Дизайн-процессы в цифровом продукте.
Общая схема работы над дизайн-задачами, что делать/что не делать по каждому из этапов.
Начал с описания дизайн-процессы в своем проекте marquiz.ru, в итоге вышла методичка для дизайнеров цифровых продуктов о том, как системно разрабатывать решения высокого качества.
Особенно актуально на старте продукта, чтобы разобраться что к чему, когда большинство вещей делаются интуитивно.
- Постановка задачи
- Дизайн-решение
- Детализация
- В разработке
1. Постановка задачи
Цель: Четкое понимание проблемы, которую мы пытаемся решить.
Ответить на вопросы
- Какую проблему мы решаем?
- Как это повлияет на клиента: на него и на его бизнес?
- Что будет успешным решением проблемы? Какую метрику улучшит?
- Какие действия принимали в прошлом, как это помогло?
Дополнительно
- Сомневаться: действительно ли это та проблема, которую нужно решить?
- Посмотреть конкурентов
- Спросить пользователя с такой проблемой. Завести переписку
- Провести исследование
- Проиллюстрировать весь путь пользователя и выявить слабые места.
Результат: Общий файл с описанием проблемы “Зачем”, без намеков о том “Как” это будет сделано.
2. Дизайн решение
Цель: Изучить разные способы решения задачи и предложить концепт. Согласовать с разработкой наиболее простой в реализации и эффективный вариант решения. (Как MVP функционала).
Что нужно сделать
- Изучить разные способы решения задачи и предложить концепт:
- Черновой дизайн ключевых экранов
- Описать путь пользователя и как эта задумка работает
- Определить сложности и возникающие вопросы на пути пользователя
- Оценить За и Против текущего концепта
- Сформулировать обоснование, почему именно это решение, а не другие
- Спросить разработку о технической части внедрения концепта
- Получить обратную связь от продуктовой команды и определить наиболее эффективный вариант решения.
Дополнительно
- Вынести проблему на общее обсуждение, собрать идеи
- Если черновой дизайн не помогает оценить удобство решения — сделать анимированный прототип.
- Протестировать концепт в закрытом Telegram чате для маркетологов.
- Возможно несколько раундов обсуждения перед принятием дизайн-решения
Результат: Принятое дизайн-решение.
3. Детализация
Цель: Подготовить исходники, анимацию и описание задачи для разработчиков.
Что нужно сделать
- Задизайнить все этапы и состояния функционала
- Использовать дизайн систему. Если не можешь использовать текущие элементы системы — дополни ее.
- Посмотреть рекомендации о хорошем UI от Intercom
- Редактура текста. Не использовать Lorem Ipsum
- Посмотреть на целостность дизайна: как это повлияет на другие элементы продукта в разных форматах?
- Нужно поменять что-то в других элементах?
- Дизайнить не только счастливый сценарий, предусмотреть все ситуации: ошибка, нет текста, много текста, долго грузится.
- Что будет при первом взаимодействии с дизайном? Есть что непонятного?
- Описать задачу в карточке Notion: проблема, решение, исходники, назначить разработчика.
Дополнительно
- Сделать интерактивный прототип, задизайнить микро-анимации
- Протестировать интерактивный прототип с реальными клиентами
- Доработать дизайн-систему
Результат: Исходники высокого качества, задача ясна, поставлен приоритет в разработке.
4. В разработке
Цель: Отвечать на вопросы разработчиков, делать дизайн-ревью, выдрачивать пиксели.
Что нужно сделать
- Взять ответственность за выпускаемый функционал. Топить за разработку качественного варианта — качество всегда на первом месте.
- Look&Feel — как воспринимается опыт работы с функционалом, что можно улучшить: анимация, текст, подсказки?
- Продумать какие анимации сделают переходы связанными и гармоничными.
- Сделать дизайн-ревью задачи: точность верстки, отступы, отображения в разных форматах
- Написать емкий текст для анонса нового функционала
- Написать текст для раздела часто задаваемых вопросов
Результат: Функция внедрена, собираем обратную связь из техподдержки.
О принципах которыми руководствуемся в продуктовой работе, рекомендации по хорошему UI, уровни развития дизайнера скорее всего напишу отдельные статьи.