Всем привет! Меня зовут Данила Максишко, я руковожу командой продуктовых исследователей в hh.ru. В статье расскажу, как мы работаем с обратной связью через важный инструмент — бэклог болей пользователей.

Это текст от исследователя для исследователей. Если вы строите или масштабируете ресёрчи у себя, наш опыт поможет избежать части ошибок и быстрее выстроить рабочую систему.

Продукт в рамках разумного

Я занимаюсь исследованиями много лет и недавно осознал простую правду: продукт не обязан быть идеальным, чтобы решать задачу пользователя. Я всегда сражаюсь за супергладкие и суперлёгкие пользовательские сценарии, но не терять из виду интересы бизнеса тоже важно. В рамках ограниченных ресурсов компаний идеал вряд ли достижим. Поэтому надо искать компромисс между идеалом и реальной жизнью, который я называю «продукт в рамках разумного». Именно продукты в рамках разумного приносят пользу клиентам и решают их задачи.

Главный вопрос: а как добиться этого «в рамках разумного»? Я вижу тут два направления работы: будущее и прошлое. Работа с будущим — это изменения в интерфейсах, которые ещё не реализованы, а работа с прошлым — корректировка шероховатостей ранее совершённых запусков.

О работе с будущим я рассказывал в предыдущей статье. Давайте освежим контекст и дополним его информацией о работе с прошлым.

Экскурс в будущее: главная страница hh для работодателей

К исследователям часто приходят запросы на проверку гипотез или решение открытых вопросов. Иногда просто хочется подискаверить, что происходит по пользовательскую сторону от экрана, иногда — проверить существующие концепции, а иногда приходит пора сопровождать запуск продукта. От исследователей ждут подтверждения, что продуктовые команды делают нечто действительно удобное, понятное и качественное, чтобы подстраховаться и не инвестировать в неудачные варианты. 

Проиллюстрирую недавним кейсом. Мы работали с большим проектом по обновлению главной страницы для работодателей. Провели для этого масштабное исследование: опросили возможных клиентов, из блоков собрали для них идеальную страничку. Благодаря тому ресёрчу наша команда осознала концептуальную роль поисковой строки. Она должна была отвечать на вопрос: «А есть ли на сервисе интересующие меня кандидаты в моём регионе?». Вокруг этого инсайта мы и пересобрали главную страницу.

Получилось круто! Конверсии, целевые действия, прирост аудитории — наш эксперимент принёс пользу клиентам. Так что и правда, никто не обязан быть идеальным. Но исследования помогают находить точки роста, которые будут давать заметный результат для бизнеса.

Работа с прошлым: собираем боли соискателей 

Работа исследователей с прошлым — про фидбэк и про то, что происходит на проде. Мы используем три графика, CSAT (Customer Satisfaction Score — удовлетворённость продуктом), NPS (потребительская лояльность) и отток. Наложив их на статистику за несколько лет, мы получили данные, которые можно увидеть ниже. Графики были очень похожи, и мы заметили прямую корреляцию — сильную для CSAT, заметную для NPS.

Из этого родился довольно простой, но важный вывод: чем быстрее соискатель находит работу, тем больше ему нравится наш сервис. Счастье клиента — вроде бы, неосязаемая вещь. Но она напрямую влияет на продуктовые метрики и показатели компании.

Если счастье клиента ключевой показатель для бизнеса, то надо в него вкладываться, делать сервис удобным и понятным. Поэтому нужно хорошо знать, где пока что неудобно и не очень понятно — и последовательно улучшать эти части продукта. Именно для этого мы и завели бэклог пользовательских болей.

По сути, это обычный проект в Jira, где каждый тикет — повторяющаяся пользовательская проблема. 

В бэклоге описаны: 

• краткие обозначения болей

• привязка к конкретному флоу и ответственные за него

• оценка распространённости, которую считаем по упоминаниям в комментариях каждый квартал

• оценка критичности — это уже наша экспертная оценка

• статус каждой боли: от момента появления до решения

• прочие детали, которые помогают анализировать проблему — например, версия приложения

