В 2016 году исследователи компании проанализировали интервью и комментарии текущих и ушедших клиентов. Из статьи вы узнаете, что сделала продуктовая команда Jira, чтобы сократить churn.
Один из способов становиться лучше как профессионал — это учиться на опыте других. Особенно интересны примеры из больших компаний с налаженными процессами и топовыми специалистами. Из разных источников я попытался восстановить процесс большого редизайна Jira. Ссылки вы найдете в конце.
Проблема на уровне бизнеса
В 2016 году исследователи компании проанализировали интервью и комментарии текущих и ушедших клиентов. Удобство пользования продуктом было камнем преткновения для пользователей Jira.
Продуктовый департамент транслировал эту проблему бизнесу. Повышение удобства использования стало одной из главных целей компании. Улучшения решили оценивать по NPS.
Спрашивать NPS внутри продукта — нормальная практика. А вот запросить доп.информацию о юзере и назначить интервью в том же окошке— это интересно 🙂
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 стал мостиком между дизайнерами, продуктологами и бизнесом, который позволил быстрее получать обратную связь на релизы и понимание вклада в цель компании.
Что такое «метрика»? Каковы свойства хорошей метрики? Метрики в UX и фрейморки для измерений.
Что такое «метрика»?
Это число, которое характеризует какое-либо из свойств наблюдаемого процесса. Процессы в реальной жизни очень сложные и для глубокого понимания обычно используется набор метрик. Они смотрят на процесс с разных углов.
Метрики помогают собирать обратную связь с наблюдаемого явления. На основе обратной связи идет корректировка дальнейших действий. Термин «обратная связь» изначально появился в механике и инженерии. Постепенно он стал использоваться в менеджменте, клиентском сервисе и разработке продуктов.
Вот как описывают фидбек на «общем уровне»
Feedback is as a generic method of controlling a system by using past results to affect future performance. Approaches which keep a system operating within tight parameters, demonstrate negative feedback. That’s not pessimistic or bad feedback, but feedback that prompts the system to maintain control. Negative feedback is actually good feedback because it yields greater efficiency and performance. Positive feedback, by contrast, causes the system to keep going, unchecked. Like a thermostat that registers the room as too warm and cranks up the furnace, it’s generally meant to be avoided.
> “Negative feedback is actually good feedback because it yields greater efficiency and performance.”
— James Watt, Scottish inventor & mechanical engineer.
Число в вакууме не несет смысла. Для получения пользы от метрики мы должны сравнить ее с другим показателем. Примеры:
сравнивая свои показатели со стандартами (бенчмарками) индустрии, можно понять наше положение на рынке.
отслеживая показатели во времени, можно понять как развивается наша компания относительно «прошлой» себя.
Свойства хорошей метрики
Консистентность (воспроизводимость) результатов (англ. reliability) — если повторить исследование/эксперимент, то мы получим те же числа.
Валидность (англ. validity) — мы уверены, что метрика измеряет именно то, что мы хотим замерить.
Чувствительность (англ. sensitivity) — метрика хорошо реагирует на изменения.
Если метрика не удовлетворяет этим критериям, то мы получаем неверную обратную связь на наши действия от окружающей среды.
Метрики в UX
Измерение в UX — это количественная оценка наблюдений и мнений пользователей. Они помогают снизить неопределённость относительно того, насколько удобно пользоваться продуктом на самом деле.
UX-метрики оценивают качество взаимодействия человека с интерфейсом при выполнении определенной задачи. Понятие «задачи» многогранно, обычно выделяют три уровня. Естественно, границы уровней размыты. Разберем на примере поискового продукта:
Макро — найти нужную информацию в поисковике.
Мезо — прочитать результаты выдачи, переформулировать вопрос.
Микро — ввод запроса, построчное сканирование текста в ответе.
Альтернативная классификация:
микро- и мезо-уровни еще иногда называют юзабилити-метриками.
макро-уровень иногда называют Customer Experience (CX-метрики). Такие метрики можно использовать на уровне всего продукта или бизнеса.
User Experience vs. User Centric
Эти понятия легко спутать. UX-метрики это подмножество User Centric метрик. Но не все User Centric метрики являются UX.
Примеры User Centric показателей, которые не являются UX-метриками:
User-Level LTV — показывает сколько мы заработаем с определенного пользователя безотносительно используемого продукта/услуги.
Количество сессий на человека — показывает активность человека в продукте, но ничего не говорит про «качество» это взаимодействия.
Средняя скорость загрузки страницы на человека — замеряет техническое свойство продукта, но не говорит о том, как пользователь это воспринимает.
NPS — замеряет лояльность потребителей к бизнесу, но не говорит о качестве реализации конкретной задачи или сценария.
Эти метрики также отталкиваются от человека, но абстрагируются от интерфейса и/или задачи, а работают уровне продукта или бизнеса. Это не означает, что UX-специалисты не используют их в работе. Такие метрики являются хорошим мостиком между дизайном, продуктом и бизнесом.
В конце 80-х начался период компьютеризации бизнеса и многие компании хотели понять, стоит ли вообще в это вкладываться. Тогда и пошел «заказ» от корпораций в университеты и другие исследовательские организации на разработку методологий оценки эффекта он внедрения IT.
Ученые использовали имеющийся аппарат из психологии, социологии, эргономики, экономики и других наук, чтобы придумать индикаторы, которые удовлетворяют «свойствам хорошей метрики» (смотри начало статьи).
Вот что входит в «джентльменский набор»…
System Usability Scale (SUS)
Самый известный и, наверное, старый способ измерения удовлетворения от интерфейса — это опросник System Usability Scale (SUS).
После работы в системе, респондент проходит опрос из 10 вопросов. По определенной формуле считается показатель, который лежит в диапазоне от 1 до 100. Он характеризует сложность интерфейса:
Концепция «простоты использования» используется во многих других метриках. Например, за метрикой Customer Effort Score стоит простая идея, что чем проще пользоваться продуктом или услугой тем более лояльными будут клиенты. Но мне удалось найти какие-либо подтверждения на этот счет (хотя мысль логичная).
Также, между одним вопросом про «простоту использования» с огромным SUS есть корреляция 90%. Это еще один «плюсик в карму» для этой метрики.
Достоинство этой метрики в том, что ее можно замерять online, т.к. конверсия в ответ будет высокой. Если в продукте есть четкая воронка, то можно собирать оценки в конце пути.
Usability Metric for User Experience (UMUX)
Эта метрика разработана в качестве альтернативы SUS. Акцент делается на измерении двух свойств продукта: функциональность и простота.
В UMUX четыре вопроса, а в усовершенствованной версии UMUX-Lite их два:
Удовлетворенность — еще одна концепция в мире User Experience. Это популярная метрика, которую обычно спрашивают после завершения какого-либо сценария. Самый популярный вариант — после обращения в техническую поддержку.
> “How would you rate your overall satisfaction with the [goods/service] you received?”
Но есть примеры, когда CSAT измеряется уровне всего продукта или компании. American Customer Satisfaction Index уже больше 20 лет каждый год опрашивает сотни тысяч американцев на предмет удовлетворенностью продуктами или услугами компаний из разных сфер и индустрий.
Интересно, что между CSAT компании и ее финансовыми показателями имеется хорошая связь. Историю и бенчмарки можно найти на этом сайте.
Single Usability Metric (SUM)
Это 6 показателей, которые по хитрой формуле превращаются в число от 1 до 100. Эти показатели включают в себя:
Метрики на основе поведения респондентов
Справился ли респондент с задачей
Фактически проведенное время над задачей
Количество ошибок
Субъективные метрики-опросы с 5-бальной шкалой для ответа:
Воспринимаемое время над задачей
Воспринимаемая сложность
Удовлетворенность (тот же самый CSAT)
По задумке авторов, эта комбо-метрика предоставить более взвешенный взгляд на пользовательский опыт и упростить принятие решений. Многие агентства и компании ее используют, но открыто не делятся опытом.
Шкала от 1 до 100 непонятна стейкхолдерам. Где отсечка, после которой «все хорошо?»
Фактическое и воспринимаемое время над задачей не всегда коррелируют. Люди иногда отвлекаются или просто «тупят», но при этом считают, что с задачей справляются быстро. Время — это шумная метрика.
Количество ошибок на практике заранее неизвестно наперед. Поэтому с точки зрения метрики это просто шум.
Net Promoter Score (NPS)
Очень популярная метрика лояльности потребителя к бренду или услуге. Поэтому остановимся на ней подробнее.
У этой метрики есть «набирающий популярность брат» Actual NPS (aNPS), который пытается устранить одну из ошибок NPS — спрашивать про мнение и будущее.
Но это не самая главная беда этой метрики в контексте измерения UX. Бренд «собирает» под собой не только продукт с его дизайном, но и работу поддержки/отдела продаж и новости о бренде.
> “Слишком много факторов влияет на NPS.”
На практике мы получаем слабую чувствительность к UX-изменениям. Сторонними исследователя установлено, что «вклад» UX в NPS составляет не более 66%.
Но есть ситуации, когда NPS можно использовать как UX-метрику:
Если респондент не знает, продукт какого бренда он тестирует / использует.
Если весь продукт держится только на одной макро-задаче и можно пренебречь влиянием других факторов
Примеры, когда NPS подходит и не подходит как UX-метрика.
Порекомендуете ли вы AdBlock друзьям или коллегам?
ОК, т.к. основной сценарий в AdBlock — это блокировка рекламы на сайтах. Однозначная ассоциаоция.
Порекомендуете ли вы Wrike друзьям или коллегам?
НеОК:
Wrike это продукт с множеством макро-задач внутри: планирование проектов, управление ресурсами, хранилище документации. Как понять, UX какого сценария дает больший вклад?
Wrike используется для управления проектами и людьми. Есть люди, которые просто не любят работать, поэтому будут ставить плохие оценки в NPS даже если продукт будет идеален.
Wrike это b2b-компания, в которой «продуктом» является не только сайт, но и поддержка, обучающие материалы и размер скидки, который может дать отдел продаж.
Основные покупатели Wrike — топ-менеджеры. Рядовые сотрудники могут просто не иметь знакомых топ-менеджеров, которые ищут систему управления проектами. Некому рекомендовать.
Некоторые люди «оставляют работу на работе» и не рекомендуют друзьям рабочие инструменты. А все коллеги и так уже пользуются этой системой.
Некоторые компании пытаются «уточнять» NPS и спрашивать про конкретный опыт в продукте. Но это тогда уже не NPS, а что-то другое. Примеры:
С какой вероятностью вы порекомендуете продавать товары на Авито друзьям или коллегам?
Порекомендуете ли вы слушать музыку в Spotify друзьям или коллегам?
Другие метрики
Существует еще большое количество UX-метрик. Какие-то требуют покупки лицензий, а какие-то используются в узкоспециализированных областях:
SUPR-Q, qxScore, User Experience Questionnaire (UEQ) и AttrakDiff — опроссники, которые продвигают идею единого числа в UX для всего и вся.
И еще сотни других метрик…
Фреймворки и подходы
Метрик много, но не всегда понятно какую использовать под вашу задачу. Google в 2010 году опубликовала научную работу по HEART — подход, который помогает выбрать метрику для измерения пользовательского опыта под разными углами. Фреймворк был опробован на 20 проектах внутри Google, а затем пошел “во вне” компании.
> “HEART комбинирует мнения пользователей через опросы и поведенческие продуктовые метрики”
— Антон Марцен
Tomer Sharon, бывший UX Researcher в Google и WeWork и нынешний глава по ресерчу в Goldman Sachs, расписал подробно про каждый “срез” сквозь призму своего опыта и дает примеры метрик:
Метрика нужна, чтобы собирать обратную связь из внешнего мира и корректировать свои планы. Числа без привязки к контексту никому не интересны.
User Experience — это очень широкая область, поэтому и метрики в нем совершенно разные. Они могут фокусироваться на удобстве микро-взаимодействий пользователя с системой и на долгосрочных целях человека в продукте. Единого термометра не изобрели (хотя многие пытаются). Главное — UX-метрики замеряют восприятие человека.
Сделать достоверную метрику очень сложно. Изучите стандартные способы измерения пользовательского опыта, которые используется повсеместно. Не придумывайте велосипед.
Для систематизации работы используйте HEART-фреймворк от Google. Освоив этот инструмент, пробуйте новый или придумайте свой подход.
Все измерения в UX крутятся вокруг ограниченного набора концепций. Будут придуманы новые метрики, а концепции будут неизменны.
Актуальные материалы по продуктовой аналитике и исследованиям лежат в моем телеграм-канале Product Science.
Про фундаментальные определения в исследованиях, о которых забывают практики.
Я не нашел специальной литературы по продуктовым исследованиям “от А до Я”. Есть практические книжки и статьи с “лайфхаками” и “самым важным”, но этого мне уже недостаточно.
Я посмотрел на опыт и работу топовых продуктовых исследователей. Почти все имеют PhD в социологии, психологии или экономике. Довольно интересные науки для продуктолога.
Это навело на мысль — что же такое хорошее исследование в этих областях? Я взял пару академических книжек по исследованиям, которые рекомендуют в интернетах для ученых. Буду читать и выписывать интересные вещи. А пока, давайте познакомимся с основными понятиями.
Исследовательская проблема и вопрос
Собственно, зачем вообще нужно проводить исследование. Понимая природу вопроса, специалист выберет лучший способ ответить на него. Примеры:
В чем ценность продукта для нашего клиента? *Что из себя представляет этот феномен?*
Почему пользователи возвращаются в наш продукт? *Что влияет на наблюдаемый феномен?* 1. Какая фича “цепляет” пользователи? *Какой фактор влияет сильнее?*
Как повлияет новая фича? *Что будет, если добавить других факторов?*
Теория
В любом исследовании пытаются подтвердить или расширить существующую теорию, или создать новую.
Теория имеет свою терминологию, систему и законы. Также она объясняет и предсказывает события.
По моему опыту, в продуктовой разработке напрямую не говорят о “теориях”, но часто подразумевают их. Но если абстрагироваться, то созданные в компании персоны или джобы будут примером локальной продуктовой теории.
В работе мы иногда ссылаемся на известные теории. Мы про них слышали или интуитивно понимаем. Например, ребята играющие с публикой “выгодными предложениями” явно вдохновляются теорией перспектив.
Подходы и методологии
Поняв вопрос, выбираем подход к исследованию:
Качественный (qualitative)
Количественный (quantitative)
Смешанный (mixed-methods)
Несмотря на названия, исследования не бывают абсолютно качественные или количественные. Они склонны быть скорее качественные, чем количественные и наоборот. Смешанные подходы балансируют посередине.
Исследователь выбирает подход в зависимости от задачи и ресурсов. Он включает в себя:
ограничения и аксиомы
поэтапный процесс сбора и анализа данных
набор методов
Методы
Это конкретные инструменты, которые исследователь использует в работе: глубинное интервью, опрос, анализ логов и т.д. Не буду сейчас подробно на этом останавливаться. Про них часто пишут и говорят. Обычно для решения практических задач, мы сразу спешим выбрать метод, чтобы ответить на вопрос. В одной из следующих статей разберем место методов в конкретных подходах.
Кратко
Все вышеперечисленное используется учеными, чтобы провести исследование и попытаться сделать прорыв в науке.
В продуктовой разработке я чаще всего сталкиваюсь с проблемой и выбором метода. Это работает для операционных и мелких тактических вопросов. Когда мы задумываемся о стратегических инициативах, то требования к исследованию повышаются. Мы должны осветить все нюансы выводов и сто раз все перепроверить. Заказчикам и исследователям нужна методология, которая будет прозрачна и понятна.
Результатами верхнеуровнего исследования будет пользоваться несколько стейкхолдеров. Выводы должны логично ложиться на знания, которые есть у отделов и команд. Это мне напоминает свойство хорошей теории, которая должна все объяснять.
В 2016 году исследователи компании проанализировали интервью и комментарии текущих и ушедших клиентов. Из статьи вы узнаете, что сделала продуктовая команда Jira, чтобы сократить churn.
Один из способов становиться лучше как профессионал — это учиться на опыте других. Особенно интересны примеры из больших компаний с налаженными процессами и топовыми специалистами. Из разных источников я попытался восстановить процесс большого редизайна Jira. Ссылки вы найдете в конце.
Проблема на уровне бизнеса
В 2016 году исследователи компании проанализировали интервью и комментарии текущих и ушедших клиентов. Удобство пользования продуктом было камнем преткновения для пользователей Jira.
Продуктовый департамент транслировал эту проблему бизнесу. Повышение удобства использования стало одной из главных целей компании. Улучшения решили оценивать по NPS.
Спрашивать NPS внутри продукта — нормальная практика. А вот запросить доп.информацию о юзере и назначить интервью в том же окошке— это интересно 🙂
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 стал мостиком между дизайнерами, продуктологами и бизнесом, который позволил быстрее получать обратную связь на релизы и понимание вклада в цель компании.
