«Сделай кнопку поярче» vs «Ты душишь мое творчество»: как продакту и дизайнеру перестать воевать и работать в связке

Краткая суть (GIST / Summary для быстрого чтения):

В чем проблема: Споры между менеджером продукта (PM) и дизайнером возникают из-за разницы языков. Продакт требует закрыть квартальный KPI и дедлайн, а дизайнер защищает визуальную эстетику и логику сценария.

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

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

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

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

Продакт видит в дизайнере «черный ящик»: сотрудник неделями полирует макеты ради красивого кейса в портфолио и срывает Time-to-Market.

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

Эта статья родилась как дополнение к подробному руководству продуктового дизайнера Андрея Молотова: https://aneoz.ru/knowledge/design-process/ — если вы хотите выстроить прозрачные этапы работы всей продуктовой команды от первой идеи до передачи в прод, рекомендуем изучить первоисточник.

В чем истинный корень конфликта: разбор позиций

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

Когда продакт спускает задачу готовым интерфейсным решением («нарисуй попап»), он лишает дизайнера возможности найти более дешевое и эффективное решение. В ответ дизайнер уходит в глухую оборону и начинает спорить о шрифтах и отступах.

4 шага к созданию слаженного тандема (PM + Product Designer)

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

Шаг 1. Брифрование на берегу: «контракт» до открытия Figma

Работа над любой задачей (за исключением мелких баг-фиксов) начинается с совместного заполнения короткого брифа. Дизайнер не открывает рабочие файлы, пока вместе с продактом они не зафиксируют 4 пункта:

Бизнес-цель: на какие финансовые или продуктовые метрики должна повлиять разработка.

Проблема пользователя: какую конкретную боль человека мы устраняем.

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

Критерии приемки: по каким измеримым показателям мы признаем задачу выполненной.

Бриф фиксируют прямо на первом фрейме в Figma или в карточке задачи в таск-трекере. Если в середине спринта продакт приходит с требованием «переделать всё», дизайнер возвращает команду к брифу-ориентиру.

Инсайт: 20 минут на заполнение брифа на старте экономят до двух недель повторной отрисовки макетов и переписывания кода.

Шаг 2. Разделение треков на Discovery и Delivery

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

Discovery (Исследование и проверка гипотез): продакт, дизайнер и аналитик работают в условиях неопределенности. Они изучают конкурентов, проводят CustDev-интервью и собирают черновые кликабельные прототипы (Lo-Fi) из базовых блоков. Цель — быстро подтвердить или опровергнуть гипотезу без привлечения разработки.

Delivery (Проектирование и передача в код): когда гипотеза подтверждена цифрами, дизайнер прорабатывает чистовые макеты, проектирует крайние состояния (Edge Cases, ошибки сети, пустые экраны) и готовит спецификацию для разработчиков.

Шаг 3. Скоупинг: от «свадебного торта» к «кексу с вишенкой»

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

Как решить проблему через совместный скоупинг:

Дизайнер рисует идеальное видение продукта на будущее («образ результата»).

Затем вместе с продактом и тимлидом разработки они отсекают все второстепенное, оставляя минимально жизнеспособный сценарий (MVP).

Принцип «кекса с вишенкой»: первая версия продукта должна быть компактной, как кекс (решать базовую задачу без сложной обвязки), но обязательно иметь «вишенку» — понятную ценность для пользователя, ради которой фичу вообще создавали.

Шаг 4. Отказ от споров о вкусах в пользу коридорных тестов

Если продакт настаивает на варианте «А», а дизайнер уверен в варианте «Б», не нужно тратить часы на абстрактные споры.

Решение:

Дизайнер собирает за 1 час два интерактивных прототипа в Figma.

Команда проводит «коридорный тест»: показывает оба прототипа 5–6 коллегам из соседних отделов или лояльным клиентам с просьбой выполнить целевое действие (например, оформить возврат товара).

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

Итог: разделение ролей в продуктовой команде

Успешный продукт строится на балансе двух равноправных ролей:

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

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

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

Чтобы пошагово настроить этапы работы, внедрить прозрачные артефакты и регламентировать взаимодействие между бизнесом, дизайном и разработкой, используйте практический гайд: https://aneoz.ru/knowledge/design-process/

😊 Донат. На чаёк с печеньками! ☕ 🍪 2200 1907 9562 7952 Мир

Добавить комментарий