Каждый квартал мы собираем поток обратной связи. Первый канал — через нашу команду по CSAT-опросу, в котором люди не только ставят оценки, но и пишут комментарии. Если видите на hh.ru всплывающее окошко с вопросом вроде «насколько удобно пользоваться этой страницей», можете смело писать всё, что думаете. Можете даже ко мне по имени обращаться — мы всё это реально читаем! Второй канал — наша дружественная команда техподдержки собирает обращения, мониторит соцсети, отзывы в сторах и так далее. В итоге у нас накапливается довольно большой объём знаний о том, что у пользователей болит.

Далее — разметка данных. Процесс муторный, но необходимый. Мы собираем комментарии, относим каждый к конкретному пункту из бэклога, смотрим, что появилось нового, что ушло, как меняется динамика. Параллельно синхронизируемся с поддержкой, маркетингом и продажами — сверяемся, насколько наш список вообще актуален. Каждый квартал мы вот таким образом обновляем картину.

По каждому тикету мы общаемся с ответственными командами. Обсуждаем, что нового появилось за квартал, что уже исправлено, а что стоит в планах. Затем остаётся наблюдать, какие продуктовые изменения работают на устранение конкретных болей, а какие — нет.

Позитивные результаты бэклога…

Если посмотреть на эту систему ретроспективно, то сразу видно, что получилось хорошо.

1. Сделали удобную структуру. И с точки зрения статусов, и с точки зрения наполнения тикетов — это реально рабочая схема.

2. Выстроили ритм. Квартальные синхронизации стали нормой, и более того — продуктовые команды сами начали двигать тикеты, комментировать, вовлекаться. История перестала быть «исследовательской» и стала общей.

3. Но самое важное — это эффект. Мы начали видеть прямую связь: обсуждаем боль, запускаем изменения, потом исчезают комментарии на эту тему, и мы закрываем тикет. И так квартал за кварталом.

4. Плюс появился побочный, но приятный эффект — вовлекли «соседей». Если раньше мы обсуждали бэклог вдвоём с продактом, то теперь подключились поддержка, маркетинг, продажи. Кросс-опыление, можно сказать!

В какой-то момент эта история стала заметной даже на C-level. Теперь CPO следит за происходящим, задаёт вопросы, а на квартальных комитетах мы вместе обсуждаем результаты. Это сильно меняет восприятие всей работы.

…и выученные уроки

Без этого тоже никуда.

1. На старте мы пытались визуализировать весь бэклог — делали карту пользовательских сценариев, которая не взлетела. У нас была система экранов и поверх неё размечены боли. Получилось красиво, но инструментом не пользовались. В итоге перестали поддерживать.

2. Ещё одна проблема — трудоёмкая разметка данных остаётся ручной. Несмотря на то, что у нас есть алгоритм предразметки, полноценного автоматизированного решения пока нет.

3. В том числе из-за этого зависимость от человеческого фактора остаётся высокой. Например, в техподдержке оператор может записать комментарий, а может не записать. Для нас каждый сигнал важен и хочется работать с первичными данными — с транскриптами, с сырыми логами, и уже автоматически их обрабатывать. Но это снова упирается в технологии. Мы двигаемся в эту сторону и скоро расскажем, что получилось.

4. Параллельно мы начали пробовать сегментировать боли — выделять специфические группы проблем. Но это пока задел на будущее.

5. И ещё одно направление — отдельный бэклог UX-проблем из исследований. Сейчас они лежат в базе знаний и не дотягивают по частотности до основного бэклога, но всё равно хочется их структурировать похожим образом.

Вот такая у нас выстроилась система. Пришлось пройти через неудачные решения, ручные процессы и постепенную сборку рабочих практик. Но в итоге получился понятный и воспроизводимый цикл, который на выходе выдаёт измеримый и заметный результат. Главное, что мы сами выяснили в процессе: исследования — это не фоновый шум, а то, что двигает продукт вперёд.

Надеюсь, мой рассказ будет интересен коллегам-исследователям и всем интересующимся. Если у вас был похожий кейс или вы решали похожие задачи иначе — призываю поделиться опытом в комментариях!