Репозиторий UX-проблем, связанный с бэклогом

Марина Суслова, Head of UX Research

В М.Видео мы вместе с командой создали хранилище результатов исследований и есть репозиторий всех проблем клиента. Структурированные и протегированные отчеты по исследованиям хранятся в Confluence, репозиторий же построен как база данных в Airtable. Существует такое понятие, atomic research, вот это он и есть. Найденные на исследованиях инсайты разбиваются на составляющие, тегируются, и потом любой может найти их в репозитории или построить дашборд на определенную тему. Но мы храним там не только результаты исследований.

Путь к созданию репозиторию начался с задачи: «Давайте построим CJM и поймем, где у нас слабые места, и куда нужно направить ресурсы». Сначала хотелось построить это в Miro, но мы поняли, что это быстро потеряет актуальность. В итоге выбор был сделан в пользу репозитория.

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

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

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

Так как основные дашборды разбиты на шаги клиента, мы называем репозиторий CX-карта.

Структура каждой отдельной записи в хранилище такая:

― Описание проблемы;

― Шаг, на котором возникает проблема;

― Задачи пользователя;

― Скриншоты;

― Причина, почему так случилось;

― Источники проблемы (например, проблемы с текстом);

― Теги;

― Последствия;

― Критичность (определяется исходя из последствий);

― Частота возникновения проблемы (определяется субъективно по таблице;

― Канал, где она возникает;

― Ссылки на исследования в базе confluence или miro;

― Источники знаний (например, UX Feedback, исследование или жалоба);

― Онлайн или оффлайн проблема;

― Идея, что можно с этим сделать;

― Референсы к идее;

― Решение: тут менеджер продукта указывает, что именно он будет делать и дает ссылки на задачи в jira;

― Статус решения;

― Дата исправления;

― Ответственный;

― Приоритет.

У каждой проблемы есть ответственный за ее решение. Он работает с картой, указывает статус проблемы клиента, пишет решение, дает ссылки на Jira. Благодаря этому информация о проблемах актуальна, можно понять, почему проблема возникает, как и когда ее решат. А еще можно отслеживать прогресс: сколько проблем решено, какие, сколько взято в работу. Если проблема решена, создается запись, что именно было сделано. М.Видео следит за статистикой и прогрессом решения проблем клиента, при этом у каждой проблемы есть вес, исходя из критичности и частоты возникновения.

CX-карту используют для стратегического планирования и наполнения бэклога.

Когда мы переносили информацию в репозиторий, это заняло несколько недель. Мы делали это всей командой в интенсивном режиме. Затем какое-то время ушло на включение его в наши процессы. Полноценно использовать репозиторий мы начали примерно за три месяца.

Учитывая, что для работы с такой системой необходимо много ресурсов, я бы не назвала ее универсальным решением, которое подойдет для всех.

Большой плюс такого репозитория в том, что результаты исследований и сбора обратной связи соотносятся друг с другом. Когда они хранятся в отдельных файлах, может случится, что новое исследование как будто отменяет предыдущее. Если все знания в одной базе, и у каждой проблемы есть критичность и частота, это помогает понять, куда каждая новая находка ложится в системе координат CX-карты. Так проще приоритизировать и дополнять бэклог, перед глазами есть полная картина.

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

Уже работаю над этим!

Критичность определяется по последствиям согласно таблице:

Низкая:

Средняя:

Высокая:

Частота определяется по частоте возникновения согласно таблице:

Низкая:

Средняя:

Высокая:

Часть 2 про репозиторий проблем клиента, который теперь живет в JIRA