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

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

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

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

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

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

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

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

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

На этапе 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 или текстовое описание в Slack.

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

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

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

Об авторе:

Alex Andreev

Lead Product Designer at QIC Digital Hub