Зачем в команде продуктовый дизайнер — и почему он не только про UI

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

Мы поговорили с двумя продуктовыми дизайнерами: нашим коллегой Павлом Карповым, руководителем группы дизайна Mail.ru Cloud Solutions, и Андреем Корытцевым, который работал над такими продуктами, как Mixpanel и Plaid, а сейчас сотрудничает со стартапами.

Андрей Корытцев: Еще три-четыре года назад профессии продуктового дизайнера в современном понимании не существовало, а UX и UI-дизайнеры были просто частью конвейера, отвечающего за разработку продукта. Стейкхолдеры и продакт-менеджер формулировали проблемы и гипотезы, продакт-менеджер писал спецификации, по ним работали UX и UI-дизайнеры, затем продукт передавали в разработку.

Со временем лидирующие IT-компании увидели пользу в совместной работе дизайнеров, инженеров и менеджеров — так индустрия ушла от конвейерного подхода.

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

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

Павел Карпов: В дизайнерской команде Mail.ru Cloud Solutions всего два человека, обязанности между ними строго распределены: один занимается продуктовой частью, второй — маркетинговой, например, лендингами и промо.

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

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

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

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

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

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

Андрей: Конечно, нужны сильные дизайнерские навыки — умение создавать стильные и красивые интерфейсы, но только ими не обойтись.

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

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

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

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

Павел: Конечно, дизайнеру нужно постоянно развиваться. В Mail.ru Group, например, для этого есть несколько инструментов.

1. Команда. Дизайнер вправе выбирать место, где он будет работать — в продуктовой или дизайнерской команде. У каждого варианта свои плюсы. Если сидишь вместе с дизайнерами, всегда знаешь, над чем работают коллеги. Это позволяет не только вдохновляться и прокачиваться, но и применять в своем продукте лучшие практики, заимствованные у коллег. Если сидишь с продуктовой командой — быстрее погружаешься в продукт, но есть вероятность профессиональной стагнации. Поэтому важно поддерживать баланс. Например, дизайнеры Mail.ru Cloud Solutions находятся рядом с дизайнерами других направлений, а для погружения в продукт есть ежедневные планерки с продакт-менеджерами.
2. Развитие soft и hard skills. Компания предоставляет дизайнеру возможность развивать прямые и косвенные навыки, необходимые для повседневной работы, обучение интегрировано в рабочий процесс.
   
3. Дизайн-ревью и обратная связь. Раз в две недели продуктовые дизайнеры ключевых продуктов компании встречаются на несколько часов. Они рассказывают друг другу о своих наработках и получают обратную связь от коллег. Это важная часть процесса — полезно взглянуть на свою работу глазами других специалистов, далеких от твоего продукта.
   

Андрей: Со времен веб-дизайна осталось мнение, что технически подготовленный дизайнер компетентнее неподготовленного. Наверное, на тот момент так оно и было. Но сегодня существует множество технологий и платформ: и веб, и Android, и iOS, к ним постепенно добавляются AR и VR. Даже инженер не может одинаково хорошо работать одновременно на всех платформах.

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

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

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

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

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

Андрей: Решение зависит от специфики продукта и стадии проекта. Бывают продукты, в которых интерфейс не играет существенной роли или его вовсе нет. Например, компания предоставляет какой-то функционал посредством API. Тогда дизайнер либо не нужен вообще, либо необходим для небольшого участка работы — его обязанности однозначно можно отдать на аутсорс.

Но, предположим, интерфейс — важная часть продукта. В таком случае решение зависит от стадии проекта. Общая практика такая: чтобы сделать MVP (минимально жизнеспособный продукт) и подтвердить основные гипотезы, привлекают агентство или продуктового дизайнера на фрилансе. Выбор между ними зависит исключительно от бюджета. Фрилансер — самый дешевый вариант, но с ним риски выше.

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

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

Общая практика такая: продуктовая команда работает спринтами. И один-два раза за спринт назначают общую встречу для обмена обратной связью. В некоторых командах дополнительно организуют ежедневные короткие стендапы. Каждый член команды рассказывает, что делает, какие у него есть проблемы и вопросы. Обычно ежедневное общение необходимо, если команда распределенная.

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

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