на русском · in english

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

1. Понимание

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

• Подробнее о понимании задачи Миша Наер и Иван Звягин

Хорошая практика:

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

2. Дискавери

Анализ нужен для того, чтобы сформулировать как можно больше валидных гипотез. У меня есть несколько рабочих способов:

1. Анализ текущего решения, если оно есть, или личное представление о решении проблемы. Мы же опытные дизайнеры, мы можем сразу сказать что можно улучшить.
2. Анализ конкурентов.
3. Анализ пользовательского фидбэка. Работа с отзывами в сторах и с тем, что прилетает в службу поддержки.
4. Анализ фидбэка от других отделов, если это уместно. Например, коммерческий отдел или маркетинг.
5. Глубинные интервью с потенциальной аудиторией.
6. Анализ метрики, которую бустим. Кабинетное исследование. Как правило мы делаем это не первые в мире и про многие практики написано достаточно много статей с исследованиями и лучшими решениями. Нельзя сказать, что они подойдут нам, но изучить стоит.
7. Анализ данных.

3. Формулирование гипотез и низкоуровневые прототипы

После анализа у меня есть куча идей и я их пытаюсь формализовывать по маске:

• «Если мы сделаем (сама идея), то он сможет положительно повлиять на (критерий успеха), так как (почему это идея хорошая)».

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

Хорошая практика:

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

Далее выставляем приоритет каждой гипотезе. Приоритет оценивается по двум параметрам:

• насколько гипотеза помогает достигнуть цель или миссию (от 0 до 10) вместе с продуктовым менеджером,
• насколько она технически сложная в реализации (тоже от 0 до 10) вместе с разработчиками.

По каждой гипотезе делю одно на другое и получаю коэффициент. Сортируем и получаем то, что нужно брать в работу в первую очередь.

4. Скоупинг и высокоуровневые макеты

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

Для лучшего решения я делаю макеты. Обрисовываю все состоянии. Работаю с синтаксисом элементов интерфейса и текстом. Пишу пояснительные заметки для разработчиков. Анимирую экраны и элементы интерфейса.

Хорошая практика:

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

5. Ревью результата и запуск!

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

6. Анализ результата

Через какое-то время, зависит от задачи, возвращаюсь к задаче и анализирую результат вместе с продакт менеджером. Насколько наши ожидания совпали с реальными результатами, делаем выводы. Для удобства я фиксирую задачи с датами и выводами в Гугл Таблице, без всяких супер-заморочек.

Далее итерации, итерации и итерации. Если все плохо возвращаемся к пункту один, если хорошо — тоже, но уже с новыми целями.

— Это очень долго!

Весь этот процесс, звучит сложным и долгим, да. Но важно отметить, что в реальности это не так долго, как кажется. Первых 6 пунктов средней по сложности задачи делаются за 1—2 рабочих дня. Тем более тут описан идеальный процесс, в реальной жизни некоторые пункты пропускаются или автоматизируются.

Дизайн-процесс большого проекта →