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

Привет! Меня зовут Даша Боровик, я руковожу командой экспертов по клиентскому опыту в RUTUBE. База юзабилити-проблем сервиса — одно из детищ нашей команды. Как и многие в индустрии, мы сталкиваемся со сложностями в управлении CX-долгом и ищем свой подход. 

Если вы задумались над созданием или оптимизацией работы с бэклогом юзабилити-проблем — читайте эту статью. Я расскажу, как в RUTUBE управляют CX-долгом, зачем его вообще трогать и почему ну никак не получится махнуть на него рукой. А ещё честно предупрежу о сложностях, с которыми мы сталкиваемся — ведь наш процесс, хоть и рабочий, совсем не идеальный. И если у вас есть идеи и советы, поделитесь в комментариях.

Краткое погружение в теорию юзабилити-проблем

Быстро расскажу, что мы в RUTUBE считаем юзабилити-проблемами, и у кого болит о них голова. Теория нужна, иначе картинка не сложится.

Принято считать, что юзабилити-проблема — особенность интерфейса, которая мешает пользователю выполнить задачу. Вот и мы так считаем.

Некоторые такие особенности юзер не заметит, но задачу ему придётся выполнять дольше. А от других закроет вкладку и в сервис больше не вернётся. Ещё и в саппорт передаст «развивающую обратную связь» (и будет прав).

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

Поэтому юзабилити-проблемы подтверждаются:

• Исследованиями UX-лаборатории RUTUBE— так мы знаем, что проблемы реальны для респондентов, а не относится к нашим личным фантазиям.

ИЛИ

• Обращениями в саппорт — если пользователи жалуются в поддержку, значит, им что-то мешает достигнуть цели.

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

Ошибочно считать, что если пользователю неудобно или что-то не нравится — это проблема только людей, у кого в должности значится приписка «UX-...». Почти любая юзабилити-проблема повышает обращайку в поддержку, портит воронку, роняет ретеншн сервиса. Управлять CX-долгом продукта — общая ответственность всех людей, которые им занимаются. 

Вот, как это делаем мы.

1. Шерше ля проблема

Чтобы начать вести бэклог юзабилити-долга, надо его найти.

Для удобства поделю источники знаний о проблеме на две категории: в одной находится «готовый долг»; в другой — гипотезы о таком долге. 

Откуда мы узнаём о «готовых» проблемах и сразу отправляем в долг

Собственно, их ищем в заранее верифицированных источниках.

• Исследования клиентского опыта

Где же найти ценный инсайт о проблеме, как не в результатах UX-ресёрча? За эту часть поисков отвечают исследователи Лаборатории RUTUBE.

• «Мясо» обращений в поддержку

Раз в определённый период команда экспертов по клиентскому опыту засучивает рукава и открывает табличку со свежими обращениями пользователей. Среди них мы ищем такие, которые проходят по нашим правилам и о которых мы точно можем сказать «такая-то особенность интерфейса мешает выполнить таким-то пользователям задачу ИКС».

Откуда мы достаём гипотезы о потенциальных проблемах 

• CX-аудиты прода

Моя команда аудирует прод после релизов — писали об этом тут. В этом процессе мы даём экспертную оценку тому, как продукт работает в пользовательских руках, фиксируем user flow. Здесь формируются гипотезы о юзабилити. 

Например: «Кнопка „Ответить“ выглядит кликабельной даже для заблокированного пользователя. Это приведёт к ошибочным нажатиям в попытке ответить на комментарий. Пользователь может решить, что поведение системы — баг. Возможны обращения в поддержку».

Мы не можем отнести гипотезы к CX-долгу: они не прошли верификацию по пунктам, о которых я писала ранее. Однако фиксировать гипотезы важно, чтобы в подходящий момент провести эту самую верификацию: разместить для проверки в бриф UX-исследования или найти подтверждение в обращениях в саппорт.

• Данные продуктовой аналитики

Ищем в них провалы в воронке к целевому действию. В нашем производственном процессе такие данные обычно приносит продуктовый менеджер. 

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

2. Врываемся в бэклог

Допустим, мы обнаружили и верифицировали юзабилити-проблему и считаем, что она должна стать частью бэклога CX-долга. Для этого:

1. Размещаем задачу на исправление проблемы в таск-трекер.

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

   Почему решили делать это в таск-трекере, а не вести отдельные таблички или странички? Потому что считаем, что исправление юзабилити-долга — это обычная работа с фичой. Чем меньше отличий от принятого алгоритма запусков — тем выше шанс, что проект попадёт в поле зрения продуктовой команды. 

   Это подтверждается статистикой: после переезда из «табличек» на стороннем ресурсе в наш таск-трекер, доля исправленных юзабилити-проблем постепенно выросла на 11 процентных пункта.

