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

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

У дизайнера:

• Страх белого листа
• Неуверенность в своём решении
• Перегруз задачами
  
• Непонимание приоритетов, целей и пользователей

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

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

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

• Некачественные и неконсистентные решения в макетах и на проде
• Множество итераций дизайна и затягивание сроков
• Непрозрачность и непредсказуемость работы дизайнера и команды
  
• Частые эдхоки и подгоны от бизнеса
• Работа над ненужными задачами
• Отсутствие взаимпонимания, все тянут одеяло на себя
• Плохой NPS и отставание от рынка
  
• Итоговое выгорание всех и вся :'(

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

_______

Разделение на 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:

• Product Discovery — продуктовый менеджер, продуктовый дизайнер, бизнес аналитик и UX-исследователь
• Research — UX-исследователь, продуктовый менеджер, продуктовый дизайнер и бизнес аналитик
• Design — продуктовый дизайнер, UX-редактор и UX-исследователь

Команда Delivery:

• Development and QA — Backend, Frontend и QA инженеры, тимлид и техлид

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

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

• Продуктовый роудмап со списком инициатив — задача от такого источника уже на входе имеет высокий приоритет и фактуру
• Любые источники User Voice — отзывы в сторах приложений, служба поддержки, результаты качественных исследований и т.д.
• Сигналы от аналитики или бизнеса — задача на рост какой-либо важной метрики или показателей
• Рыночные исследования — анализ конкурентов и рынка, отставание от Market-Normal, инсайты от маркетинга
• Продуктовые гипотезы и экспертные мнения команды
• Баг или старый продуктовый долг

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

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

• CustDev и JTBD-интервью
  
• Результаты прошедших UX-интервью с пользователями
• Прямые жалобы пользователей на проблемы из разных источников
• Количественные данные — опросы и метрики продукта
• Проблемные места CJM

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

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

• Отставание от рынка по данным бенчмарков
• Рост ключевых метрик бизнеса и продукта

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

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

• Помогает продуктовому менеджеру и UX-исследователю, лидирующим на этом этапе, находить боли пользователя и продукта с помощью своей накопленной экспертизы
• Участвует или проводит CustDev / JTBD-интервью, если позволяет загруженность
  
• Может сгенерировать первичные гипотезы решения, если хватает данных на этом уровне погружения
  

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

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

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

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

• Рассматривает задачи, которые ещё не попали в спринт дизайна
• Уточняет недостающую информацию
• Приоритизирует задачи в соответствии с продуктовой и дизайн-стратегией — использует RICE / ICE Scoring, User Story Map, КАНО и другие фреймворки или их комбинацию
• Оценивает задачи в рамках своих функций, предварительно разделив крупные и непонятные задачи на мелкие
  

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

• Боли пользователя
• Проблемы бизнеса
  
• Сигналы о болях пользователей и их источники
  
• Критерии успешности решения — что команда считает решённой задачей и как измеряется успех
  
• Ограничения — технические, продуктовые, бизнесовые и другие
• Дедлайн — если есть конкретная дата, например — маркетинговая кампания или запуск временной акции
  
• Артефакты — ссылки на связанные с задачей исследования, аналитику, CJM и другие артефакты
  

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

• «А сделай как у конкурента...» — это апелляция к существующему решению на рынке без полного понимания контекста конкурента
• «Есть такая гипотеза, давай по ней сделаем макет…» — дизайнер сначала челленджит гипотезы и предлагает свои, а потом прорабатывает решение
• «Я (продакт) тут нарисовал схему, сделай для неё UI…» — дизайнер сам проектирует решение, и если зафреймиться на одном варианте — итоговое решение может быть значительно менее эффективным, чем придуманное дизайнером с нуля

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

• Проверяет достаточность информации в задачах — DoR
• Дополняет задачу своими гипотезами и экспертными знаниями
  
• Челленджит существующие вводные и гипотезы
  
• Помогает в приоритизации болей пользователей
  
• Декомпозирует на этапы, если задача получается большой, например — поиск решений, создание концепции и разработка финального решения
• Оценивает задачу и/или этапы задачи
  

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

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

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

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

• Разбирается во всех вводных и артефактах задачи
• Обращается к продуктовой и дизайн-стратегии
  
