Юзердни в продукте: как мы вовлекаем команду в исследования и зачем это бизнесу
Команда, глубоко погружённая в продукт, часто начинает говорить на своём языке, забывая о пользователе. В Магнит OMNI мы ломаем этот барьер с помощью юзердней — сессий прямого общения с клиентами. Они помогают проверять гипотезы и показывают реальные, а не предполагаемые сценарии. За пару лет мы испытали три подхода и готовы поделиться вынесенными уроками.
Что такое юзердень для бизнеса и пользователей
Представьте: команда разработки, дизайнеры и продакты месяцами делают продукт, опираясь на данные и гипотезы. А потом выясняется, что реальные люди используют его не совсем так, как задумано. Знакомо?
Чтобы этого избежать, мы в Магнит OMNI проводим не только стандартные исследования, но и юзердни. Это быстрые сессии, где команда напрямую общается с пользователями, а исследователь выступает в роли ведущего и ментора — страхует процесс и помогает извлечь максимум пользы.
Зачем это нужно? Простыми словами — чтобы взглянуть на продукт глазами пользователя. Увидеть живого человека, услышать его большие и маленькие проблемы, а потом превратить всё это в проверяемые гипотезы. То есть цель юзердня — понять, для кого мы делаем продукт, и проникнуться эмпатией к пользователю.
В юзердне участвуют все команды — разработчики, продакты, дизайнеры и аналитики. Поводом может стать как решение исследователя, так и запрос от коллег. Для разговора мы приглашаем наших пользователей, а если нужен взгляд со стороны — например, пользователи конкурентов, — обращаемся к агентству. Пяти интервью достаточно, чтобы увидеть устойчивые паттерны, но если желающих пообщаться много — мы просто расширяем пул респондентов.
Три формата, которые мы попробовали, и что из этого вышло
Формат 1. Командный юзердень: подключаем разработчиков
Задача: Показать разработчикам, для кого они на самом деле пишут код. Вытащить их из контура «задача → код → релиз» и дать пообщаться с живым пользователем.
Как готовились:
- Обсудили, как задавать открытые вопросы, не бояться пауз и этично вести беседу.
- Первые интервью проводили исследователь вместе с лидом, чтобы показать команде, что это не страшно.
- Подготовили шпаргалки с вопросами.
- Заранее созвонились с респондентами, чтобы проверить звук и связь.
Что сработало:
- Поддержка лидов. Когда лид провёл первое интервью, у команды пропал страх «а вдруг не получится».
- Тестировали готовый продукт, а не прототип. Так проще — ничего не зависает и не ломается.
- Подбирали более лояльных первых респондентов, готовых открыто давать обратную связь и пунктуальных — чтобы команда пробовала свои скиллы в более комфортной обстановке.
Разработчики боялись вести диалог. Мы побороли это тестовыми интервью, шпаргалками и чатом поддержки, где исследователь мог быстро подсказать вопрос. Как итог — коллеги увидели реальные проблемы пользователей и начали предлагать решения. Вместо абстрактных «юзеров» появились запоминающиеся портреты: «тот строитель из Твери, который любит рыбачить», а следом — желание помочь ему и таким же другим строителям, учителям, бухгалтерам... Эмпатия стала конкретной.
«Мой первый юзердень был настоящим боевым крещением. Руководство компании хотело, чтобы в нём по максимуму участвовали разработчики. При этом в реальности не всем такая идея казалась жизнеспособной. Помню, как продакт говорила: «Арина, разработчики не будут вести интервью. Послушать кто-нибудь придёт, но вести интервью — вряд ли. Они любят делать, а не говорить, даже про то, в чём они разбираются лучше всех. А тут ещё при всех задавать вопросы незнакомым людям». На это я ответила: “Хорошо, давай посмотрим, рискнём. И мы рискнули».
Формат 2. Общий юзердень на 4–5 команд: почему «много ответственных = нет ответственных»
Задача: Провести масштабное мероприятие по запросу руководства, где несколько команд общаются с пользователями в одних и тех же слотах.
Что пошло не так:
- Календарный ад. Даже при планировании за полтора месяца слоты разлетались, а лиды пропадали на более срочных задачах.
- Размытая ответственность. Часто срабатывала логика «там ещё 3 лида, и без меня справятся».
- Потеря фокуса. Каждая команда тянула одеяло на свои темы, и было сложно удержать общую картину.
Была ли польза? Да, но точечная. Одна команда полностью пересобрала свой бэклог. Остальные взяли на вооружение отдельные инсайты. Поэтому общие Юзердни хороши как разовая встряска. Но для системной работы лучше фокусироваться на одной команде: один лидер, одна зона ответственности.
«Юзердень — это выход из зоны комфорта для разработчика. Нужно раскрепощаться и учиться управлять встречей: поддерживать и пользователя, и команду, постоянно импровизировать. Самое главное — я понял, что суть не в вопросах и записях, а в том, чтобы искренне слушать, улавливать эмоции и контекст. Это мощная тренировка многозадачности А как бонус — после юзердня ты начинаешь гораздо лучше понимать своих же коллег».
Формат 3. «Трушный» юзердень: холодная база и суровая реальность
Задача: Для опытной команды мы усложнили условия — работали с «холодной» базой — то есть с теми, кто может подумать, что мы мошенники или тестируем IQ пользователя. Был велик риск срыва встреч. Темой встречи выбрали пуши.
Что заметили:
- Люди не читают пуши в идеальной тишине за чашечкой чая. Они читают «на бегу», в перерыве на работе или даже с ребёнком на руках. А людям, для которых русский — неродной, ещё сложнее всё считать в таком формате. Но это наши пользователи. И мы должны стараться сделать понятно для всех.
- Эра мошенников даёт о себе знать: люди стали настороженнее. Важно было правильно представиться, снять тревогу и не давить.
«Юзердень вызвал у меня восторг — от подготовки до анализа. Это был и личный, и профессиональный рост. Я поборола страх перед интервью с незнакомцами и научилась находить к каждому «ключик» — иногда даже приходилось петь или шутить! Главный вывод — качество важнее количества. Наша небольшая, но заряженная команда пришла к цели вместе, потому что все горели идеей».
Что не работает в юзерднях
- Сложные респонденты для первого раза. Не надо геройствовать. Начинайте с проверенных участников.
- Сырые прототипы для новичков-интервьюеров. Первый раз лучше тестировать на работающем продукте — меньше шума и стресса.
- Много лидов, мало ответственности. Чётко назначайте ответственных. Идеально, когда это лид разработки и продакт. Программа минимум — только продакт.
- К юзердню не нужно готовиться. Нужно заранее выбрать дату, когда у ключевых участников нет важных запусков, отчетов, отпусков. Команде будет существенно сложнее влиться в процесс без гайдов, шпаргалок и прочего.
- Глубинные интервью. Чтобы разговорить человека, нужен большой опыт.
Как юзердни меняют команду, а не только продукт
Юзердень — важная часть продуктовой культуры. Да, не каждая гипотеза «выстрелит». Но такой подход поможет сэкономить время и деньги. На этом польза не заканчивается. За три разных юзердня мы обнаружили важные «побочные эффекты».
Это отличный тимбилдинг — коллеги поддерживают друг друга, вместе шутят и открывают что-то новое. Такие мелочи неожиданно сближают. Совместная генерация решений после пяти интервью создаёт ощущение, что в следующий раз будет легче работать вместе над любой задачей. А для некоторых участников юзердень стал возможностью прокачать софт-скиллы и открыть в себе новые грани, например, навык публичных выступлений. В итоге юзердень — это инвестиция не только в качество продукта, но и в сплочённость команды и личностный рост каждого её участника.
«Арина в статье рассказала о взаимодействии с продуктовой командой и о пользе этой инициативы для продукта. Но есть и другая сторона — развитие самого исследователя. Юзердни помогают исследователям становиться ещё круче и прокачивать навыки, которые для них не обязательны. Так исследователь развивает менеджерские и организаторские способности: ведь больших трудов стоит собрать всех участников, провести краткий брифинг, управлять каждым интервью и следить за соблюдением плана. А бонусом мы ещё получаем еще большую сплочённость с продуктовой командой и их доверие. Так что эта активность, как говорится, — чистой воды win-win».