Как дизайн-процесс помогает разрабатывать страховые продукты для Катара и ОАЭ

В этой статье Алекс Андреев, Lead Product Designer в QIC digital hub, расскажет о том, как в крупной компании построен дизайн-процесс в формате ‘end-to-end’. Статья будет полезна дизайнерам, которые заинтересованы в устройстве процессов внутри крупной компании, или менеджерам продукта/дизайн-команд.

Дизайн-процесс в продуктовой компании играет значительную роль, ведь от него, в том числе, зависит результат разработки отдельной фичи, или всего продукта. Грамотно выстроенный дизайн-процесс помогает упростить разработку и дизайн, начиная с концепции, и заканчивая анализом метрик после релиза. Кроме того, он сокращает стоимость разработки и time to market, а продуктовым дизайнерам UX/UI помогает достигать высокого качества работы, за счет плотной координации с продуктовой командой.

В команде мы используем дизайн-процесс в формате end-to-end — проектируем дизайн от возникновения задачи/проблемы/идеи до релиза, и пост-релизной доработки на основе метрик или фидбэка от пользователей:

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

Разберем последовательно этапы дизайн-процесса:

• Prepare – формирование точного понимания проблемы или задачи, которую будем решать;
• Explore – быстрое прототипирование решения и обсуждение со стейкхолдерами;
• Detailed design – детальный дизайн в финальном качестве, который учитывает все кейсы взаимодействия пользователя с интерфейсом;
• Copy review – проверка и корректировка текстов в интерфейсе;
• Developers hand-off – обсуждение дизайн-решения с разработчиками;
• Design review – просмотр и обратная связь по реализованному решению на тестовой среде (со стороны дизайнеров).

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

• Чтобы этого избежать, мы используем определенный шаблон постановки задач на дизайн, по которому продуктовая команда может описать суть и объем задачи/проблемы, а также критерии успеха;
• Также дизайнер может обсудить задачу с Project Manager своей команды, чтобы убедиться в деталях, или дополнить задачу вводными;
• Если в вашей компании есть UX Researcher, то на этом этапе имеет смысл запросить у него релевантные результаты с предыдущих исследований/тестирований, чтобы использовать их в текущей задаче и выстроить аргументацию своего решения.

Про метрики. Также, стоит учитывать работу с метриками на этом этапе. По аналогии, со взаимодействием с UX Researcher, стоит изучить и приложить к задаче самые базовые показатели. Это будет большим плюсом, ведь вы сможете опираться на цифры, а не субъективные решения. Вот лишь несколько из них, на которые мы смотрим в реальных задачах:

• CR — Conversion Rate (конверсия);
• Session Duration — средняя продолжительность сессии на сайте;
• Scroll Map (карта скролла) — как глубоко пользователи скролят страницу по высоте, какой контент они видят.
• Heatmaps (карта кликов) — куда пользователи кликают в интерфейсе;

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

На этапе Explore продуктовый дизайнер проектирует решение низкой детализации в виде wireframes, а также информационную архитектуру в виде данных, если это крупная фича/продукт. Благодаря этому мы сможем увидеть весь User Flow. Наша задача — посмотреть на продукт глазами клиента и продумать все сценарии его взаимодействия с продуктом или фичей:

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

Когда всё готово, мы валидируем результат у Project Manager, и/или разработчиков, причём иногда это можно делать параллельно. Бывает так, что Project Manager вносит корректировки в wireframes, но в целом разработчики уже могут предварительно оценить scope работы, технические ограничения, и сроки реализации.

Когда продуктовый дизайнер предварительно обсудил логику работы интерфейса, и учел все нюансы разработки из предыдущего этапа ‘Explore’, то можно переходить к следующему - ‘Detailed Design’.

Именно на этом этапе дизайнер визуализирует интерфейс в виде UI в финальном состоянии, включая ошибочные кейсы — страницы 404, ошибка загрузки данных, валидации форм, ‘empty-state’, и так далее:

