У вас отключен JavaScript
Для пользования сайтом, необходимо, чтобы JavaScript был включен. Посмотреть как включить, выберите свой браузер:

Wireframes для мобильных приложений: как мы их создаем

 

Wireframes, Prototypes, Mockups – термины, которые зачастую ошибочно используются как взаимозаменяющие друг друга.

Из этой статьи вы узнаете, какой смысл мы вкладываем в эти три понятия. А затем мы подробно остановимся на таком инструменте, как Wireframe, и опишем процесс его создания специалистами Umbrella в той форме, в которой мы обычно готовим его для своих заказчиков.

Стоит отметить, что мы уже не первый день успешно используем в своей работе этот полезный инструмент.

Хотите на практике оценить преимущества работы с нашей командой, приходите к Umbrella со своими идеями и проектами!  

 

Что такое Wireframe:

По существу, wireframe – это скелет экранов будущего приложения.  На нем обозначены основные элементы, и отображено их расположение в зависимости от приоритетности.

Можно было бы ограничиться обозначением wireframe как схемы экранов. Но это не отразило бы других его особенностей: зачастую он включает в себя некоторые пользовательские сценарии, отдельные изображения, навигацию. Согласитесь, это уже не просто схема. Поэтому правильнее называть его прототип интерфейса.

В целом,  этот инструмент отражает взаимодействие пользователя с приложением. Стоит упомянуть, что в каждом конкретном проекте такой прототип интерфейса будет иметь свои определенные особенности, но мы будем говорить сейчас о типичном (назовем его идеальным) случае.

 

Mockup:

В дальнейшем на основании прототипа интерфейса создается макет (mockup).

На этом этапе за работу принимается дизайнер. Его задача заключается в том, чтобы разработать дизайн для приложения и в соответствии с ним стилизовать все элементы прототипов интерфейсов. Дизайнер оформляет форму и размер элементов прототипа, может незначительно изменять их расположение, но не удаляет сами элементы. Задача дизайнера – создать оптимальный  UX/UI на основе прототипа интерфейса.

 

Prototype:

На следующей ступени на базе прототипа интерфейса и макета создается прототип (prototype).

Такой прототип уже будет представлять собой приложение с минимальным объемом функционала. В этой форме прототипы приложений можно использовать, например, для проверки определенных функций, презентации инвесторам или альфа тестирования на группе пользователей.

 

Что именно мы видим на Wireframe?

  • какие будут использоваться экраны в приложении, и как они связаны между собой:

Мы можем представить себе общую структуру приложения и логику связи между экранами, а также навигацию.

  • все блоки информации:

Wireframe отражает, какая информация будет включена в приложение, и как она будет распределена по блокам.

  • все интерактивные элементы:

Мы видим кнопки, ссылки, формы, поля форм на каждой странице и их общее расположение/структуру.

  • структуру размещения элементов и информации:

Все элементы приложения размещаются таким образом, чтобы пользователю было удобно с ними взаимодействовать. Кнопки находятся именно там, где мы привыкли их видеть. Наиболее значимая информация выделена подсветкой или размером.

  • удобные для заполнения формы:

Поля форм сгруппированы по определенным признакам. Продумывается каждый шаг пользователя при заполнении формы.

 

Mind Map как основа для Wireframe

Прежде чем мы начинаем работать над прототипом интерфейса, мы создаем функциональную карту (Mind Map), которая составлена на основании информации о продукте, полученной от заказчика. Такая карта представляет собой проработанную схему, отражающую общую идею сайта или приложения и высокоуровневые описания пользовательских сценариев.

Подробнее о функциональных картах читайте в нашей статье.

 

Как мы создаем Wireframe?

  • создаем наброски экранов приложения

Начинаем работу с того, что на основании функциональной карты определяем, какие именно экраны нам будут необходимы в будущем приложении, чтобы последовательно и логически распределить на них запланированные блоки информации.

Рисуем основные экраны, которые нам нужны в будущем приложении. Распределяем постранично информацию, которая должна быть на них отражена.

Такие наброски можно делать на бумаге, а можно использовать специальные скетчпады (блокноты с заготовками под мобильный интерфейс) или веб-сервисы.  Изображение должно быть очень схематичным. Не нужно детально прорабатывать каждый экран, иначе существует риск упустить общую концепцию.

 

ex 1

 

  • продумываем переходы между экранами и навигацию

Определяем логическую последовательность экранов, переходы и ссылки с одного экрана на другой.

Современный пользователь привык работать с приложениями интуитивно, и неохотно выполняет сложные действия в приложениях. Поэтому связь между экранами должна быть простой и понятной и должна соответствовать привычному UX пользователя. Чтобы добиться этого, нужно самому быть активным пользователем мобильных приложений.

 

ex 2

 

  • прорабатываем более детально каждый экран

На этом этапе детализируем наброски экранов, добавляем недостающие второстепенные/переходные экраны.

В процессе создания wireframe мы применяем существующие практики в области UX/UI для пользователей разных платформ (iOS, Android, Windows Universal Platform). В этом смысле подходы к созданию mainframes для приложений iOS и приложений Android отличаются, и нужно принимать в расчет специфику каждой платформы.

 

Например:

Навигация между вкладками в приложениях iOS расположена в нижней части экрана. В то время как для Android рекомендуется расположение в верхней части.

