Один из способов становиться лучше как профессионал — это учиться на опыте других. Особенно интересны примеры из больших компаний с налаженными процессами и топовыми специалистами. Из разных источников я попытался восстановить процесс большого редизайна Jira. Ссылки вы найдете в конце.
Проблема на уровне бизнеса
В 2016 году исследователи компании проанализировали интервью и комментарии текущих и ушедших клиентов. Удобство пользования продуктом было камнем преткновения для пользователей Jira.
Продуктовый департамент транслировал эту проблему бизнесу. Повышение удобства использования стало одной из главных целей компании. Улучшения решили оценивать по NPS.
Спрашивать NPS внутри продукта — нормальная практика. А вот запросить доп.информацию о юзере и назначить интервью в том же окошке— это интересно 🙂
Метрики
NPS (индекс лояльности) — это главная метрика Atlassian. Важнее продаж, выручки, LTV и размера месячной аудитории. Но она не подходит для оценки релизов:
-
NPS — это интегральная метрика, на которую влияют многие аспекты бизнеса, а не только удобство продукта.
-
В зрелой компании сложно двигать верхнеуровневые метрики. Практически невозможно заметить улучшение после короткой итерации.
Продуктовым команда была нужна метрика, которая позволит напрямую оценить изменения на юзабилити. Индустриальным стандартом для этой цели является System Usability Scale (SUS).
Придуманный в 1986 году опросник оценки удобства пользования.
Главная проблема SUS при использовании в качестве in-product опроса— количество вопросов сильно прерывает работу пользователей, что снижает количество заполненных анкет.
Исследователи компании предложили использовать более компактные юзабилити-метрики: UMUX и UMUX-Lite. В них всего 4 и 2 вопроса соответственно, что позволяет разместить эти опрос внутри продукта и получать хорошую конверсию в ответ. Притом, ранние исследования доказали сильную корреляцию между этими метриками, SUS и NPS.
Вопросы из UMUX-Lite
Была проведена серия экспериментов, где последовательно спрашивали UMUX-Lite и NPS. Была найдена относительно сильная линейная зависимость между этими метриками (R² = 0.62), что позволило UMUX-Lite стать “мостиком” для NPS. Продуктовым командам выдали формулу “перегонки” из одного значения в другое: NPS = 3.18 ∗ (UMUX-Lite) − 200.6. Это позволило выставлять реалистичные цели на релизы.
NB! Не переиспользуйте эту формулу у себя. Установите свой процесс замера этих метрик и на своей аудитории найдите формулу зависимости.
Приоритизация инициатив
У членов команды было много предложений как сделать Jira удобнее. Нужно было выстроить систему приоритетов. Для этого снова обратились к комментариям из NPS. Вдохновившись классификацией требований к программным системам FURPS, фидбек разбили по следующим темам:
-
Reliability — требования к надежности.
-
Usability — требования к удобству использования.
-
Functionality — функциональные требования.
Каждая тема содержит иерархию из категорий и отдельных фичей.
Продуктовая команда Atlassian получает около 2000 комментариев в месяц. Для тэгирования (кодинга) такого объема информации ребята взяли к себе несколько стажеров. Разметка идет в общем Google Spreadsheet. Каждый комментарий может быть включен в 3 категории и обязательно назначается на ответственную команду.
Каждую потенциальную фичу / проблему они рассматривают в трех измерениях: размер аудитории, частота использования и доля негативного фидбека.
Feature 1 — хороший кандидат для исправления. Большое количество аудитории часто ей пользуется и доля негативных комментов (Pain Index) тоже высока.
Юзабилити-проблемы также разбивали на три популярных категории, которые встречались в комментариях. Это позволило прицельно решать проблемы.
Числа в ячейках — это количество детракторов, которые упомянули о проблеме
Инструмент мониторинга: UX ScoreCard
Для продукта составляют набор метрик за которыми хочется следить. В идеале, этот набор метрик постоянен на всех стадиях разработки продукта, но на практике это не так.
Например, NPS мы можем получить только после выпуска продукта. Или метрики в стиле “время на выполнения задачи” хорошо замеряются в юзабилити-тестах, но не всегда четко отслеживаются “в бою”, т.к. мы не знаем контекст пользователя. Исключением, конечно, являются страницы с четкими Call to Action.
Поэтому в Atlassian используют два дашборда:
-
Early Signal Testing Scorecard (ESTS) — для дизайн-команды выносят метрики, которые помогают принимать решения на этапе разработки. Для этого они создали собственный мини-фреймворк — Early Signal Testing (никаких откровений особо по ссылке нет, но можно пощелкать презентацию).
-
Instrumented Scorecard — для продуктовой команды, когда фича уже в проде. Сюда выносят метрики, которые составлены по Google HEART и UMUX-Lite (это, видимо, замеряет Happiness).
Early Signal Testing Scorecard отображает метрики по новым и текущим юзерам
Находим эффект от продуктовых изменений в UMUX-Lite
Продуктологам хочется понимать “стрельнул” ли апдейт. Для этого аналитик строит линейную модель, которая пытается предсказать значение UMUX-Lite.
Линейные модели — не самые точные ML-алгоритмы, зато очень легко интерпретируются, что и нужно в работе над продуктом. Можно посмотреть, дал ли апдейт ожидаемый вклад. Ну или можно воспользоваться A/B-тестами.
Вывод
Анализ комментариев из NPS позволил подсветить проблемные места продукта. Через процесс кодинга удалось “оцифровать” жалобы клиентов и использовать количество жалоб как один из факторов в расстановке приоритетов.
Проблема медленной реакции NPS на изменения была решена созданием отдельной метрики для продуктовых команд.
UMUX-Lite стал мостиком между дизайнерами, продуктологами и бизнесом, который позволил быстрее получать обратную связь на релизы и понимание вклада в цель компании.
Более подробнее про метрику и методологию можно прочитать здесь: Measuring Usability: From the SUS to the UMUX-Lite.