Как выстроить дизайн-процесс при проектировании сложных продуктов: опыт команды Selectel

Привет! Меня зовут Ксения Гаврилова, я дизайн-менеджер команды продуктовых дизайнеров в Selectel. В этой статье поэтапно разберу наш дизайн-процесс, который формировался годами. Более 20 дизайнеров уже используют его в работе. Мы его дорабатываем, так как компания развивается и дизайн-процессы должны это учитывать.

Что полезного вы узнаете из текста:

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

Сначала введу вас в контекст. Selectel – продуктовая компания с кросс-функциональными командами. Чаще всего набор ролей внутри команды такой: продакт-менеджер, продуктовый дизайнер, фронтенд-разработчик, бэкенд-разработчик и тестировщик. В компании также есть отдел бизнес-аналитиков, но они не интегрированы в команды, поэтому продуктовый дизайнер часто берет на себя роль аналитика и общается с заказчиками.

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

А теперь — к сути.

Используйте навигацию, если не хотите читать текст полностью:

→ Что такое дизайн-процесс

→ Нюансы дизайн-процесса на практике

→ Шаг 1. Принятие и понимание задачи

→ Шаг 2. Анализ, исследование и информационная архитектура

→ Шаг 3. Проектирование

→ Шаг 4. Ревью у продуктовой команды и UX-team

→ Шаг 5. Передача в разработку

→ Шаг 6. Авторский надзор

→ Шаг 7. Проверка успешности метрик и корректировка курса

→ Заключение

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

Дизайн-процесс помогает:

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

Мы разделяем наш дизайн-процесс на 7 шагов.

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

Понимание задачи — подход, при котором исполнитель не начинает работу, пока не убедится, что он понял задачу и что заказчик согласен с его пониманием.

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

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

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

Дизайнеру необходимо:

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

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

Мы переходим к этапу анализа, если считаем, что задачу необходимо делать.

В жизни каждого дизайнера случается момент, когда он ощущает, что уже «познал этот мир». В результате, когда он берет в работу новую задачу, то сразу начинает обдумывать очевидное, на первый взгляд, решение. И оно может быть не самым эффективным из-за «замыленности» глаз. Наша задача на шаге анализа — уменьшить степень «замыленности» и не идти на поводу у первого пришедшего в голову решения.

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

На этапе анализа дизайнеру необходимо:

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

Отталкиваясь от этого, договориться с командой, сколько времени можно выделить на этот этап и на какой риск мы готовы.Наши уверенность и экспертиза формируются из:

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

В зависимости от распределения ролей внутри команды часть работ по анализу данных может взять на себя продакт-менеджер или аналитик.

Если анализа и данных в открытых источниках недостаточно, чтобы понять потребности и текущие проблемы пользователей, а риски велики, то следует провести исследование пользователей.

Главное — придерживаться правила: Не нужно заменять экспертизу исследованиями.

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

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

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

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

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

Информационная архитектура (IA) — структура контента внутри продукта. Она определяет, какие данные должны быть размещены на каждой странице и как они должны быть связаны между собой.

Действия для определения информационной архитектуры:

IA документируется в диаграммах, а не в макетах или прототипах.

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

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

Для небольших фичей и микро-улучшений этот этап будет излишним.

Решение провалидировано с командой и при необходимости с пользователями.

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

На этапе принятия задачи мы предварительно зафиксировали продуктовые метрики успешности. Сейчас – время их уточнить и скорректировать с учетом знаний, полученных на этапе анализа и исследования.

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

В документации к фиче зафиксированы метрики успешности.

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

Диапазон решений — это набор идей о том, как можно решить проблему. Задача дизайнера — как можно быстрее проверить эти идеи и отмести неподходящие.

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

Есть два пути, чтобы проверить сгенерированные идеи:

Нужно взвесить возможные риски при ошибочном решении и, если они значительные, выбрать путь тестирования.

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

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

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

При необходимости решение снова можно протестировать на коллегах или пользователях.

Есть несколько способов сократить время на проектирование:

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

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

В зависимости от масштабов фичи и ее специфики метрики успешности могут быть разными. На этом этапе стоит как минимум задаться вопросом «как я пойму, что сделал хорошо?», как максимум — сформировать систему метрик в системе аналитики.

В документации фичи зафиксированы UX-метрики.

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

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

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

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

Передача задачи разработчику включает в себя:

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

Создана задача на разработчика. К задаче прилинкованы:

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

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

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

По результатам анализа

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

Дизайнер проверил данные по метрикам успешности, сделал выводы и зафиксировал в задаче дальнейшие действия.

Так выглядит дизайн-процесс, по которому мы работаем в Selectel. Как я уже говорила дизайн-процесс внутри каждой компании уникален и зависит от типа компании, уровня ее зрелости и зрелости дизайн-отдела в частности, оргструктуры и распределения ролей на проектах. Процесс, который я описала, отлично работает для нас на текущий момент, но в будущем скорее всего претерпит изменения.

Читайте также:

#дизайн #selectel #дизайнсистема