Рассмотрим разработку минимального рабочего решения. Эта методика подойдёт как при создании нового продукта, так и при доработке существующего. Она позволит понять полезность решения задолго до релиза, сократить время разработки в долгосрочной перспективе и разумно подойти к работе, без вкусовщины.

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

Роли, необходимые в решении задачи:

• UX/UI-дизайнер — для проведения исследования и создания макетов и прототипов.

• Фулстек-разработчик — для сборки фронтенда и проработки бэкэнда.

• Системный аналитик —- для проверки решения на бою и сбора полезных для развития показателей.

Полезные роли:

• Инвестор/владелец — для координации и оплаты работ.

• Бизнес-аналитик — эксперт в разрабатываемой области

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

→ 1 — Определение целевой аудитории

Любой продукт решает конкретную задачу, которой озабочен конкретный человек → человек представляет некую группу людей → у этой группы есть какие-то общие черты. Так мы грубо представляем группу людей одним человеком — это собирательный образ ЦА.

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

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

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

Для этого нужно изучить целевую аудиторию.

→ 2 — Изучение ЦА

Как правило, приложение решает не одну, а несколько задач, крутящихся вокруг главной.

Потратьте неделю–другую для исследования ЦА:

1. Найдите представителей вашей целевой аудитории.

2. Составьте опросник для проведения глубинного интервью.

3. Встретьтесь или созвонитесь с респондентами, и в спокойной обстановке — в духе разговора по душам — расспросите о том, как люди решают свои задачи; почему именно так; что в этом решении удобно-, что — не очень; в какие моменты эти задачи возникают; что заставляет их действовать так, а не иначе.

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

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

5. Выясните, какими ещё сервисами они пользуются? Какие из них платные? Что в них нравится, что удобно.? Что не нравится, что не удобно? Почему они решили платить за услуги? Отлично, если эти сервисы будут в схожей с вашей тематике..

Так вы детализируете ранее созданный образ вашего клиента.

→ 3 — Прототип

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

На этом этапе нужно быстро проработать основные процессы приложения — ваш путь будет зависеть от сложности вашего сервиса. Перечислю основные инструменты и их пользу:

• Ментальная карта — пригодится, если у вас множество небольших функций; позволит не запутаться и отделить основное от второстепенного. 

• Блок-схема — понадобится, чтобы выстроить логику запросов на сервер и передачу данных на фронт.

• Карта переходов — позволит широкими мазками наметить путь пользователя.

• Вайрфрейм-прототип — позволит протестировать решение без глубокой проработки. Сформирует понимание процесса у коллег.

Разберём прототип детальнее:

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

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

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

Сделайте переходы и соберите интерактивный прототип. Пробегитесь по нему.

→ 4 — Определение стиля

Обратите внимание на то, как перечисленные респондентами сервисы подают информацию, оформляют интерфейс, строят процесс, и подводят к оплатам.

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

Вышеописанным мы решаем несколько задач:

1. Обретаем понимание потребностей пользователей.

2. Получаем твёрдую аргументацию для отстаивания решения перед коллегами.

3. Формируем у себя визуальные привычки пользователей — это даст нам возможность говорить с пользователем на его языке или выделиться на фоне привычного.

→ 5 — Визуальный концепт

Держите мудборд всегда перед глазами. 

Возьмите 3–4 основных экрана из прототипа и отрисуйте в том стиле, который вам кажется более подходящим под ваших пользователей, с учётом их ассоциаций и настроения.

Немного о настроении и ассоциациях:

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

Используйте хороший контраст для основных триггеров и текстов. Не используйте мелкие шрифты. Вообще, проверяйте свой дизайн на соответствие международному стандарту доступности контента (WCAG). Для этого есть множество программ и плагинов.



→ 6 — Макеты

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

Гиперважно: 

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

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

На этом этапе нужно отрисовать все ветки приложения. Обязательно нужно учесть все состояния интерфейса (заполненный, незаполненный, заполненный частично, ошибка).

Расставьте ветки так, чтобы было просто разобраться, что за чем идёт. Это позволит и вам, и коллегам не запутаться.

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

Покажите весь процесс команде и расскажите подробнейшим образом о каждой детали (цвета, отступы, компоненты, анимации, шрифты)

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

→ 7 — Тест основного процесса

1. Соберите на макетах интерактивный прототип основной ветки и спорных мест. 

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

3. Протестируйте прототип. Помните, тест не должен занимать много времени. Идеально, когда на одного респондента уделяется минут 15–20 и 10 минут на доп. вопросы.
   
   Тестируйте прототип на том устройстве, под которое вы собираете решение. Обращайте внимание на то, как респонденты пользуются прототипом. Спрашивайте, почему они сделали то или иное действие, что ожидали.
   
   Ведите запись экрана, а ещё лучше просто записывайте всё интервью на видео так, чтобы было видно, что делает пользователь, и слышно его комментарии.
   

   

4. Проведите около 10-и сеансов с разными людьми — представителями вашей целевой аудитории.
   
   Вы выявите повторяющиеся поведенческие паттерны, заблуждения, действия и предположения. Это и есть результат. Скорректируйте макеты, чтобы убрать шероховатости.



→ 8 — Документация для разработчика

В разработку передайте процессы, обрабатывающие различные пользовательские сценарии. Передавайте только то, что вы договорились релизить в первую очередь. Так вы не запутаете разработчика.

→ 9 — Результат в бою

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

→ 10 — Улучшения

Общайтесь с коллегами и вносите коррективы в сервис и его работу оперативно, но не всё сразу, чтобы понимать, что влияет на конверсии, а что нет.

Заключение 

• По итогу мы получаем процесс, в котором всё взаимосвязано. 

• Решение проверено и отвечает задаче пользователя и бизнеса. 

• Итоговый дизайн опирается на исследование, тестирование прототипа и приятный пользователю визуальный стиль

Таким процессом мы на раннем этапе отсекаем множество доработок, переделок и никогда не зарелизим мертворождённый продукт.

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

Если будут вопросы, я с радостью отвечу на них в Телеграме — @Kilunin.