Дизайнер прорабатывает интерфейс, используя максимально реалистичный контент: имена и фамилии, модели авто, etc… , чтобы заранее продумать нарратив интерфейса с пользователем, и протестировать корректность работы компонентов дизайн-системы. Например, часто возникает проблема с переполнением и размерами компонента - из-за большого объема текста, интерфейс ‘съезжает’. Больше всего это проявляется в карточках, навигации, и текстовых ячейках. Такие кейсы дизайнеру стоит предусмотреть заранее, и внести соответствующие изменения.

В случае, если в компании есть UX-Researcher, стоит также передать ему интерфейс в виде интерактивного(кликабельного) прототипа на проведение модерируемого usability-тестирования, чтобы получить фидбэк от респондентов еще до передачи интерфейса в разработку. Если такой возможности нет, то стоит провести хотя-бы “коридорное” тестирование, чтобы выявить самые критичные ошибки в логике работы интерфейса. На этом этапе часто можно найти ошибки в навигации продукта. Это хорошо, ведь можно сразу скорректировать решение.

В итоге, финальный дизайн согласовывается с Project Manager, который может принять его сразу, либо отправить на доработку. Обсуждение дизайн-решения может проходить как в формате презентации, если оно объемное, так и в виде ссылки на Figma в Jira.

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

На этом этапе наш Content Designer проверяет текст в интерфейсе на логику текстового нарратива, а также соответствие корпоративным гайдлайнам, и tone-of-voice. Content Designer правит текста, если нужно. Иногда подключается на этапе ‘Explore’, но это опционально и зависит от масштабов фичи или продукта:

Иногда бывает так, что Content Designer смотрит на экран и говорит: «Здесь эту проблему нельзя решить текстом, нужно показать другое состояние или расположить элементы иначе». Если это обоснованное решение, и оно сделает пользовательский опыт лучше, то мы переделываем дизайн в этом месте (не забывая согласовать изменения с Project Manager и разработчиками).

На данном этапе, дизайнер проводит презентацию всего флоу разработчикам. Этот этап частично повторяет ревью, проведенное разработчиками на этапе 'Prepare', но уже более детально. Дизайнер рассматривает каждый экран на протяжении всего флоу, включая все детали интерфейса, такие как отступы, текст и так далее. Внимание уделяется не только логике интерфейса, но и его дизайну (UI) и анимации, если они присутствуют.

Кроме того, на этом этапе важно, чтобы дизайнер учел следующие аспекты:

• Подготовить Figma-файл для передачи в разработку. Это — тема отдельной статьи, однако кратко стоит подчеркнуть необходимость наглядного отображения всех состояний экранов, включая ошибочные и пустые состояния, с четкой организацией на странице.
• Очистить Figma-файл от ненужных элементов, таких как блоки, секции и устаревшие дизайн-варианты. Их наличие может сбить с толку как разработчиков, так и самих дизайнеров. Такие элементы можно переместить на отдельную страницу внутри файла, которую можно назвать ‘Draft’ или “Archive".
• Проверить привязку компонентов к дизайн-системе или UI-Kit. Это поможет минимизировать необходимость создавать кастомные компоненты. Конечно, на реальных задачах иногда возникают ситуации, когда нужно пересмотреть или доработать компонент. В таких случаях мы отвязываем его от дизайн-системы и вносим необходимые изменения. Частота подобных ситуаций будет зависеть от того, насколько хорошо дизайн-система в вашей компании охватывает все потребности в интерфейсных компонентах.

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

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

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

• Постепенного развития каждого этапа. Не беритесь сразу за все аспекты; начните с чего-то конкретного, например, улучшения процесса сбора информации ‘Prepare’, ‘Explore’. Когда этот этап станет успешным и хорошо отлаженным, переходите к анализу метрик. Важно, чтобы каждый последующий этап строился на прочных основах, созданных на предыдущих этапах.
• Настройки анализа метрик. Этот аспект важен, поскольку на основе метрик после выпуска продукта или фичи вы сможете определить приоритеты задач и структурировать дизайн-бэклог.

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

Об авторе:

Alex Andreev

Lead Product Designer at QIC Digital Hub