• Смотрит на CJM продукта, на аудиторию продукта и персоны, на сам продукт, на продукты смежных команд
• Смотрит на метрики и результаты исследований
• Следит за рынком и за конкурентами
  
• По ситуации обращается к другим артефактам продукта
  

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

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

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

• Текстовые и графические варфреймы
  
• Драфты и скетчи решения
  
• Структура данных и переходы экранов — User Flow
• Макеты основных экранов из компонентов дизайн-системы
• Другие фреймворки
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Команда продукта и разработки готова вкладываться в максимальное качество продукта и создавать решение с бескомпромиссным UX, которое может потребовать дополнительное время на реализацию

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

• Команда разработки и продукта готова создавать MLP решение и брать на доработку целевое решение, если оно докажет ощутимый прирост удобства для пользователей и потенциал роста будущих метрик

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

• Фидбек от дизайн-департамента, помогающий зачелленджить решение, выявить спорные моменты и улучшить дизайн
• SbS (Side-by-Side) тестирование — количественное исследование, где респонденты выбирают одну из нескольких картинок
  
• Проверить качество решения самому по эвристикам Нильсена

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

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

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

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

• Использовать чек-листы для проверки макетов перед передачей в разработку — проработаны ли все корнер-кейсы, нулевые состояния и т.д.
• Привлекать QA к финальному этапу разработки макетов для проверки покрытия всех состояний продукта
• Финально синхронизировать решение с дизайн-департаментом, с продуктовой командой и командой разработки
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• UX-Feedback для количественных опросов пользователей о продукте, который мог быть внедрён уже на этапе A/B тестирования
• User Voice — фидбек в отзывах сторах мобильных приложений, тикеты о проблеме от служба поддержки
• Статистически значимые метрики по продукту

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

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

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

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

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

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

• Демо продукта или дизайн-демо
• 1-1 с продуктовым менеджером
• Discovery PBR
• Daily Stand-Ups

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

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

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

• Общие дизайн-синки в компании, на которых стоит регулярно выступать, чтобы получать полезный фидбек и прокачивать навык презентаций
• 1-1 со своим дизайн-руководителем и дизайнерами других команд
  
• Дизайн-спринты — фасилитируемая совместная работа над продуктом с другими дизайнерами и участниками продуктовой команды
• Брейнштормы и воркшопы — совместная работа дизайнеров над концептами или решениями
• Парный дизайн — работа двух дизайнеров над одной задачей
• Дизайн-ревью от других дизайнеров
• Демо смежных продуктовых команд

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

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

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

• Delivery PBR — регулярная встреча, похожая на Discovery PBR, на которой обсуждают будущие задачи для команды разработки. На этой встрече можно презентовать свои ранние концепты или решение на более поздней стадии, чтобы команда могла подготовиться к будущим задачам, задать вопросы по реализации и повлиять на решение.
• Индивидуальные синки с разработчками и QA
• Дизайн-ревью по задаче разработчика
• Демо продукта и дизайн-демо, на которые стоит звать разработчиков
  

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

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

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

• Можно начать решать несуществующую боль или делать ненужный продукт, что в итоге сильно повлияет на Time to Market

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

• Disco PBR — один из ключевых этапов синхронизации Discovery команды, где происходит уточнение задач, их приоритизация и декомпозиция. Без этого этапа команда может сильно расфокусироваться, мыслить в разных направлениях и заниматься задачами, которые не приносят значимой пользы бизнесу или пользователям.
  
• Если задача не подготовлена до необходимого уровня DoR, это ощутимо замедлит TTM, поскольку дизайнеру придется тратить много времени на изучение и понимание задачи после того, как она уже взята в работу
  

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

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

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

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

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

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

1. Как продуктовому дизайнеру выжить и расцвести в большой компании
   
2. Почему дизайнеры занимаются ненужной работой
   
3. Как повысить осознанность команды с помощью дизайн-стратегии
   
4. Как сделать редизайн, от которого не заплачут пользователи и бизнес
5. Как понять, нужен ли ребрендинг именно твоему продукту?
6. Как быстро сделать продающее портфолио дизайнера в Notion
   
7. Харды и база для продуктового дизайнера на 2024 год
   
8. Как вдохновляться продуктовому дизайнеру? (не Dribbble и не Behance)
   
9. Актуальные ресурсы для продуктового дизайнера на 2024
   

_______

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