Как выглядит процесс работы продуктового дизайнера в российском BigTech в конце 2023 года (D→P)

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

У дизайнера:

У команды разработки:

У всей команды и бизнеса:

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

_______

Разделение на Discovery и Delivery

Этап A — Появление задачи · [1], [2], [3]
Этап B — Передача в дизайн · [4], [5], [6]
Этап C — Выбор концепции · [7], [8], [9], [10]
Этап D — Раскатка в тест · [11], [12], [13]
Этап E — Релиз решения

Принципы: [I], [II], [III], [IV], [V]

Команда Discovery:

Команда Delivery:

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

Откуда задача попадает в бэклог:

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

Находим и подтверждаем боли пользователя:

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

Выявляем проблемы бизнеса:

Задача, подкреплённая болью бизнеса и соотносящаяся с продуктовой и/или дизайн-стратегией, будет иметь больший приоритет.

Как дизайнер участвует в сборе данных:

Нужны ли гипотезы от Продуктового менеджера по решению проблемы?

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

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

Discovery Product Backlog Refinement — регулярная встреча (она же Backlog Grooming), на которой команда:

Что должна содержать задача по итогам PBR — (Definition of Ready задачи для передачи её в дизайн):

Что задача не должна содержать:

Как дизайнер участвует в Disco PBR:

Когда у дизайнеров много продуктовых команд одновременно – имеет смысл сделать отдельный Design PBR, который будет основной регулярной встречей, а подключение к Discovery PBR каждой продуктовой команды — опционально.

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

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

Дизайнер проводит research, необходимый для полного понимания контекста:

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

В процессе research’а и по его завершению дизайнер формирует гипотезы решения проблемы и подкрепляет их концептами.

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

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

Если хочется конкретных примеров, как использовать и комбинировать те или иные подходы для концептов — напишите об этом в комментариях, если я увижу интерес — напишу статью и продублирую её в telegram канале Design → Product

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

В зависимости от задачи могут быть разные варианты проведения тестов:

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

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

Тестирование заранее подготовленного прототипа выбранным способом может быть проведено либо дизайнером самостоятельно, либо силами UX-исследователя.

Для проведения быстрых UX-тестирований подходит формат UserDay — это регулярные встречи с респондентами, которые организует Research отдел.

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

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

Дизайнер создаёт высокодетализированные прототипы для будущего UX-тестирования, работая совместно с UX-исследователем для создания сценария или готовясь к тестированию самостоятельно.

В процессе создания прототипов привлекается UX-редактор и происходит синхронизация с продуктовой командой и командой разработки.

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

В продукте, где ценность дизайна только начинает расти, а команда далека от оптимального TTM (Time to Market), создаётся 2 решения для проверки — MLP (Minimal Lovable Product) и целевое решение

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

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

Полноценное UX-тестирование чаще проводится силами UX-исследователя, но может быть проведено и самим дизайнером.

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

Вот несколько лайфхаков, как сделать качественное решение:

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

Этап, на котором лидирует команда Delivery, но участие продуктового дизайнера всё ещё необходимо.

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

Обычно количественные данные по эффективности решения получают с помощью A/B тестов — проверки решения на части пользователей.

Помимо стандартного A/B тестирования существуют разные способы валидации решения — например, решение может быть внедрено в формате пилотного выборочного запуска с участием реальных пользователей, или в формате использованием добровольной программы раннего доступа — публичный бета-тест (как, например, тестирование функций в YouTube).

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

После разметки событий в продукте команда разработки внедряет решение на продакшен с учётом дизайна теста.

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

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

Внесение небольших изменений в макеты. Дополнительно можно быстро протестировать решения — провести экспертную оценку от продуктовой команды, дизайн-департамента, или проверить решение на User Day.

Delivery команда реализует финальные правки и подготавливает решение к релизу для всех пользователей.

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

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

С момента релиза решения доступно множество инструментов для сбора обратной связи:

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

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

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

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

У команды Discovery очень много контекста по продукту и задачам, которую решает дизайнер. Синхронизация с командой позволит сокращать TTM (Time to Market) и быстрее актуализировать контекст и изменения.

Как можно синхронизироваться:

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

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

Для синхронизации есть много форматов:

Какие-то способы коммуникации могут быть регулярными и постоянными, такие как общие дизайн-синки и 1-1 с руководителем, а какие-то — ситуативными, вроде дизайн-спринтов и воркшопов.

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

Как можно синхронизироваться:

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

Стоит пойти от обратного и отметить в первую очередь то, какие шаги не стоит пропускать продуктовой команде:

Нельзя пропускать Сбор данных о задаче (1 этап)

Нельзя пропускать Discovery PBR (Grooming) (2 этап)

Нельзя пропускать Погружение и Design Research (3 этап)

Остальные шаги в зависимости от контекста можно пропускать, например:

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

Список тем для голосования в опросе:

_______

Мои контакты: LinkedIn · Facebook · Twitter