Продакт-менеджер проектирует продукт так, чтобы он работал на бизнес-цели. Своё взаимодействие с дизайнером он строит тоже с учётом этого. А дизайнеры иногда видят в этом «мне неважно твоё мнение, сделай, как сказали». Особенно если продакт просит переделать макет ещё раз и ещё — хотя, по мнению дизайнера, он сделал красиво и правильно. В итоге время уходит на споры и конфликты.
<<work-with-developers-checklist>>
В статье — о том, какие и почему между продактом и дизайнером возникают проблемы, как им строить продуктивное взаимодействие и работать на эти самые цели бизнеса вместе.
Проблема 1. Продакт-менеджер и дизайнер не договорились, кто за что отвечает
Ситуация. Продакт-менеджер приходит к дизайнеру с задачей добавить в приложение баннер с акцией. И это нужно сделать быстро, так как акция стартует завтра. Дизайнер вместо того, чтобы просто вставить баннер, начинает править весь сценарий, так как, по мнению дизайнера, он устарел и его нужно обновить. В итоге на отрисовку уходит больше времени и баннер не появляется в приложении вовремя. Стороны конфликтуют. Вся ответственность при этом — на продакте, так как он отвечал за то, чтобы задачу выполнили в срок.
Решение. Продакт-менеджеру нужно обозначить, где его зона ответственности, а где — дизайнера. Если эти зоны где-то пересекаются, договориться, как будут действовать.
Андрей Шанский, Lead Designer, Core Banking, Sberbank:
Основное недопонимание продактов и дизайнеров происходит потому, что у них разные DoD’ы — критерии успешности их работы. Продакт-менеджеру нужен приемлемый результат в кратчайшие сроки с минимальной затратой ресурсов, а дизайнер хочет сделать для пользователя, красиво, переделать весь пользовательский путь, всё выровнять — вот вам явный конфликт.
Продакт-менеджер отвечает за то, чтобы развитие продукта соответствовало стратегии компании и приносило измеримые результаты: продажи, новых клиентов,увеличение доли на рынке. Ему нужно — запускать и развивать продукты, которые будут приносить компании деньги.
Дизайнер продукта решает проблему пользователя через интуитивно понятный интерфейс. Делает так, чтобы пользователям было удобно пользоваться продуктом и совершать покупки.
Представили обязанности продакт-менеджера и дизайнера в таблице. По списку обязанностей есть пересечения — они выделены фиолетовым цветом. И это потенциальные зоны конфликтов.
Чтобы избежать конфликтов там, где обязанности пересекаются, лучше заранее обсудить, как действуют в похожих ситуациях и кто принимает решение. Например, если у дизайнера есть опыт в исследованиях, он может проводить их сам и презентовать результаты команде. Это поможет ему лучше разобраться в том, что действительно нужно пользователям, а продакт-менеджер покажет, как это связано с бизнес-целями. Работа станет продуктивнее.
Ещё вариант — какие-то задачи продакт-менеджер и дизайнер могут делать совместно, например:
- Анализировать вводные от бизнеса, проводить исследования на разных этапах, собирать обратную связь от пользователей.
- Продумывать сценарии использования и на их основе проектировать интерфейсы, корректировать и улучшать их.
- Организовать исследование, чтобы проверить эффективность интерфейса. Например, usability-тест или A/B-тест.
- Работать с разработчиками, чтобы понимать технические ограничения и особенности внедрения дизайна в продукт.
- Продуктовый дизайнер может отдавать на ревью продакт-менеджеру готовые макеты с проработанным UX- и UI-дизайном, чтобы получить обратную связь и внести коррективы.
Дмитрий Исаев, Product design team lead, Avito, founder isfirst agency:
Продакт управляет ростом и развитием продукта, делает всё возможное, чтобы продукт начал приносить прибыль, поэтому он думает о бизнесовых метриках. А дизайнер — это адвокат пользователя с точки зрения визуального опыта и удобства интерфейса. Продакт заботится о дешёвых решениях, о скорости выкатывания на прод. А дизайнеру зачастую важно при этом сделать не только дешёвые, но красивые и удобные для пользователей решения.
Есть хорошая фраза — «слушаем всех, но берём только то, что считаем важным». Если возникают конфликты, важно вытащить из них конструктив. Например, когда продакт комментирует визуал, поинтересоваться, что его смущает. Уметь отделять личные, не подкреплённые аргументацией замечания. Например, в случае, если продакт просто говорит, что иллюстрация некрасивая. Я хочу сказать, что комментарии команды — это ок, но важно определить зоны ответственности дизайнера с продактом и донести до последнего, что визуал — ответственность дизайнера.
Проблема 2. Продакт-менеджер не погружает дизайнера в свой контекст
Ситуация. Команда разрабатывает новое приложение для планирования задач. Продакт-менеджер провёл исследования и говорит, что ключевой функцией должно быть автоматическое распределение задач по дням на основе их сроков. Это будет конкурентным преимуществом продукта, которое привлечёт пользователей.
Дизайнер не знает, почему важно сделать такую функцию. Вместо этого сосредоточился на том, чтобы приложение выглядело интуитивно понятным, поэтому предложил сделать так, чтобы пользователь сам добавлял задачи и мог просто перетаскивать их по дням. По мнению дизайнера, это улучшит пользовательский опыт. С другой стороны, в интерфейсе станет сложнее реализовать автоматическое распределение задач по дням, которое предлагает менеджер.
Проблема в разном контексте. Продакт-менеджер отвечает за стратегию продукта, поэтому фокусируется на бизнес-целях, исследованиях, анализе рынка и конкурентов. Дизайнер сосредоточен на том, чтобы создать удобный и приятный интерфейс для пользователя.
Решение. Продакт-менеджер должен давать дизайнеру как можно больше контекста: откуда возникла конкретная задача, какую проблему мы решаем, что уже есть, а что предстоит сделать. Например:
«Я хотел бы обсудить наш новый проект по созданию приложения для путешествий. Вот несколько деталей, которые помогут тебе лучше понять контекст:
- Целевая аудитория: пока мы не углублялись, но думаем, что наше приложение для молодых людей в возрасте от 18 до 35 лет, которые любят путешествовать и ищут удобные решения для планирования поездок. Они часто используют социальные сети для обмена впечатлениями.
- Проблема, которую мы решаем: заметили, что большинство существующих приложений слишком сложные и перегружены информацией. Пользователи хотят простой и интуитивно понятный интерфейс, который позволит им быстро находить и сохранять интересные места, маршруты и советы.
- Ключевые функции. Планируем реализовать:
- удобный поиск и фильтрацию мест;
- возможность создавать собственные маршруты;
- раздел с рекомендациями от пользователей и возможность делиться своим опытом;
- интеграцию с картами для навигации.
- Сроки: у нас есть 4 недели на разработку прототипа, и я бы хотел, чтобы ты подготовил первые макеты через две недели и мы могли обсудить их с командой».
Ещё важно объяснять, почему нужно сделать именно так, а не иначе. Например, добавить в приложение функцию «Избранное», чтобы пользователи сохраняли интересные объекты — места, маршруты, услуги — в отдельный список. Тогда стоит объяснить, для чего нужна функция:
- Чтобы пользователям было проще возвращаться к объектам, которые их интересовали.
- Увеличить время пользования приложением.
- Подготовиться к тому, что позже в приложении появится возможность планировать поездки.
Дальше добавить, что дизайнеру нужно учесть при реализации:
- Функция «Избранное» должна быть интуитивно понятной и легко доступной.
- Значок для добавления в «Избранное» должен быть заметным и узнаваемым, например звезда или сердечко.
- Должно быть визуальное подтверждение, что элемент добавлен, например изменение цвета значка или появление уведомления.
- Нужно сделать отдельный раздел в меню или вкладке для доступа к списку «Избранное».
- Пользователям должно быть легко управлять своими сохранёнными объектами (удалять, сортировать, фильтровать).
Оксана Бакланова, Head of Information & Back Office, Emex:
Важно давать дизайнеру как можно больше контекста: показывать, как пользователь будет работать с функционалом, и аргументировать решение метриками, результатами исследований. Тогда дизайнер будет не просто создавать красивый, а строить пользовательский опыт, который отвечает бизнес-цели.
Это особенно важно, если у дизайнера в команде нет продуктового мышления, то есть он не понимает, какие инсайты можно вытащить из интервью с пользователями или метрик. В таком случае, если дать больше контекста и объяснить, зачем предлагаешь конкретное решение, вы с дизайнером можете вместе подумать, как сделать результат лучше.
Проблема 3. Продакт-менеджер недостаточно вовлекает дизайнера в процесс
Ситуация. Дизайнер не участвует в этапе discovery, его не привлекают к обсуждению дорожной карты и задачи в целом. Он может не интересоваться этим сам, либо его не вовлекает в процесс продакт-менеджер. В итоге дизайнер не знает контекст и может нарисовать интерфейс, который не отвечает цели продакт-менеджера.
Например, команда работает над тем, чтобы сделать инвестиционный продукт доступным для массовой аудитории. Это новая гипотеза, которую в начале квартала сформулировали без дизайнера. Продакт провёл исследование массовой аудитории, чтобы лучше узнать новых пользователей и их потребности, но не привлёк к исследованию дизайнера. Тот не знал об этом и продолжал считать, что продукт направлен на опытных инвесторов, поэтому предложил новый онбординг с профессиональными терминами, которые понятны только тем, кто погружен в тему. В итоге пришлось потратить дополнительное время, чтобы исправить тексты и сделать их понятными для массовой аудитории.
Решение. Привлекать дизайнера как можно раньше на этапе проработки задачи. Чем раньше он поймёт и начнёт вовлекаться и разбираться с задачей, тем лучше будет результат. Тогда у продакт-менеджера и дизайнера будет одинаковый контекст и понимание, чего нужно достичь в результате — это сократит количество итераций работы.
У продакт-менеджера может быть много идей, их лучше оценивать сразу со всей командой. Например, дизайнер сможет составить примерное представление, как будет выглядеть продукт, а разработчик обозначит возможные технические ограничения.
<<prodakty-telegram-kanal>>
Например, компания создаёт приложение для организации мероприятий. Продакт-менеджер, дизайнер и разработчик собираются, чтобы обсудить идею приложения:
- Продакт-менеджер представляет концепцию: «Мы хотим создать приложение, которое поможет пользователям планировать и управлять мероприятиями, будь то дни рождения, свадьбы или корпоративы. Думаю, что нужно сделать акцент на лёгкости использования и возможности интеграции с календарями».
- Дизайнер подключается к обсуждению, задавая вопросы о целевой аудитории: «Какие проблемы мы решаем для пользователей? Каковы их основные боли при организации мероприятий?» Предлагает провести исследование, чтобы лучше понять, какие функции будут наиболее востребованы.
- Разработчик поднимает вопросы о безопасности данных.
Вместе они обсуждают, какие функции лучше реализовать. Например, создавать и редактировать мероприятия, интегрировать приложение с картами и календарями, делать интерактивные приглашения и RSVP — запрашивать подтверждение от приглашённого.
В конце встречи три стороны приходят к согласию, что фокус приложения должен быть основан на интеграции с картами и календарями и на персонализации. Ещё они определяют минимальный набор функций приложения: изучают, какие функции есть у продукта-конкурента, проводят исследования.
Оксана Бакланова, Head of Information & Back Office, Emex:
Сложности были в том, что дизайнер ожидал, что продакт принесет готовую, описанную задачу и пользовательский путь, а он просто сделает визуальный дизайн и все. Иногда проблема здесь кроется в том, что продакт не всегда понимает, как построить хороший пользовательский опыт — это компетенция дизайнера. Поэтому дизайнер должен участвовать на всех этапах проработки решения и продумывать все вместе с продактом. Продакт и дизайнер — это партнеры, а не заказчик и исполнитель.
Раньше многие дизайнеры, с которыми я встречалась, сторонились исследований и контактов с пользователями — как будто боялись узнать, что плохо что-то спроектировали. Другие дизайнеры избегали прямой коммуникации с пользователем, так как не имели навыков проведения интервью. Им было сложно начать разговаривать с незнакомым человеком и столкнуться с негативной обратной связью.
Очень помогли курсы по проведению исследований для дизайнеров. Также расширили штат исследователей: сажали их в команды и встраивали в процесс проработки задачи. Дизайнеры вместе с ними проводили исследования, изучали и проверяли пользовательский опыт, поэтому постепенно втянулись.
Ещё важно не терять контакт после релиза:
- Дизайнер поможет проанализировать поведение пользователей. Вместе с ним можно изучить время, проведённое в приложении, и проследить путь пользователя, чтобы выявить проблемные участки и улучшить интерфейс.
- После запуска продукта можно собирать отзывы от пользователей. Продакт-менеджер и дизайнер смогут проанализировать эти отзывы и собрать идеи, как улучшить продукт. На основе обратной связи дизайнер может предложить решения, которые будут учитывать, чем довольны и недовольны пользователи.
- После успешного релиза всегда возникает необходимость в новых функциях или обновлениях. Поэтому продакт-менеджер и дизайнер смогут вместе разработать стратегию для следующих итераций, учитывая предыдущий опыт и данные пользователей.
Оксана Бакланова, Head of Information & Back Office, Emex:
Ещё важно, чтобы дизайнер не выходил из задачи после релиза. Я всегда стараюсь вовлекать дизайнера в тот результат, который мы получили. Во-первых, если результат хороший, то это позитивная обратная связь не только от команды, а еще и от пользователя. Во-вторых, в случае негативной обратной связи она делится в равной степени между продактом и дизайнером. Они могут вместе подумать, что еще сделать, чтобы стало лучше.
Проблема 4. Продакт-менеджер относится к дизайнеру как к исполнителю
Ситуация. «Мы всё придумали — осталось только нарисовать», — с таким посылом продакт-менеджер приходит к дизайнеру, приносит готовые решения или макеты. Для него дизайнер — исполнитель, просто руки, которые рисуют готовые макеты, мнение дизайнера не учитывается, его не подключают к проработке задаче.
Такой подход мешает увидеть проблемы пользовательского пути, который незаметны команде, но видны дизайнеру. Например, если приложение для всей семьи, то очень часто забывают сделать его доступным для пожилых людей. Такое приложение обязательно должно отвечать требованиям accessibility, то есть быть таким, чтобы им могли пользоваться те, у кого проблемы со зрением, слухом, памятью, опорно-двигательным аппаратом. И дизайнер может подсветить необходимость таких функций, если приложение для всей семьи.
Решение. Дизайнеру и продакту важно договориться об этапах работы дизайнера. В каждой команде дизайнеры по-разному организуют процесс, но есть и общие вещи. Британский совет по дизайну (British Design Council) исследовал и собрал их вместе. В итоге получился инструмент, который может помочь не только дизайнерам, но и менеджерам проекта в организации, структурировании и управлении проектами.
Этот инструмент называет «Двойной бриллиант» (Double Diamond). Суть подхода заключается в четырёх этапах работы, на каждом из которых у дизайнера есть своя роль:
- Открытие (discover): дизайнер понимает, в чём заключается проблема, он проводит интервью с пользователями, участвует в исследованиях.
- Определение (define): информация, которая была собрана на прошлом этапе, помогает формулировать проблему. Например, команда разрабатывает приложение для управления личными финансами и после исследований понимает, что основная проблема не в том, что пользователи забывают о расходах, а в том, что им трудно оценить их общее финансовое состояние. Тогда проблему формулируют более точно: «Пользователям нужен инструмент, чтобы следить за расходами и доходами».
- Разработка (develop): дизайнер и его команда предлагают различные решения чётко определённую проблемы. Например, решают, какие функции добавят в приложение: автоматическое отслеживание доходов и расходов, графики, интеграция с приложениями банков для автоматической загрузки транзакций.
- Выпуск (deliver): тестирование разных решений на небольшой аудитории, отсечение решений, которые не работают, и улучшение тех, которые будут работать. Например, команда проводит пилотное тестирование прототипов на ограниченной выборке пользователей (допустим, 50–100 пользователей). Потом собирает отзывы и анализирует, какие функции полезны и понятны, а какие вызывали путаницу или проблемы. На основе этого дорабатывают приложение, улучшают функциональность и убирают те функции, которые не показали своего значения или не были понятны пользователям.
Оксана Бакланова, Head of Information & Back Office, Emex:
Когда к дизайнеру относятся уважительно и используют его не как сервис, а как члена команды, результат работы получается намного лучше. Когда продакт конфликтует с дизайнером, это говорит о том, что у продакта ещё мало опыта.
Опытный продакт принимает решения исходя из целей бизнеса, обоснования через аналитику, исследования, бенчмарками или анализ конкурентов и рынка. Я не видела ни одного продакта, который будет действовать только на основе своей интуиции. Коммуникация должна строиться на основе хорошо проведенного дискавери.
Проблема 5. Продакт-менеджер не стремится к общению с дизайнером и не налаживает с ним контакт
Ситуация. Продакт-менеджер недостаточно общается с дизайнером. Из-за этого возникают разные проблемы. Например, дизайн занимает слишком много времени, хотя нужно было отрисовать пробный макет. Или дизайнер не получает ответы на свои вопросы. В итоге тоже делает не то, что ожидает продакт-менеджер. Время потрачено, а задача не выполнена. Или продакт не идёт на контакт с дизайнером: общается только письменно, из-за чего каждая итерация правок любой фичи занимает в несколько раз больше времени, чем если бы они один раз обсудили всё на созвоне.
Андрей Шанский, Lead Designer, Core Banking, Sberbank:
Бизнесовая часть всё равно главная, бизнес даёт деньги на продукт. Но дизайнеры ближе всего к клиенту, поэтому им проще его понять. Они буквально чувствуют и визуализируют путь клиента до продукта и видят все проблемы. Поэтому продакту и дизайнеру важно подружиться, чтобы последний воспринимался не как раздражитель, а как эксперт и дополнительный источник информации.
Решение: соблюдать основные принципы коммуникации с дизайнером и обсуждать с ним приоритеты и контекст задач.
1. Общаться через референсы и антиреференсы. Мало кто их использует в работе, но они хорошо работают. Берём примерные визуалы, которые нравятся, те пользовательские пути, которые нравятся, и даём их потестить. В итоге у нас получался результат сильно лучше, чем у других продактов.
Кроме референсов, можно использовать антиреференсы — показывать, как делать не нужно. Иногда они работают лучше, поскольку референсы вызывают желание сделать так, как на них показано. Особенно когда на задачу отведено мало времени. Антиреференс заставляет подумать и даёт дизайнеру больше простора для творчества.
2. Обсуждать приоритеты при постановке задач. Например, команда работает над обновлением мобильного приложения по управлению временем. У продакт-менеджера есть список функций для внедрения: доработать напоминания, перепроектировать главную страницу, добавить функции календаря. Передавая задачи дизайнеру, продакт-менеджер уточняет приоритеты:
- В первую очередь работаем над напоминаниями: по исследованиям, к этой функции больше всего интереса у пользователей, и она повысит вовлечённость.
- Дальше тестируем обновления главной страницы: исследования показали, что некоторым пользователям неудобно ей пользоваться. Это задача со средним приоритетом.
- Затем внедряем календарь, такая функция есть у конкурентов. Перед тем как её реализовывать, проведём исследования: проверим, насколько эта функция действительно важна пользователям. Это задача с низким приоритетом.
3. Не персонифицировать, то есть не «присваивать» продукт себе. Продукт — это то, над чем команда работает вместе. Если продакт-менеджер или дизайнер думают, что это их личный продукт, возникают проблемы. Например, решения принимают предвзято, исходя из своего видения, не учитывая исследования, цели и мнение других специалистов.
Кроме этого, когда один человек считает, что «владеет» продуктом, это останавливает поток идей от других членов команды — все решения опять же принимает кто-то один. Плюс у других членов команды это может вызывать недовольство: «Почему он считает этот продукт своим и не учитывает нашего мнения?».
Дмитрий Исаев, Product design team lead, Avito, founder isfirst agency:
Думаю, что продакту и дизайнеру важно понимать, что они партнёры, а не заказчик и исполнитель. В таком случае они оба будут на одной стороне, где каждый переживает за продукт. Из этой точки они могут прийти к оптимальному решению, которое принесёт нужный результат. Когда продакт и дизайнер работают как партнёры, они могут дать друг другу честную обратную связь и подсветить, где и кто недотягивает или делает неправильно.
4. Не стучать в закрытую дверь. Если дизайнера не получается убедить даже аргументами, надо дать ему дойти до результата и самому увидеть, что решение было неудачным. При этом зафиксировать, какие были договорённости, что предлагал продакт-менеджер, а что дизайнер, какое решение в итоге внедрили и к чему оно привело.
Например, продакт-менеджер предложил добавить фильтр отзывов по положительным и отрицательным. По его мнению, так пользователи быстрее найдут отзывы, которые для них важны, и им легче будет воспринимать информацию. Дизайнер не согласился: по его мнению, это может отвлечь от общего положительного восприятия товара и лучше оставить общую ленту отзывов.
В итоге решили провести A/B-тест. Увидели, что в версии с фильтром люди оставили на 70% больше отзывов. Провели там на 40% больше времени, а число покупок оказалось выше на 10%. Дизайнер на цифрах увидел, что его предложение было неудачным, и вернулся к обсуждению решения продакт-менеджера.
В такой ситуации важно именно обсуждать, как действовать дальше, и не допускать таких разногласий в будущем. То есть продакт-менеджеру не стоит бросаться фразами вроде «я же говорил». И это работает в сторону как дизайнера, так и продуктового менеджера — в зависимости от того, чьё решение оказалось неудачным.
Андрей Шанский, Lead Designer, Core Banking, Sberbank:
Когда начинаешь объяснять, почему решение продакта неудачное, он не всегда соглашается, даже если есть аргументы. В таком случае я говорю: «Вот как тебе нужно, но вот как будет удобнее для пользователей или как быстрее сделают разработчики. Делай, как решил, но через два этапа ты всё равно придёшь ко мне, я скажу тебе то же самое, и мы вернёмся к тому, с чего начинали». То есть надо, чтобы продакт сам проверил своё решение и понял, что на старте стоило прислушаться к дизайнеру.
На начальных этапах это конфликтные ситуации, в последующем — маленькие победы и кредит доверия. Сначала это похоже на постоянные объяснения, а дальше этого всё меньше и меньше, и дизайнеру начинают доверять без дополнительных аргументов.
5. Не усложнять работу и помогать друг другу. Например, есть договорённость, что дизайнер проведёт общую встречу с командой и покажет текущие результаты работы. Но сейчас он параллельно погружается в другой проект и не успевает прийти на встречу. Если продакт-менеджер хорошо погружён в проект, он может подстраховать дизайнера и презентовать результаты вместо него. Это здорово помогает команде.
6. Использовать неформальные приёмы. Например, вместе проводить перерывы на кофе или обед, где обсуждать не только работу, но и то, что происходит в жизни. Создавать отдельные чаты, где делиться идеями в более непринуждённой обстановке, чем в рабочих чатах. Проводить мозговые штурмы, где любой может высказать мнение о дизайне, функционале и любом другом аспекте продукта, не ощущая давления руководства.
<<prodakty-kompanii-uchenikov>>
Главное, общаться уважительно и без манипуляций. Например, если продакт сначала наладил контакт с дизайнером, а потом пытается протащить задачи вне срока, намекая, что «если не справишься в такие сроки, это повлияет на всю команду», это скорее плохо повлияет на дальнейшую коммуникацию. То же самое, когда продакт ставит задачу без чёткого описания: «У меня мало времени, ты и так знаешь, что делать».
Дмитрий Исаев, Product design team lead, Avito, founder isfirst agency:
Основной принцип совместной работы продакт-менеджера и дизайнера — усиливать друг друга через разные точки зрения на продукт и отраслевую экспертность.
