Январь 2019 — martsen.me

Я не нашел специальной литературы по продуктовым исследованиям “от А до Я”. Есть практические книжки и статьи с “лайфхаками” и “самым важным”, но этого мне уже недостаточно.

Я посмотрел на опыт и работу топовых продуктовых исследователей. Почти все имеют PhD в социологии, психологии или экономике. Довольно интересные науки для продуктолога.

Это навело на мысль — что же такое хорошее исследование в этих областях? Я взял пару академических книжек по исследованиям, которые рекомендуют в интернетах для ученых. Буду читать и выписывать интересные вещи. А пока, давайте познакомимся с основными понятиями.

Исследовательская проблема и вопрос

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

В чем ценность продукта для нашего клиента? *Что из себя представляет этот феномен?*

Почему пользователи возвращаются в наш продукт? *Что влияет на наблюдаемый феномен?* 1. Какая фича “цепляет” пользователи? *Какой фактор влияет сильнее?*

Как повлияет новая фича? *Что будет, если добавить других факторов?*

Теория

В любом исследовании пытаются подтвердить или расширить существующую теорию, или создать новую.

Теория имеет свою терминологию, систему и законы. Также она объясняет и предсказывает события.

По моему опыту, в продуктовой разработке напрямую не говорят о “теориях”, но часто подразумевают их. Но если абстрагироваться, то созданные в компании персоны или джобы будут примером локальной продуктовой теории.

В работе мы иногда ссылаемся на известные теории. Мы про них слышали или интуитивно понимаем. Например, ребята играющие с публикой “выгодными предложениями” явно вдохновляются теорией перспектив.

Подходы и методологии

Поняв вопрос, выбираем подход к исследованию:

Качественный (qualitative)
Количественный (quantitative)
Смешанный (mixed-methods)

Несмотря на названия, исследования не бывают абсолютно качественные или количественные. Они склонны быть скорее качественные, чем количественные и наоборот. Смешанные подходы балансируют посередине. — Несмотря на названия, исследования не бывают абсолютно качественные или количественные. Они *склонны* быть скорее качественные, чем количественные и наоборот. Смешанные подходы балансируют посередине.

Исследователь выбирает подход в зависимости от задачи и ресурсов. Он включает в себя:

ограничения и аксиомы
поэтапный процесс сбора и анализа данных
набор методов

Методы

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

Кратко

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

В продуктовой разработке я чаще всего сталкиваюсь с проблемой и выбором метода. Это работает для операционных и мелких тактических вопросов. Когда мы задумываемся о стратегических инициативах, то требования к исследованию повышаются. Мы должны осветить все нюансы выводов и сто раз все перепроверить. Заказчикам и исследователям нужна методология, которая будет прозрачна и понятна.

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

Один из способов становиться лучше как профессионал — это учиться на опыте других. Особенно интересны примеры из больших компаний с налаженными процессами и топовыми специалистами. Из разных источников я попытался восстановить процесс большого редизайна Jira. Ссылки вы найдете в конце.

Проблема на уровне бизнеса

В 2016 году исследователи компании проанализировали интервью и комментарии текущих и ушедших клиентов. Удобство пользования продуктом было камнем преткновения для пользователей Jira.

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

Спрашивать NPS внутри продукта — нормальная практика. А вот запросить доп.информацию о юзере и назначить интервью в том же окошке— это интересно :) — Спрашивать NPS внутри продукта — нормальная практика. А вот запросить доп.информацию о юзере и назначить интервью в том же окошке— это интересно 🙂

Метрики

NPS (индекс лояльности) — это главная метрика Atlassian. Важнее продаж, выручки, LTV и размера месячной аудитории. Но она не подходит для оценки релизов:

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

Продуктовым команда была нужна метрика, которая позволит напрямую оценить изменения на юзабилити. Индустриальным стандартом для этой цели является System Usability Scale (SUS).

Придуманный в 1986 году опросник оценки удобства пользования.

Главная проблема SUS при использовании в качестве in-product опроса— количество вопросов сильно прерывает работу пользователей, что снижает количество заполненных анкет.

Исследователи компании предложили использовать более компактные юзабилити-метрики: UMUX и UMUX-Lite. В них всего 4 и 2 вопроса соответственно, что позволяет разместить эти опрос внутри продукта и получать хорошую конверсию в ответ. Притом, ранние исследования доказали сильную корреляцию между этими метриками, SUS и NPS.

Была проведена серия экспериментов, где последовательно спрашивали 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.

Источники

Актуальные материалы по продуктовой аналитике и исследованиям лежат в моем телеграм-канале Product Science.

Открыть Product Science в Telegram

Месяц: Январь 2019

Продуктовое исследование, ч.1 основные термины