PM × Design: как работать вместе
PM × Design: как работать вместе
Section titled “PM × Design: как работать вместе”В разделе «UX и управление опытом»
Роли PM и Design: кто за что отвечает
Section titled “Роли PM и Design: кто за что отвечает”Product Manager (PM) и его задачи
Section titled “Product Manager (PM) и его задачи”Product Manager определяет, какую проблему решает продукт, для кого он нужен, и как этим займется команда. PM отвечает за понимание рынка, пользователей и бизнес-целей. Регулярные задачи — приоритизация фич, гипотез, согласование целей с бизнесом.
Пример: если необходимо увеличить оплату подписки на 15%, PM уточняет, кто ключевая аудитория, что им мешает платить, какую проблему надо устранить.
Product Designer (UX/UI) и его зона
Section titled “Product Designer (UX/UI) и его зона”Дизайнер отвечает за то, как продукт выглядит и ощущается. Цель — чтобы пользователь без боли достиг своих задач. Это включает создание прототипов, тестирование, сбор обратной связи и постоянные улучшения интерфейса.
Пример: пользователь слишком долго ищет кнопку оформления заказа. Дизайнер исследует паттерны взаимодействия, предлагает новый макет и тестирует на реальных клиентах.
Успех продукта на рынке возможен только тогда, когда выявлены реальные пользовательские проблемы и найдено оригинальное, простое решение
Julie Zhuo, экс-руководитель по дизайну Facebook, The Making of a Manager
Быстрые принципы эффективной работы
Section titled “Быстрые принципы эффективной работы”Совместное формулирование целей
Section titled “Совместное формулирование целей”PM и Designer обсуждают, как продукт должен работать с точки зрения бизнеса и пользователя. Обсуждение начинается с общей карты CJM (Customer Journey Map) и гипотез по улучшению опыта.
Мини-кейс: запуск новой онбординг-страницы. PM приносит данные о первом входе в продукт, дизайнер предлагает новые шаги на основе паттернов UX. Вместе проводят юзабилити-тест, смотрят, как проходят новые пользователи.
Общие ритуалы и документация
Section titled “Общие ритуалы и документация”Оптимальная совместная работа строится на регулярных встречах: grooming идей, совместные дизайн-ревью, проверки решений на этапе прототипа. Важно фиксировать договоренности (Notion, Confluence) по структуре задач, чтобы не возникало споров на последних этапах.
Пример: на воркшопе команда договаривается о главных юзер-персонах и использует один шаблон CJM.
Ошибки и антипаттерны
Section titled “Ошибки и антипаттерны”Игнорировать мнение дизайнера при планировании фич
Section titled “Игнорировать мнение дизайнера при планировании фич”Когда PM определяет приоритеты без консультации с дизайнером, появляются необработанные сценарии и слабый пользовательский поток.
Реплика: запуск новой функции, которая визуально отличается от основной системы, увеличил тикеты в саппорт на 30%.
Формальный подход к UX-исследованиям
Section titled “Формальный подход к UX-исследованиям”Дизайнер передает исследования PM только ради галочки, а не для реальных изменений. Итог — продукт не лучше, а проект стопорится.
Мини-кейс: после A/B-теста форму упростили, но на действия пользователей это не повлияло — ключевой инсайт из исследований не учтен в Roadmap.
Совместные артефакты и каналы связи
Section titled “Совместные артефакты и каналы связи”CJM, user stories, дизайн-системы
Section titled “CJM, user stories, дизайн-системы”Главное — иметь прозрачный стек инструментов. PM следит за user stories и бритью backlog, дизайнер развивает дизайн-систему и прототипы. Важно договариваться о правилах: где смотреть финальные макеты, кто что апрувит, как фиксировать эксперименты.
Пример: в Miro совместно собирают карту пути пользователя, договариваются по узким местам, в Figma — финальный прототип. Решения по догадкам не оставляют — только после теста.
Быстрые синки и ревью
Section titled “Быстрые синки и ревью”Оперативная связь важнее долгих согласований. Регулярные короткие calls позволяют решать вопросы по ходу, а не ждать еженедельных встреч.
Чем чаще команда сверяет видение и уточняет детали на ходу, тем стабильнее темп и меньше конфликтов
Jared Spool, CEO User Interface Engineering, uie.com
Как не потерять пользователя между менеджером и дизайнером
Section titled “Как не потерять пользователя между менеджером и дизайнером”Прозрачное исследование и обратная связь
Section titled “Прозрачное исследование и обратная связь”Все инсайты и пользовательские боли обсуждаются открыто, обе стороны комментируют выводы исследований. Проверяют, что решения не только функциональны, но и приятны пользователю.
Пример: совместно расставляют приоритеты — даже простая техническая фича может изменить NPS, поэтому нужны быстрые тесты и валидированные решения.
Метрики через призму UX
Section titled “Метрики через призму UX”Важно отслеживать не только бизнесовые показатели (вроде LTV или MAU), но и UX-метрики: время первого успеха (time to first value), число ошибок на шаге, NPS, CSAT. Основные бенчмарки и цифры зависят от отрасли. Метрики смотри, например, в Lean Analytics и NNG UX KPIs.
Что делать, если PM и дизайнер не согласны по варианту решения?
Идти через прототипы и тесты. Реальный пользователь покажет, что лучше.
Когда привлекать дизайнера — до или после Roadmap?
Дизайнер должен быть вовлечен в обсуждение гипотез и приоритизацию с самого начала, не только на этапе отрисовки.
Какие документы важно вести совместно?
CJM, personas, hypothesis backlog, тестовую документацию, ключевые выводы по UX-результатам.
Как оценить качество взаимодействия PM и Design?
По скорости принятия решений, числу конфликтов по макетам, % гипотез с реальной user value.
На что ориентироваться в UX-метриках?
Time to first value, NPS, CSAT, конверсия в ключевые действия, % ошибок/отказов.
Где искать примеры и гайды по ритуалам работы PM и Design?
Хорошие кейсы и подходы — NN Group о ритуалах в UX и Product Design at Scale.