Вступление
Я замечал неоднократно, что многие известные мне юиксеры оказываются музыкантами. Сначала это выглядело как просто случайное совпадение, но сейчас я уверенно предполагаю как причину наблюдаемого эффекта развитую дивергентную природу мышления этих людей. Вот, и давайте попробуем поговорить о продуктовой разработке на примере метафор из музыкальной сферы. Представьте себе оркестр. Скрипач виртуозно выводит соло, флейтист парит в высоких нотах, ударник задает бешеный ритм, а дирижер страстно размахивает палочкой. Проблема только в том, что каждый играет разную симфонию, а партитуру съел бульдог. Это метафора для продуктовой команды, которая вроде бы движима благой целью — угодить клиенту. Но на пути к этой идиллии ее поджидают тернии недопонимания, амбиций и профессиональных деформаций.
Клиенто-центричность — это не магнитик на холодильник, который можно прилепить и забыть. Это сложный, живой и часто болезненный процесс, где сталкиваются мировоззрения четырех ключевых ареопогов: Исследователя (глас клиента), Дизайнера (творец решений), Продакта (повелитель ресурсов) и Разработчика (инженер реальности). Давайте окунемся в их увлекательные производственные конфликты и найдем спасительные рецепты перемирия.
10 эпичных конфликтов и рецепты их разрешения
1. Конфликт: Продакт vs Исследователь — «Мы и так все знаем»
- Суть: Продакт, опасаясь срыва сроков, игнорирует результаты юзабилити-тестов или глубинных интервью, предпочитая положиться на свою «экспертизу» и интуицию. Ценные инсайты уходят в архив, а команда наступает на грабли, которые исследователь уже аккуратно сложил в углу.
- Причина и нюансы: У продакта в голове — карта рисков, сроков, бюджета и требований стейкхолдеров. Новые данные — это новые работы, задержки и сложные разговоры. Его KPI — часто «выпустить вовремя», а не «выпустить идеально». Исследователь же видит свою миссию в том, чтобы не дать команде наломать дров.
- Выход:
Для продакта: Сформулируйте «риски незнания». Спросите себя: «Что будет, если мы не послушаем исследователя? Каковы финансовые и репутационные издержки?». Часто они выше, чем cost of delay.
Для исследователя: Говорите на языке бизнеса. Презентуя находки, начинайте не с «Пользователи не понимают этот паттерн», а с «Мы рискуем потерять 30% конверсии на этом экране, потому что...». Привязывайте инсайты к метрикам, которые волнуют продакта.
Стандарт поведения: Внедрите в процесс «исследовательский спринт» перед началом разработки. Его задача — ответить на ключевые вопросы и снизить риски. Это не «еще одна бюрократическая процедура», а «страховой полис» продукта.
2. Конфликт: Дизайнер vs Исследователь — «Ты мне не указ!»
- Суть: Дизайнер воспринимает дизайн-рекомендации от исследователя как покушение на свою творческую свободу и экспертизу. Возникает конфликт амбиций: кто на самом деле голос пользователя?
- Причина и нюансы: Дизайнер — творец. Он провел сотни часов, продумывая каждый пиксель, выстраивая систему. И тут приходит исследователь с парой цитат из 5 интервью и говорит: «А давай переделаем?». Это больно. Исследователь же видит лишь холодные данные и не всегда понимает контекст технических или дизайнерских ограничений.
- Выход:
Для исследователя: Не давайте готовые дизайн-решения («сделайте кнопку красной»). Давайте проблемы и инсайты («пользователи не видят призыв к действию»). Пусть дизайнер сам найдет креативное решение.
Для дизайнера: Относитесь к исследователю как к союзнику, а не критику. Его данные — это не приговор, а суперсила. Это сырая нефть, которую вы, как дизайнер, можете перегнать в бензин премиум-класса.
Стандарт поведения: Проводите совместные воркшопы по интерпретации данных. Исследователь делится сырыми данными, а дизайнер помогает их осмыслить и придумать решения. Это создает чувство соавторства.
3. Конфликт: Исследователь vs Бизнес — «Я защищаю пользователя, а вы все меркантильные»
- Суть: Исследователь настолько погружается в боли пользователей, что полностью игнорирует бизнес-контекст: монетизацию, стратегию, конкурентов. Его предложения идеальны для пользователя, но разорительны для компании.
- Причина и нюансы: Миссия исследователя — эмпатия. Его редко посвящают в все тонкости P&L (отчета о прибылях и убытках). Он искренне верит, что если сделать продукт идеальным, то деньги придут сами собой. Но бизнес — это всегда компромисс.
- Выход:
Для исследователя: Всегда задавайте продакту и стейкхолдерам вопрос: «Какие бизнес-цели мы решаем в этом исследовании?» (увеличить удержание, снишить нагрузку на поддержку, повысить конверсию). Ищите решения на стыке «выгода для пользователя» и «ценность для бизнеса».
Для продакта: Не прячьте бизнес-требования. Четко сформулируйте их для команды: «Нам нужно, чтобы эта функция принесла X денег» или «Наша цель — сократить количество обращений в поддержку на Y%».
Стандарт поведения: Введите в отчеты исследователя обязательный раздел «Влияние на бизнес-метрики». Это заставит его мыслить шире, а его предложения будут звучать весомее для руководства.
4. Конфликт: Исследователь vs Система — «Мой отчет пылится на полке»
- Суть: Труд исследователя игнорируется. Происходит выгорание и потеря мотивации. Причины делятся на два типа:
Объективные (вина исследователя): Некачественная методология, малая выборка, предвзятость, непрактичные выводы, запоздалые результаты.
Субъективные (вина продакта/системы): Отсутствие процесса внедрения выводов, постоянная смена приоритетов, нежелание что-либо менять. - Выход:
Для исследователя: Работайте по принципу «time to insight». Быстрые и своевременные инсайты ценнее идеального отчета, припозднившегося на две недели. Делитесь предварительными выводами сразу. Делайте свои отчеты визуально простыми и ясными — «пост для лидеров», а не академический трактат.
Для продакта: Если вы заказали исследование, вы обязаны организовать сессию по обсуждению выводов и принятию решений. Исследование — это не галочка, это начало работы.
Стандарт поведения: Внедрите «триггеры на исследования». Четкие правила: «Если мы делаем новую фичу стоимостью более 100 человеко-часов, то мы обязательно проводим юзабилити-тест прототипа».
5. Конфликт: Разработчик vs Дизайнер — «Это невозможно сделать / Это будет стоить 100 лет»
- Суть: Дизайнер, вдохновленный лучшими примерами Dribbble, приносит макет с сложнейшей анимацией, кастомными элементами и нестандартной механикой. Разработчик смотрит на это и видит 3 недели костылей, баги и проблемы с производительностью.
- Причина и нюансы: Дизайнер мыслит категориями визуала, эмоций, поведения. Разработчик — категориями логики, архитектуры, производительности и поддерживаемости кода. Это классический конфликт «идеала» и «реалии».
- Выход:
Для дизайнера: Изучите базовые принципы разработки. Что легко, а что сложно? Используйте готовые дизайн-системы (тот же Material Design) как основу — они уже продуманы с учетом технической реализации.
Для разработчика: Не говорите «нет». Говорите: «Да, но это будет стоить N часов. Вот какие есть более простые альтернативы с похожим эффектом». Предлагайте решения.
Стандарт поведения: Внедрите технический спринт/воркшоп для дизайнеров, где разработчики рассказывают о новых возможностях и ограничениях платформы. И наоборот — дизайнеры проводят для разработчиков экскурсии по дизайн-системе.
6. Конфликт: Продакт vs Разработчик — «Нам нужно вчера»
- Суть: Продакт требует сделать фичу максимально быстро, предлагая срезать углы: «Сделайте пока костыль, потом перепишем» (знаменитый «техдолг»). Разработчик сопротивляется, так как знает, что «потом» никогда не наступит, а код развалится.
- Причина и нюансы: Продакт живет в мире релизов и маркетинговых окон. Его цель — быстрее получить feedback от рынка. Разработчик живет в мире кода, который должен быть стабильным и чистым. Техдолг для него — это мина замедленного действия.
- Выход:
Для продакта: Легитимизируйте техдолг. Пусть разработчики оценивают его так же, как новую функциональность. Включайте задачи по устранению техдолга в бэклог и спринты как полноправные элементы. Это сделает стоимость «костылей» видимой.
Для разработчика: Объясняйте последствия техдолга на понятном языке: «Если мы сделаем так, как вы просите, то в будущем мы не сможем быстро добавить нужную вам фичу Х, и это обойдется в 5 раз дороже».
Стандарт поведения: Введите правило «в каждом спринте 20% времени уходит на техдолг и улучшения». Это компромисс: продакт знает, что 80% времени уходит на фичи, а разработчики знают, что 20% времени можно поддерживать код в чистоте.
7. Конфликт: Дизайнер vs Продакт — «Давайте переделаем всю логику!»
- Суть: Дизайнер, углубившись в пользовательский опыт, предлагает глобальное переосмысление продукта или ключевого потока. Продакт в ужасе: это ломает все текущие планы, roadmap и требует переделки уже работающего функционала.
- Причина и нюансы: Дизайнер смотрит на продукт целостно и видит системные проблемы. Продакт вынужден мыслить итеративно и точечно, чтобы показывать постепенный прогресс.
- Выход:
Для дизайнера: Предлагайте эволюционный, а не революционный путь. Разбейте глобальное изменение на маленькие шаги, которые можно встраивать в текущие итерации. Покажите, как первый шаг можно сделать прямо сейчас.
Для продакта: Не отвергайте глобальные идеи сразу. Возможно, в них скрыт ключ к прорыву. Выделите время (например, раз в квартал) на стратегические сессии по «перепридумыванию» продукта.
Стандарт поведения: Создайте дорожную карту для UX-улучшений (UX Roadmap) параллельно с продуктовой roadmap. Это покажет дизайнерам, что их системные идеи имеют шанс на жизнь, просто в более долгосрочной перспективе.
8. Конфликт: Менеджер vs Данные — «Нам не нужны тесты, я и так знаю, что хочет пользователь»
- Суть: Стейкхолдер или высшее руководство на основе личного опыта или «чуйки» продвигает решение, которое противоречит данным исследований и тестов.
- Причина и нюансы: HiPPO (Highest Paid Person's Opinion) — классическая болезнь организаций. Опыт руководителя, безусловно, важен, но он может быть устаревшим или нерелевантным для новой аудитории.
- Выход:
Для команды (продакт, исследователь): Не спорить, а предлагать тестирование. «Я вас понимаю, ваша идея имеет право на жизнь. Давайте проведем A/B тест или быстро протестируем прототип на 5 пользователях? Это поможет нам проверить гипотезу с минимальными затратами». Переводите спор в плоскость данных.
Стандарт поведения: Культивируйте в компании культуру экспериментов. Внедрите инструменты для A/B тестирования. Главный аргумент должен звучать не «я так думаю», а «давайте проверим».
9. Конфликт: Разработчик vs Исследователь — «Ваши пользователи — идиоты»
- Суть: Разработчик видит в логах или слышит от исследователя, что пользователи используют продукт не так, как задумывалось. Вместо того чтобы винить интерфейс, разработчик винит пользователей.
- Причина и нюансы: Разработчик мыслит логически. Он создал систему с четкой логикой, и если кто-то ее не понимает, это проблема человека, а не системы. Это защитная реакция на критику своего детища.
- Выход:
Для исследователя: Приглашайте разработчиков на сессии юзабилити-тестов (в качестве наблюдателей). Нет ничего убедительнее, чем увидеть собственными глазами, как реальный человек бьется головой об интерфейс, который ты создал. Это включает мощнейшую эмпатию.
Для разработчика: Примите как аксиому: «Если пользователь ошибся, виноват интерфейс». Ваша задача — предугадать любое нестандартное поведение и сделать систему надежной.
Стандарт поведения: Проводите регулярные демо-сессии всей команде, где показываете записи тестов с пользователями. Это общая боль и общие инсайты.
10. Конфликт: Команда vs Клиенто-центричность — «Мы делаем фичи, а не решаем проблемы»
- Суть: Все настолько увязли в бесконечной гонке за релизами, что забыли, зачем вообще все started. Команда механически реализует задачи из бэклога, не задумываясь, какую именно пользовательскую проблему они решают и решают ли вообще.
- Причина и нюансы: Потеря фокуса, усталость, давление сверху. Процесс победил результат. Клиенто-центричность стала пустым лозунгом.
- Выход:
Для продакта: Перед каждой новой фичей задавайте команде и себе два вопроса: 1. Какую проблему какого пользователя мы решаем? 2. Как мы поймем, что решили ее успешно? (какие метрики померяем). Пишите в бэклоге не «Сделать кнопку Х», а «Как пользователь Y, я хочу Z, чтобы решить свою проблему W».
Стандарт поведения: Внедрите регулярные (раз в квартал) «дни клиента»: просмотр записей тестов, чтение отзывов из поддержки, общение с реальными пользовацами. Это возвращает фокус и вдохновение.
Заключение
Идеальной команды не существует. Конфликты — это не признак провала, а признак жизни. Они возникают потому, что каждому не все равно. Плохо не ссориться, а замалчивать противоречия, позволяя им превращаться в тихий саботаж и выгорание.
Клиенто-центричность — это не про то, чтобы все всегда были друг с другом согласны. Это про то, чтобы иметь общий компас, стрелка которого упрямо указывает на пользователя. Этот компас и есть ваш главный арбитр в спорах. Спросите себя: «Какое решение в данной ситуации лучше для него?». И тогда из шума конфликта начнет рождаться не просто код, дизайн или фича, а по-настоящему ценный продукт.
Так где же спасительный рецепт? Он не в том, чтобы избежать конфликтов — это невозможно и даже вредно. Он в том, чтобы перестать воспринимать их как битву амбиций, а начать видеть в них систему сдержек и противовесов.
Здоровая продуктовая команда — это не оркестр, играющий с одного листа. Это джаз-банда. Здесь у каждого своя партия, свой инструмент и даже право на импровизацию. Но всех объединяет общий ритм (продуктовая стратегия) и гармония (потребности пользователя). Роль исследователя — чутко улавливать настроение зала. Роль дизайнера — придумывать запоминающиеся мелодии. Роль продакта — быть продюсером, который следит, чтобы все не свелось к какофонии. А разработчики — это те виртуозы, что превращают ноты в реальное, живое звучание.
Конфликт — это не сбой, а часть джема. Это момент, когда один музыкант подхватывает идею другого и вместе они находят звучание, которое невозможно было придумать в одиночку. Ваша цель — не заставить их замолчать, а настроить инструменты и научиться слушать друг друга. Тогда клиенто-центричность превратится из модного слова в ту самую волшебную химию, которая рождает по-настоящему великие продукты.
-----------------------------------------------------------------------
Меня зовут Роман Черных, я руковожу Русской Школой Сервисного Дизайна и преподаю User Experience Research&Design. Благодарю, что ознакомились с мыслями про ньюансы найма UX-исследователей. Подробнее про меня здесь.
Буду рад услышать вашу точку зрения – дополнения или аргументированные возражения, в комментариях. Если вас интересует тема человекоориентированного проектирования и исследований, приходите к нам, в телеграм-чат Русской Школы Сервисного Дизайна.
Так же мы проводим большие учебные программы по тематикам User Experience Research&Design&ProductOwnership. Со студентами говорим о тонких моментах творчества UX/UI-дизайнеров и исследователей, при этом параллельно глубоко прокачиваем искусство мышления и поиска вариантов решения задачи. Ближайшее событие – Осенняя UX-программа, которая пройдет с 20 по 31 октября 2025 в дневное время в онлайн. Присоединяйтесь!
Если вы или ваши коллеги:
- хотите учиться по нашей авторской методологии на групповых занятиях, в индивидуальном или корпоративном формате по темам UX Research&Design&ProductOwnership
- хотите нанять действительно сильных UX-исследователей/дизайнеров
- организуете мероприятие, где требуется спикерская поддержка специалистов Школы или моё участие в качестве ведущего/модератора
- планируете получить консультацию по продуктовому проекту или процессу
- желаете оценить свой текущий потенциал, перспективы профессионального роста, тактику UX-обучения и карьерную траекторию
- хотите предложить другое сотрудничество –
запишитесь на консультацию/созвон, написав мне здесь.
Подпишитесь на наши ресурсы, чтобы видеть анонсы UX-мероприятий:
Rutube-канал РШСД
Телеграм-канал РШСД
Youtube-канал РШСД