Отличается и метод возврата на предыдущий экран: у Android используется системная кнопка Назад, и иногда предусмотрена дополнительная кнопка Назад на верхней панели.

В приложениях для iOS кнопка Назад находится почти всегда на верхней панели, а также применяется удобный возврат на предыдущий экран с использованием свайпа от левого края.

Все подобные детали рекомендуется обсуждать с UX/UI дизайнерами и разработчиками уже на этом этапе. За счет своевременного обсуждения можно сократить время работы над проектом в последующем.

  • добавляем комментарии к скелету

Помимо фактического отображения элементов экрана приложения и навигации целесообразно включить в прототип интерфейса комментарии по бизнес-логике.

Например:

Пользователь может загрузить 1 картинку бесплатно. Если он захочет загрузить больше, ему предложат апгрейд его аккаунта.

Или

Рядом с кнопкой удаления должно открываться всплывающее окно с запросом на подтверждение удаления.

 

ex 3

 

  • делаем прототипы интерфейса более реалистичными

Если позволяет время, дополняем wireframe изображениями. Оформляем кнопки так, чтобы они выглядели более реальными, или добавляем настоящие данные.

Например:

Добавляем действительное название продукта или его описание.

 

baba

 

  • добавляем интерактивность

В некоторых случаях рекомендуется сделать wireframes интерактивными в той степени, в которой позволяют время и условия разработки проекта.

Например:

С одной стороны, действующие переходы между экранами и работающие ссылки дают возможность заказчику увидеть свое будущее приложение “вживую” уже на этом этапе работы.

С другой стороны, это еще и отличная возможность выявить любые возможные нестыковки и ошибки и устранить их, не дожидаясь этапа тестирования.

  • демонстрируем заказчику

Если заказчик не имеет технической подготовки, объясняем ему, что это еще не конечный результат, а только схема. Согласовываем с ним готовый вариант wireframe, чтобы передать его дальше в работу дизайнерам и разработчикам.

 

Какие преимущества дает нам wireframe?

  • в отличие от текстового описания графическое обеспечивает более приближенное к реальному представление о будущем продукте;
  • соответственно, ниже риск разночтений в отношение видения будущего продукта разработчиками и заказчиком;
  • схематическое представление воспринимается проще;
  • есть возможность найти UX ошибки еще на этапе проектирования, а не когда приложение уже будет готово;
  • существует возможность привлечь разработчиков уже на этом этапе, согласовать с ними критические и важные моменты и зафиксировать их в комментариях.

 

ex5

 

Возможные ошибки: как их исключить?

Возможная ошибка: уделять слишком много внимания деталям и затягивать процесс проектирования.

Решение: делать только то, что необходимо в соответствии с требованиями к продукту (функциональной картой или другим документом).

Возможная ошибка: открыть доступ к редактированию всем участникам команды. Это приводит к путанице с версиями и недопониманию.

Решение: обновления вносит только один человек.

Возможная ошибка: пытаться охватить сразу весь объем, если работаем с масштабной и многофункциональной системой.

Решение: прорабатывать страницы поэтапно, модульно.

Возможная ошибка: выдумывать что-то совершенно новое, игнорируя существующие основные практики UX. В результате интерфейс кажется пользователям непонятным и сложным.

Решение: использовать общепринятые стандарты. Вносить новшества, но с учетом уже наработанного опыта.

Мы описали типовой процесс разработки wireframe в том виде, в котором он выполняется специалистами Umbrella. Нельзя не упомянуть, что каждый новый проект привносит новый опыт и новые улучшения в этот процесс. В каждом последующем случае мы выбираем те методы и практики, которые оптимально подходят каждому конкретному заказчику.

Остались вопросы? Свяжитесь с Umbrella прямо сейчас!

 

Фото: Shutterstock.com


Ещё

  • Создаем приложение с механикой Uber: руководство по разработке проекта на миллион долларов
    Создаем приложение с механикой Uber: руководство по разработке проекта на миллион долларов
    Uber стал первым, кто применил бизнес-модель совместного потребления и экономику по требованию и взял на абордаж целый мир. Дестабилизация традиционного рынка такси не мешает Uber позиционировать себя, прежде всего, как технологическую, а не транспортную компанию. И это вполне оправданно – образцовый сервис и эффективные технические решения – именно то, что привело компанию к оглушительному успеху. …
  • Как увеличить вовлеченность в мобильных приложениях: 6 полезных советов
    Как увеличить вовлеченность в мобильных приложениях: 6 полезных советов
    Что заставит пользователей возвращаться в ваше приложение снова и снова? Как запустить работу приложения на полную мощность и сделать его незаменимым для всех и каждого? Десяток, а может и два десятка установленных на смартфон приложений, но пользуетесь в реальности всего несколькими из них? Совсем не хочется, чтобы ваше приложение попало в список “однажды открою, вдруг …
  • Разработка приложений на React Native: универсальный солдат
    Разработка приложений на React Native: универсальный солдат
    К 2018 году споры о том, нужны ли бизнесу мобильные приложения, уже утратили актуальность. Теперь основной вопрос заключается в выборе технологий и исполнителей для реализации проектов. Мы уже описывали 5 причин использовать React Native для разработки мобильных приложений. Сегодня вы узнаете, в каких случаях целесообразно использовать React Native, а в каких – нативную разработку.   …