- Сначала нужно выяснить, есть ли какая-то информация о бизнес-контексте: рынок, пользователи, потребности. Как правило, это инфа должна быть от самого заказчика.
- Если мы знаем контекст, то нужно узнать подробнее о пользователях, кто, в каких ситуациях и для каких задач будет использовать приложение. Обычно информацию о пользователях собирает исследователь или заказчик. Но если такой информации нет, то тогда придется собирать дизайнеру.
- Информацию о пользователях нужно упаковать в понятные для работы фреймворки. К примеру можно использовать следующие
- JTBD – для описания контекста и ожиданий пользователя.
- CJM – карта для описания действующего / нового пути пользователя. Поможет понять, какой набор экранов и с каким функционалом необходим пользователю
- После того, как мы получили представление о пользователях и их задачах мы можем перейти к созданию низко-детализированных прототипов (Lo-Fi) на основе CJM.
На этом этапе нет задачи сделать красиво, главное сделать понятно. Поэтому вместо изображений и текста - прямоугольники. Главное, чтобы текст необходимый для понимания что происходит был уже написан. (Кнопки, разделы и т.д.)
Такие прототипы помогают быстро и с низкими затратами времени, проверить насколько наше решение подходит пользователям. Плюс мы избежим ситуации, когда на дизайн потрачено много времени, а сделано в итоге не то, что нужно.
- Проверяем наше решение на пользователе. Если пользователь может решить свою основную задачу уже в Lo-Fi прототипе, то это хороший прототип и можно идти дальше.
Если пользователю сложно понять, что происходит, куда нужно тыкать и зачем он это всё делает, то будет необходимо вернуться на шаг назад и улучшить прототип.
Кроме пользователя, прототип можно показать и заказчику, чтобы синхронизироваться, в ту ли сторону мы движемся.
- И вот у нас уже есть проверенный Lo-Fi прототип, который решает задачу пользователя и является тем, что от нас хотел заказчик. Значит, мы можем постепенно повышать детализацию прототипа: добавлять картинки и тексты.
- Постепенно, улучшая наш прототип, мы приходим и к самому дизайну приложения.
2 эксперта согласны
Вероничка Гущина
29 авг 2021подтверждает
Как подробно и доступно разложено ! 🔥
В проектах пригодился подход от Дж. Гарретта из книги The Elements of User Experience: User-Centered Design for the Web and Beyond (2nd Edition). Автор хорошо ориентирует по схеме дизайна приложений от стратегии и требований к... Читать далее
С общения с заказчиком! Вы должны четко понимать, какие задачи решает приложение и что хочет видеть заказчик.
Отлично если вы сами можете присутствовать на интервью и записывать все пожелания заказчика.
Если нет, то советую... Читать далее
Не всегда заказчик хорошо представляет тагет-груп заказываемого приложения. Кто будет его юзать? Гик с айфоном... Читать дальше
Первый
Надежда, добрый день!
Создание дизайна приложения начинается с составления его структуры. Но перед тем, как составить структуру, необходимо понимать, какие задачи стоят перед приложением, кто целевая аудитория (пол, возраст... Читать далее
Первый
С изучения пользователей и их проблем. Надо определить кто будет использовать продукт, их базовое поведение по модели DISC Уильяма Моултона Марстона, какие у них проблемы.
Создать профили пользователей, т.н. "персоны"... Читать далее
Удачный дизайн создается с учетом эстетики, эргономики и характера наиболее вероятного пользователя. Причем эргономика играет здесь ключевую роль, так как неудобное управление, пользование ЛЮБОГО изделия, включая и графические... Читать далее
Нужно чётко понять что делает приложение и какие задачи выполняет, выписать на листке все его функции.
Потом выписать все экраны и страницы приложения, составить блок-схему для наглядности.
И наконец можно сделать набросок... Читать далее