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

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

Структура базы знаний

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

Структура репозитория

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

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

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

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

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

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

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

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

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

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

― Скриншоты;

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

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

― Теги;

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

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

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

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

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

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

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

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

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

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

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

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

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

― Приоритет.

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

Как используем

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

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

Кому подойдет

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

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

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

Куда расти

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

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

Дополнение: критичность и частота

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

Низкая:

  • Проблема не сильно влияет на выполнение задачи и достижение цели:
  • не требует времени на исправление,
  • пользователь продолжает выполнение своей задачи, получает желаемый результат.

Средняя:

  • Проблема мешает выполнению задачи и достижению цели клиента/пользователя:
  • требует время или усилия на исправление,
  • пользователь отклоняется от пути, но возвращается к выполнению своей задачи,
  • пользователь получает желаемый результат, который может частично не соответствовать ожиданиям.

Высокая:

  • Проблема делает выполнение задачи и достижение цели пользователя невозможным:
  • пользователь не выполнил задачу,
  • пользователь выполнил задачу, но не заметил критичной ошибки (из-за которой не получен нужный результат),
  • итоговый результат полностью не соответствует ожиданиям и клиента/пользователя.

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

Низкая:

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

Средняя:

  • Проблема может возникнуть у любого клиента, проявляется время от времени, заметна клиентам
  • Проблема возникает в определенном контексте, но это контекст распространен
  • Проблема актуальна для средней группы клиентов (не всех)

Высокая:

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

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

1515
1 комментарий

Очень классный репозиторий! :)

2
Ответить