Daria Tsukali
Product Designer · UX/UI
С 2019 года проектирую интерфейсы, с 2023-го — в продуктовом дизайне: веду задачи от интервью и гипотез до макетов и дизайн-системы. Открыта к предложениям из разных индустрий. Работаю удалённо из Бишкека, английский B2.
Дизайн-процесс
- Роль
- DesignOps
- Формат
- Штат, Click2Money
- Дата
- 2024
Результат
Команда стала одинаково понимать, что и зачем делает и чего ждать от дизайна
Контекст
Процесс собрала в Click2Money, где была единственным дизайнером: требований к дизайну не было, экраны делали сразу, без этапов. Похожий процесс до этого выстраивала в New Shift. В основе Double Diamond, схема из двух ромбов: первый про проблему, это дискавери и гипотезы, второй про решение, это макеты и релиз. Перед ними стоит постановка задачи, после них оценка результата. Часть шагов взяла из практик продуктовых команд российского бигтеха.
Постановка задачи
С этого начинается любая задача: команда одинаково понимает, что и зачем делает, и на поздних этапах меньше расхождений в ожиданиях.
- Зачем дизайнеру
Нельзя спроектировать то, в чём не разобрался. Нужен контекст, цель и миссия задачи.
- Шаги
- Вводные данные. Каждый в команде делится идеями, инсайтами и предложениями. Дальше материалы раскладываются на вводные, миссию, цель, аудиторию и критерии успеха. Сессия брейнсторминга, все предложения задокументированы.
- Цель и миссия. Цель: какую пользу компании принесёт задача. Миссия: как решение поможет клиенту. Какие преимущества получит пользователь. Цель конкретная, измеримая, привязанная ко времени.
- Аудитория. Не только «кто наши пользователи», но и сколько их: для скольких человек это делается, какая это доля от всех, есть ли специфический сегмент. Аудитория ещё одно доказательство, что задачу вообще стоит делать.
- Критерии успеха. Метрики, по которым будет понятно, что задача решена. Что считается успехом, что нельзя сломать, что делать, если результат не совпадёт с ожиданиями.
- Как сократить время
Дизайнер получает полную документацию по задаче.
- На выходе
- Описанная задача или описанная проблема
- Предварительная оценка времени на реализацию
- Предварительные метрики успеха: пользовательские и продуктовые
Дискавери
Начинается, если задачу решено брать в работу. Смысл: разобраться в проблеме, не рассуждая в рамках готового решения, и не идти на поводу у первой идеи. Отсюда берутся гипотезы для проектирования.
- Зачем дизайнеру
Понять проблему пользователей до того, как рисовать решение.
- Из чего состоит
- Опыт. Анализ текущего решения, если оно есть. Понимание общих тенденций, стандартов и лучших практик.
- Конкурентный анализ. 3–4 прямых конкурента и косвенные, их сильные и слабые стороны. Таблица с оценками от 0 до 5 и комментариями, что повлияло на оценку. На основе собранного формулируются гипотезы.
- Пользовательский фидбэк. Существующая обратная связь, консультации с поддержкой и менеджерами, у которых прямой контакт с пользователем, фидбэк от других отделов.
- Исследование пользователей. Если анализа и открытых данных недостаточно. Метод по ресурсам: опросы, глубинные интервью.
- Анализ метрики. Количественные данные о поведении пользователей в той метрике, над которой идёт работа.
- Анализ данных. Результаты прошлых исследований, существующие решения, практики и методы, которые применялись раньше.
- Как сократить время
- Часть анализа данных берёт на себя продакт-менеджер или аналитик.
- Использовать существующие исследования и статьи с практиками.
- Держать фокус на ключевых аспектах анализа.
- На выходе
- Анализ текущего решения или проблемы
- Разобраны отзывы, данные поддержки, проведены интервью и опросы
- Документация по задаче: бизнес, пользователи, технологии
- Артефакты: user flow, user story, CJM, анализ конкурентов
- Стейкхолдеры посмотрели результаты и согласовали их
Гипотезы
Гипотезы оформляются, для каждой делается простой и дешёвый прототип. Это даёт материал для дизайн-сессии и решения, с какими идеями идти дальше. У каждой гипотезы приоритет, после сортировки понятно, что брать в работу первым.
- Зачем дизайнеру
Оценить гипотезы и собрать low-fi прототипы.
- Шаги
- Гипотезы. Формула: если мы сделаем [идея], то сможем положительно повлиять на [критерий успеха], так как [почему это идея хорошая].
- Low-fi прототипы. Для каждой гипотезы простой и дешёвый прототип.
- Приоритет гипотез. Две оценки от 0 до 10: насколько гипотеза помогает достичь цель, вместе с продакт-менеджером, и насколько сложна в реализации, вместе с разработчиками. Одно делится на другое, получается коэффициент, сортировка по нему показывает, что брать первым. Подходит и любой другой метод приоритизации.
- Как сократить время
- Формулирование гипотез можно пропустить, если риск навредить клиентам или потерять деньги невелик.
- Проектировать решение, опираясь на собственную экспертизу.
- На выходе
- Оценка гипотез: насколько помогают достичь цель и насколько сложны технически
- Приоритетный список идей для дальнейшей работы
Макеты
От поиска решения к макетам. Вместе с продакт-менеджером решение делится на итерации, которые реально сделать в отведённое время, и выбирается, что войдёт в первую версию.
- Зачем дизайнеру
Уточнить детали, определить функциональность и подготовить материалы для разработчиков.
- Шаги
- Декомпозиция задачи. Задача разбивается на атомы, выделяются ключевые элементы и функциональность. Фокус на минимально необходимом решении, вместе с продакт-менеджером. Может включать информационную архитектуру и визуальный дизайн.
- Макеты. Все состояния интерфейса. Синтаксис интерфейса и тексты, понятные разработчикам. Пояснительные заметки, упрощающие реализацию. Анимация экранов и элементов там, где она объясняет поведение.
- Ревью. Разбор каждого пользовательского сценария, каждый экран сверяется с чек-листом приёмки, коридорные тесты на слабые места. Дизайн-ревью у другого специалиста, затем продукт-ревью: аналитик или продакт-менеджер сверяет с критериями приёмки из задачи.
- Как сократить время
- Готовые библиотеки компонентов.
- Фокус на основных сценариях использования.
- Отрисовывать не все состояния, недостающее закрывать общением с разработчиками.
- На выходе
- Дизайн-ревью от другого дизайнера, аналитика или продакт-менеджера
- Отмечены задачи, к которым нужно вернуться позже
Релиз
Проверка перед запуском в продакшен: дизайнер сверяет реализацию с макетами и критериями приёмки. После запуска за интерфейсом наблюдают в реальных условиях.
- Зачем дизайнеру
Сверить реализацию с макетами.
- Что проверяется
- Соответствие макетам. Экраны, состояния, тексты и поведение совпадают с тем, что принято на ревью.
- Критерии приёмки. Реализация проходит по критериям, описанным в задаче на первом этапе.
- Мониторинг после запуска. Отслеживание метрик успеха, заложенных при постановке задачи.
- Как сократить время
Заранее распределить, кто и что проверяет в команде.
Оценка результата
Через некоторое время после запуска команда возвращается к решению и сравнивает результат с ожиданиями из постановки задачи.
- Зачем дизайнеру
Понять, что сработало, а что нет.
- На выходе
- Оценка, насколько достигнутые результаты соответствуют изначальным целям
- Найдены решения, которые сработали
- Что не сработало
- Выводы и дата анализа записаны, чтобы сравнить со следующим разом
- Как сократить время
Ожидаемые результаты, критерии оценки и инструменты анализа готовятся заранее, ещё на постановке задачи.



