2. Вводим в контекст проблемы продуктового менеджера и команду.

   Чтобы РО не удивлялся, что в бэклоге вдруг появилась новая карточка, мы выходим к продуктовой команде и проговариваем, что это за задача и какую проблему пользователя хотим исправить.

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

3. Начинаем сначала

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

Конец ванильной части

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

Реальность с её проблемами и недостатками

или почему иногда CX-долг всё же хочется простить…

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

Для некоторых мы уже нащупали решения — ими тоже поделюсь. А вот для некоторых пока ничего не придумали — так что будет супер, если идеями поделитесь вы в комментариях :)

Проблема: приоритизация не приоритизирует

В RUTUBE фичи запускаются с учётом анализа влияний на метрики. Основной фокус идёт на бизнесовые эффекты, их достаточно легко посчитать по моделям.

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

В работе с CX-долгом мы используем «классический» в сфере UX подход выставления критичности проблемы (Низкая — Высокая — Средняя). Однако сейчас нам не хватает подкрепления цифрами, чтобы «обсчитывать» проекты и брать их в работу. 

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

Решение проблемы приоритизации

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

Сейчас у нас эта проблема закрывается партнёрскими отношениями между РО, который приоритизирует задачи, и экспертом клиентского опыта. Команда искренне заинтересована в UX своего продукта, поэтому фичи, влияющие на юзабилити, приоритизируются вне принятой модели.

Проблема: тяжело следить за статусами

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

О правилах ведения тикетов в таск-трекерах можно и говорить, и писать часами. Се ля ви: даже самые дисциплинированные команды не всегда делают это хорошо. Это нормально — при большом объеме задач что-то обязательно ускользнёт или забудется обновиться.

Сами мы заметили это, когда начали считать статистику исправления юзабилити-проблем: что-то не сходилось. Например, мы точно знали, что юзабилити-проблема уже исправляется (мы ведь участвуем во внедрении изменений на прод). А в базе она всё ещё «В бэклоге». Умножьте на 20. 

Полезли считать вручную и увидели причину, почему уравнение не складывалось: неактуальные статусы. 

Решение проблемы актуализации бэклога

Работы с юзабилити-долгом в нашей команде регламентированы: описаны процессы, оформлены инструкции. Частью этих документов стал блок «Ревью статусов юзабилити-проблем». Мы дополнили его чёткими действиями по ролям — кто и за что отвечает в вопросе ведения таск-трекера, чтобы всё было актуально. 

Например, «опрозрачили» правила и периодичность:

• раз в квартал команда обновляет список проблем, перемещает их в свежий статус при необходимости;

• раз в полгода просматривают ещё и отклонённые задачи — вдруг на что-то появился ресурс или технические возможности.

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

Проблема: моральная усталость

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

Эта часть работы может даваться тяжело. Чем больше людей пользуются продуктом, тем выше шанс, что кто-то наткнется на неблагоприятный сценарий. Иногда у пользователя болит так, что слова для обратной связи он не подбирает — мы слышим это в интервью и читаем в исходниках обращений в саппорт. Чтобы рационализировать негатив, докопаться до сути и прийти к решению, приходится пропускать его через себя — и иногда броня слетает. Хочется, чтобы весь CX-долг был исключительно в статусе «Исправлено». Но это утопия. Все проекты должны приоритизироваться, заниматься только одним не получится, да и вредно. 

И всё же время от времени моя команда испытывает упадок сил. Но пополнять базу юзабилити-долга — наша работа, и мы стараемся поддерживать друг друга.

Решение проблемы моральной усталости

В этом году мы впервые провели ретро, которое сосредоточили на процессе работы с юзабилити-проблемами. Частично по его следам я и пишу сейчас эту статью :) 

Команда выделила себе три официальных часа «на поныть» — и это невероятно освобождающее чувство. Мы выдохнули и за последний час рывком придумали решения самых болючих нюансов. Совместили приятное с полезным.

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

Вдохновляющее заключение

Я честно рассказала о том, с чем моей команде (и, уверена, многим другим) приходится сталкиваться при работе с базой CX-долга. 

Слово «долг», конечно, не вызывает приятных ассоциаций, но в случае интерфейса — абсолютная норма. У идеальных сервисов и продуктов есть только одна общая черта — они никогда не были запущены. 

Любой продукт начинается с «неидеального» MVP. Может меняться аудитория, что-то может произойти с рынком. И те особенности, которые казались нормой, теперь не соответствуют пользовательским привычкам и начинают вызывать у них проблемы.

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

Больше о создании медиасервисов в телеграм-канале Смотри за IT: там рассказываем об инженерных тонкостях, продуктовых находках и полезных мероприятиях, делимся видео выступлений и кадрами из жизни команд Цифровых активов «Газпром-Медиа Холдинга» таких, как RUTUBE, PREMIER, Yappy.