Всем привет, я Лена, исследовательница в команде Облака Mail. Изучаю опыт пользователей и помогаю командам делать наши сервисы удобнее и понятнее. Управляю проектом UX-мониторинга core-сценариев продуктов Mail.
В этой статье хочу рассказать о том, как мы переосмыслили место исследователя в продуктовой команде и как нам удалось пересмотреть UX-долг*, также о том, как этот подход помог нам стать источником для формирования продуктового бэклога на примере нашей небольшой команды.
Несколько лет назад мы работали по «агентской модели»: приходили по запросу, проводили интервью, тестировали дизайны, помогали проверять гипотезы. Мы старались не просто «отдать результаты и забыть», а проводили мастер-классы с командой, собирали в таблицы найденные проблемы и наблюдения, делали первые попытки создать свой репозиторий знаний. Но почти никогда не видели, какую информацию в итоге использует команда, что уходит в разработку и почему принимаются те или иные решения.
Параллельно раз в год мы проводили UX-мониторинг core-сценариев, который выявлял системные UX-проблемы в продукте. Однако до бэклога доходило далеко не всё и не всегда. Мы копили огромный объём знаний о продукте и пользователях, но команды возвращались к этим данным стихийно, если вспоминали.
При этом мы и сами были не сильно погружены в контекст продуктовых целей, а источниками наших знаний о том, что происходит в продукте, были продуктовые демо и внутренняя документация. Мы не участвовали в формировании бэклога и не могли встроить наши знания в системную работу команды.
Со временем стало понятно, что у нас много наблюдений, но нет системы, которая связывала бы их с реальными продуктовыми решениями.
Мы оказались в ситуации, когда:
Как мы проектировали репозиторий
Чтобы выйти из сложившейся ситуации, нужно было изменить сразу два направления работы:
Во-первых, организационный. Мы начали уходить от чисто «агентского» формата и постепенно распределяться по продуктовым командам, чтобы лучше понимать цели, метрики и контекст каждой команды.
Во-вторых, методологический. Прошлые попытки в репозиторий не сработали, репозиторий из UX-мониторинга существовал вне контура инструментов наших команд. Все данные были разрозненны и их необходимо было собрать в одном месте. Я начала изучать рыночные практики, общалась с коллегами из других бизнес-юнитов, смотрела, как они строят исследовательские репозитории и как «продают» их продукту.
Это дало:
Понимание, какие источники данных действительно ценны для продуктовых решений.
Определение структуры базы знаний, чтобы быть не архивом, а рабочим инструментом.
Выбор инструмента, который будет для продукта понятным и находиться «на расстоянии вытянутой руки». То есть инструмент, который команды используют в ежедневной работе — без дополнительного обучения, прав доступа и сложных интеграций (примеры: Сonfluence, Jira, Notion, онлайн-таблицы и т. д.).
Я временно остановилась на таблицах. Это не идеальный формат для больших объёмов данных, но вначале он дал то самое важное преимущество: быстрое и бесшовное включение продуктовой команды в работу с данными.
Для обогащения репозитория я выделила ключевые источники данных, которые могут показать, как уникальные проблемы в одном источнике, так и пересечения в источниках:
Чтобы все данные можно было сопоставлять, я собрала структуру каждой записи:
описание проблемы;
сценарий или место возникновения;
теги;
приоритет;
критичность;
влияние (по данным аналитики, сколько пользователей задействовано в сценарии);
источники знаний;
платформа (мобильный сегмент, веб);
дата первого появления;
ссылки на результаты исследования.
Оценка приоритета UX-проблем рассчитывалась по двум осям: влияние на продукт (критичность проблемы*) и влияние на охват (количество пользователей в сценарии). Самый высокий приоритет получали проблемы, которые одновременно мешали выполнению сценариев и затрагивали большую долю пользователей.
Таким образом, собранные в таблице данные позволяли любому участнику продуктовой команды сразу увидеть полную картину по каждой проблеме: где и когда проблема возникает, насколько она массовая и критична, из каких источников она подтверждается и как давно существует.
Полевой этап: тестируем прототип с продуктовой командой
Тестировать нашу базу UX-долга я начала в новой продуктовой команде, которую создавали с нуля — с новым продактом и чистым взглядом на процессы. Это оказалось важным фактором: нам не нужно было ломать устоявшиеся правила, мы могли выстраивать свои собственные процессы.
В этой команде впервые появилась полноценная роль исследователя внутри продуктового процесса — не как внешней функции, а как участника команды, вовлечённого в планирование и принятие решений. Это создало подходящую среду для эксперимента с UX-долгом.
Сначала команда определила ключевые метрики, над которыми планировала работать в текущем квартале. При этом у команды уже был delivery-бэклог (технический), а discovery (продуктового) не существовало. Именно тогда UX-долг стал отправной точкой для формирования discovery-бэклога.
Чтобы всей команде было проще ориентироваться в базе UX-долга, совместно с продакт-менеджером мы обогатили её дополнительными категориями:
Каждая проблема получила продуктовую «привязку»:
на какой сценарий она влияет;
как много пользователей с ней сталкиваются (охват в сценарии);
на какую метрику повлияет решение проблемы;
что именно нужно изменить, чтобы повлиять на метрику.
Так UX-долг заговорил на языке продукта. Теперь каждая задача имела не просто пользовательскую проблему, а чёткое бизнес-обоснование: гипотезу о влиянии на продуктовые метрики.
В результате репозиторий стал отвечать на продуктовые вопросы:
с какими проблемами сталкиваются пользователи;
что даст решение этой проблемы бизнесу (на какие метрики повлияем);
приведет ли решение проблемы к достижению целей команды.
Сопоставляя продуктовую гипотезу по проблеме с приоритетом (критичность и охват) и целевыми метриками команды, мы смогли значительно ускорить сбор бэклога и повысить ценность UX-долга.
Анализ результатов: к чему стоит быть готовыми
Формирование репозитория — это не беззаботная прогулка по ровной дороге. Скорее, это долгий маршрут с поворотами, туманами и участками, где приходится идти на ощупь. На каждом этапе возникают свои вызовы и сложности — ниже я описала те, которые лично для меня оказались наиболее ощутимыми.
Нужен владелец процесса
У UX-долга обязательно должен быть менеджер — человек, который держит контекст, развивает и внедряет инструмент, договаривается с коллегами, презентует результаты и держит инициативу «в фокусе».
Разрозненные источники данных
В начале мне пришлось многое собирать вручную — от выгрузок CSAT до скриншотов из исследований. Это заняло время, но позволило увидеть пересечения проблем из разных источников и прийти к новым выводам.
Чтобы не закопаться, стоит ограничить период анализируемых данных и составить план: цель, этапы, примерные сроки.
Формирование репозитория — это не задача «между делом», а отдельный проект, на который нужно выделять время и встраивать в исследовательскую рутину.
Зрелость продуктовой команды
UX-долг не повышает зрелость сам по себе. И речь здесь не только про «UX-зрелость», а про общую продуктовую зрелость: насколько команда умеет работать с данными, гипотезами, пользовательскими сценариями, метриками. Если этих практик нет, то внедрение UX-долга может оказаться слишком ресурсозатратным для исследователя.
Buy-in от продукта и топ-менеджмента
Без поддержки сверху база действительно рискует остаться инициативой исследователей. Что помогало мне:
регулярно рассказывать о находках разным «горизонталям» (дизайнерам, продуктологам, аналитикам, разработчикам);
показывать ценность не только через «проблему пользователей», но и через влияние на продуктовые метрики и цели команды;
подчёркивать, что репозиторий помогает планировать и приоритизировать бэклог с учётом уже накопленных знаний о продукте, а не начинать каждый раз с нуля.
Это помогало постепенно «продавать» идею не только вверх, но и вширь — через горизонтальные связи.
Сейчас инструмент уже работает и помогает нам собирать продуктовый бэклог быстрее. Но данных становится больше, и в скором времени мы перестанем помещаться в табличный формат. Поэтому следующим логичным для нас шагом может стать переезд в командный таск-трекер, где мы сможем связать UX-долг с продуктовым бэклогом и задачами на разработку
Вместо выводов
UX-долг нельзя «закрыть», как нельзя «доделать» пользовательский опыт. Но можно научиться работать с ним осознанно: видеть, где продукт теряет ценность, и превращать это в развитие.
Поделитесь вашими примерами внедрения UX-долга: как вы подходили к работе на старте, какие использовали рабочие хитрости и где искали мотивацию, чтобы продолжать?
Благодарность коллегам, которые вдохновляли своим опытом: Екатерине Бессчётновой («UX-долг — это не про интерфейсы, это про деньги») и Марине Сусловой («Репозиторий UX-проблем, связанный с бэклогом»).