В 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 стал мостиком между дизайнерами, продуктологами и бизнесом, который позволил быстрее получать обратную связь на релизы и понимание вклада в цель компании.
UPD: Статье идет третий год, а она все еще пользуется популярностью. Поэтому я актуализировал ее и поправил “битые ссылки”.
В начале 2018 года на большой IT-конференции я очень много общался с разными людьми: основатели компаний, топ-менеджмент, менеджеры продукта, дизайнеры.
Когда я говорил, что работаю продуктовым аналитиком, то почти каждый раз слышал различные предположения, чем я занимаюсь. Видимо, приставка “продуктовый” откидывалась, т.к. не несет ценности для неискушенного слушателя, и оставался просто “аналитик”.
Мне показалось, что у людей из заказной разработки и корпораций, “аналитик” ассоциировался чаще с человеком, который “сидит на каждой встрече, что-то записывает и потом делает документацию”. В продуктовых и игровых компаниях “аналитик” это чаще всего тот, кто “вечно занят и что-то там считает”.
Покопавшись немного в рунете, я так и не нашел толковой статьи, где в одном месте написано про аналитиков. Зато в процессе нашел огромную карту компетенций аналитиков (ссылка в конце статьи в доп.материалах).
Пора расставить точки над i и внести ясности. Собрал классификацию аналитиков, которые часто встречаются в компаниях в России и СНГ. Различную “экзотику” не учел.
Будет полезно тем, кто ищет аналитика себе в команду, кто непосредственно сталкивается с ними в работе и тем, кто хочет разбираться в особенностях работы аналитиков.
Бизнес-аналитик
Что делает
Бизнес-аналитик понимает проблемы и возможности бизнеса в контексте требований и рекомендует решения, позволяющие организации достичь своих целей. Т.к. бизнес-анализ очень широкая сфера деятельности, принято конкретизировать области работы конкретного специалиста (если, конечно, он не супермен):
Стратег-консультант — работает с топ-менеджментом над целями, стратегией и политикой компании.
Архитектор бизнес-процессов — модернизирует и/или оптимизирует бизнес-процессов компании. Обеспечивает ее операционную эффективность. Почитайте про кайдзен.
Результат работы
Помогают в управленческих решениях и улучшают процессы компании.
Отличительная черта
Понимает особенности какой-либо отрасли в целом (нефть, FMCG) или какой-то деятельности, которая не зависит от типа компании (продажи, логистика, финансы).
Где работает
В крупной компании любого типа или в консалтинге.
Системный аналитик
Что делает
Работает с техническими требованиями: выявляет, собирает, документирует и согласует.
Результат работы
ТЗ для разработки и, иногда, документация
Спокойствие всех заинтересованных сторон
Отличительная черта
Хорошо разбирается в специфике IT-решений.
Где работает
IT-компания, которая занимается интеграцией и заказной разработкой (аутсорсинг).
Не IT-компания, которая разрабатывает внутренние информационные системы in-house и интегрируют сторонние.
В IT-компаниях основные процессы завязаны на разработку ПО, поэтому роли системного и бизнес-аналитика могут сливаются в единого человека.
UX-аналитик
Что делает
Он исследует взаимодействия пользователей с цифровым продуктом, изучает особенности и проблемы этого взаимодействия. Работает с качественными инструментами (интервью, фокус-группы, анализ обратной связи) и количественными (опросы, side-by-side)
Результат работы
Интуитивно понятный целевой аудитории и удобный в использовании продукт.
Отличительная черта
Хорошо разбирается в потребностях пользователей и может транслировать их в выгоду для бизнеса.
Где работает
Компания, которая создает свои собственные цифровые продукты.
IT-компания, которая занимается интеграцией и заказной разработкой (аутсорсинг).
Аналитик данных (Data Analyst)
Что делает
Подготавливает и обрабатывает данные для бизнеса (ETL). Работает в Excel и/или специализированных инструментах Business Intelligence. Умеет немного программировать. Часто имеет “специализацию”, которая зависит от того, в каком отделе работает:
Веб-аналитик в отделе маркетинга
Аналитик продаж
Финансовый аналитик
Продуктовый аналитик
HR-аналитик
Результат работы
Выводы и рекомендации для заказчика
Инструменты для мониторинга (отчеты и дашборды)
Отличительная черта
Фанатеют от изучения данных
Где работают
В компании с 30+ сотрудников, где хотят принимать решения на основе данных.
Data Scientist
Что делает
В Европе и США Data Scientist — это Data Analyst на “стероидах” с более техническим уклоном. Он умеют работать с “большими данными” и разбирается в машинном обучении для применения “продвинутой аналитики”. В странах СНГ под Data Scientist’ом чаще подразумевает разработчик, который разрабатывает ML-продукты: системы рекомендаций, поиск, распознавание голоса. Правда где-то по середине.
> “Это человек, который разбирается в статистике лучше любого программиста и способен написать программный код лучше любого статистика”
— Josh Wills, Director of Data Engineering at Slack
Результат работы
Выводы и рекомендации для заказчика.
Инструменты для мониторинга (отчеты и дашборды).
Продукт на основе машинного обучения.
Отличительная черта
Любит математику и данные.
Где работает
Компания, которая создает свои собственные продукты
IT-компания, которая занимается интеграцией и заказной разработкой (аутсорсинг)
Запомнить
В зависимости от специфики компании, человек может совмещать несколько аналитических ролей. Я встречал системных аналитиков, которые хороши в UX и аналитиков продукта, которые разбираются в маркетинге. Все роли разные, у них разные инструменты и разная зона ответственности, но их объединяют несколько факторов:
Они выступают как консультанты в своей предметной области. Аналитик изучает проблему, устанавливает причинно-следственные связи и дает выводы с рекомендациями.
Для изучения предмета аналитик использует качественные и/или количественные данные:
Бизнес-аналитик изучает компанию через интервью со стейкхолдерами.
Data Analyst использует SQL для анализа активности.
UX-аналитик проводит пользовательские исследования.
Что такое «метрика»? Каковы свойства хорошей метрики? Метрики в 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.
Впечатления от самой большой конференции по Human-Computer Interaction (HCI). Исследователям и разработчикам будет интересно!
Что это?
Конференция проводится организацией ACM (Association for Computing Machinery). Это огромнейшая ассоциация, которая курирует много движений в мире технологий. Существует с 1947 года.
В состав AMC входят поднаправления (SIG, Special Interest Groups). Одно из направлений это Human-Computer Interaction (HCI, иногда пишут CHI).
Я немного рассказывал про HCI в своем докладе на Киви Кухне (слайды). Вкратце, это направление науки изучает как люди выполняют задачи используя технологии. Продемонстрирую разнообразие тем, поигравшись с кусками определения:
Технологии: web/mobile/часы/протезы/VR/AI/»умная ткань» и так далее и тому подобное.
Дисциплина смешивает подходы из Computer Science, всех социальных наук и подмешивая иногда биологию с физикой. На конференцию приехало почти 4000 человек.
The ACM CHI Conference on Human Factors in Computing Systems is the premier international conference of Human-Computer Interaction. CHI — pronounced ‘kai’ — is a place where researchers and practitioners gather from across the world to discuss the latest in interactive technology.
Что там показывают?
Полная программа включала в себя ~1200 уникальных активностей.
Презентация научных работ (~700 штук)
Выступление — 15 минут:
Что за проблему хотим решить? Почему это важно?
На какие вопросы нам нужно дать ответ? Какие гипотезы?
Выбор и обоснование методологии
Процесс сбора данных: как и с кого собирали
Анализ данных и результаты
Рекомендации по реализации и/или освещение новых вопросов
Дают ссылку на подробную статью (10+ страниц), где описаны все нюансы, расчеты и релевантные работы.
Пять минут на вопросы из аудитории.
Очень крутой формат, который позволяет ознакомится с работой, а затем чуть ли не воспроизвести ее самому.
> “В HCI изучают как люди выполняют задачи используя технологии.”
Постерная сессия (~250 штук)
Постер — это зачастую красиво рассказанная история с картинками и тезисами на формат А1. По-сути, это инфографика по научной работе, которую автор также прилагает на конференцию.
В принципе, из постера можно было бы сделать и обычный доклад. Насколько я знаю, кто-то сам не хочет запариваться, а кого-то не допускает комиссия.
На специальной площадке расположены ~50 стоек, на которые в первой половине каждого дня авторы вешают свои работы. Пока они готовятся, можно присмотреть интересные для себя вещи. К началу второго перерыва между сессиями, они уже готовы и посетители конференции идут туда коротать время. Каждый постер презентуют 1-2 человека. Можно (и нужно) подходить к ним, узнавать что за ресерч и просто болтать за жизнь.
Я поговорил с коллегой из Atlassian, который разработал иерархию метрик для редизайна Jira. Еще скоротал время с корейскими студентами, которые применяли теорию графов кучи всего, в т.ч. для анализа активности фан-сообществ в социальных сетях. Ну и просто постоял около многих стендов и послушал авторов. У многих поистине горят глаза от того, чем они занимаются.
Курсы, воркшопы и мастер-классы (~30 штук)
CHI — это еще и место учебы. Преподаватели из топовых универов и компаний, дают интенсивны размером от 2 до 4 академических пар.
Составление такой модели требует поистине глубокого понимания задач пользователей и продвинутой математики. Тут я впервые увидел использование дифуров для продуктовой работы, а не в задачах ракетостроения.
Интерактивные стенды (много)
Множество научных лабораторий со всего мира: VR-шлемы, роботы, интерфейсы мозг-компьютер и много всякого…
Топовые компании из США, Европы и Азии организовали свои площадки и пылесосили контакты всех, кто потенциально интересен. Интересно отличилась Apple. От них были две вакансии, где неприметно и мелким шрифтом написаны общие требования к кандидатам. А снизу была приклеена папка, куда надо кидать резюме. Папка была очень уродливая, словно мусорная урна…
Яркие спикеры
Вступительный и финальный доклады были на высоте. Первый доклад заряжал позитивом и вдохновлением. Последний рассказывал о глобальном видении и стратегии Google на рынке умных вещей. Такое стоит послушать (оцените спикера).
CHI 2019 Closing Keynote - Ivan Poupyrev Technology Woven In ABSTRACT The digital revolution has changed every aspect of our lives, the very essence of how w...
Из минусов
Конференция, прежде всего, ориентирована на академическое сообщество. Научный совет решает, что будет презентовано. Они смотрят на какие-то формальные вещи, ссылки на литературу и автора публикации. Как я понял из кулуарных бесед, практикам сюда пробиться крайне тяжело. У статьи должен быть хотя бы один автор с академическим опытом.
Предыдущее ограничение сильно отражается на докладах. Многие выступления сложно или невозможно применить на практике - авторы не сильно задумываются об этом. 80% выступлений заканчиваются фразой
Мы копнули этот вопрос глубже. Спустя 3 месяца исследований мы поняли, что он оказался сложнее чем мы предполагали. Наш вклад в HCI сообщество заключается в том, что мы нашли новые вопросы, на которые надо дать ответ. Надеюсь, это вдохновит исследователей заняться этим в будущем.
Получается ресерч ради ресерча. Явно не хватает какой-то практической нотки. Хорошо, чтобы есть остальные 20% докладов. В них презентуют либо сотрудники из ведущих IT-компаний, либо ученые из топовых универов, которые делают исследования по заказу индустрии. Нужно проделать большую подготовительную работу по составлению расписания, чтобы попадать только на интересные выступления.
>
“Конференция, прежде всего, ориентирована на академическое сообщество.”
Необычные вещи
Призывы и протесты и за равноправие/разнообразие
Я замечал намеки разного размера:
Разговоры людей.
Стикеры с призывами на специальной стене "вопросов и предложений". Мало черных/женщин/практиков/инвалидов спикеров.
Я, наверное, не понимаю всей внутренней кухни, но по мне это была самая "социально-благоприятная" конференция, на которой я был:
Спикеры и участники были всех возрастов, наций, полов и конфессий.
Были сурдопереводчики на некоторых докладах и ключевых кейноутах. Широкие проходы, специальные подъемники.
На конференции можно было покушать все виды еды: глютен-фри, веганская, кошерная и еще 50 видов.
Один из самых популярных тегов в научных работах этого года - Accessibility.
Во всех исследованиях всегда указывали, что у них 50-50 мужчин и женщин. В одном выступлении проскользнули числа 75-25, так спикер быстро перелистнул слайд, а из зала донесся небольшой смех.
Кругом информация об экологии и вторичном использовании материалов.
Ясно, что всегда можно сделать лучше/выше/сильнее. Непонятно, когда надо останавливаться.
Обнесли кабинет
В первый день обокрали кабинет, где проходил один из курсов. Слушатели вышли перекусить, а по возвращению остались ни с чем. Как так?))
Вкратце
Несмотря на академичность, сюда стоит ехать, чтобы реально узнать про новые подходы и словить инсайтов. Как я узнал в беседе с одним из Гуглеров, CHI одна их немногих конференций куда катаются синьоры, чтобы поучиться.
Под вопросом ценность для продуктовых менеджеров и стратегов:
Слишком сильно углубляются в детали, много воды.
За трендами/инсайтами можно следить более эффективно.
Нетворкинг с отдельными спикерами/участниками будет полезен, но можно найти другие способы познакомиться.
Совсем не нужно ехать, если вы работаете на уровне операционки/тактики.
Можно попробовать похайрить народ. Думаю, будка на выставке хорошо бы конвертировала в лидов на собеседования. Много умных людей-теоретиков. В комбинации с одним практиком может получится интересная связка.
Про фундаментальные определения в исследованиях, о которых забывают практики.
Я не нашел специальной литературы по продуктовым исследованиям “от А до Я”. Есть практические книжки и статьи с “лайфхаками” и “самым важным”, но этого мне уже недостаточно.
Я посмотрел на опыт и работу топовых продуктовых исследователей. Почти все имеют 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 стал мостиком между дизайнерами, продуктологами и бизнесом, который позволил быстрее получать обратную связь на релизы и понимание вклада в цель компании.
A comprehensive list of articles and links to deep dive in online experiments!
Recently, I got involved in the adventure of A/B testing. I decided to go beyond simple math and online calculators and dig deeper into this field. In this journey, I found many useful articles, papers, researches and so on. If you, like me, want to become professional in A/B testing, then check the following links in this post. You’ll find many exciting things.
Overview of the A/B testing field
These links are great to refresh your knowledge, remember the basic formulas, and to learn common mistakes and solutions for them.
In addition to authors that wrote previous papers and articles, I recommend you to check out these resources:
Ronny Kohavi is a Microsoft Technical Fellow and Vice President of Analysis & Experimentation. You must explore his project ExP Platform. Also look for his recommendations on what to read.
Eytan Bakshy’s blog. Eytan is a senior scientist on the Facebook Core Data Science Team, who lead the Adaptive Experimentation group.
Evan Miller is a developer of statistical software. He has a series of A/B testing articles on his website.
Papers from the SIGKDD conferences. It’s a community for data mining, data science, and analytics.
Слышали про “магические” 20%, на которые надо ориентироваться, чтобы улучшать продукт? Подробности читайте в этой статье.
Недавно узнал про “магические” 20%, на которые надо ориентироваться, чтобы улучшать продукт. Быстрый поиск через Google не дал конкретики, а запрос “JND 20%” только один раз встретился на SlideShare, где также не было ссылки на первоисточник.
Я заинтересовался вопросом и копнул интернет поглубже. Уж больно хотелось найти обоснование, которое затем можно использовать в работе.
Русская Википедия переводит это понятие как “порог различения”. В интернете хорошо ищется по сокращению JND и альтернативному названию — difference threshold.
И так, приступим…
Что это?
Термином just noticeable difference (JND) обозначают количество воздействия, которое нужно применить, чтобы человек смог заметить разницу между двумя сигналами как минимум в половине случаев.
> “The Difference Threshold (or “Just Noticeable Difference”) is the minimum amount by which stimulus intensity must be changed in order to produce a noticeable variation in sensory experience.”
— Frank Schieber, Professor and Human Factors Researcher at University of South Dakota
В паре с этим понятием идет absolute threshold — количество воздействия, которое необходимо применить, чтобы заметить сигнал на минимуме. Под сигналами подразумеваются пять основных чувств человека: осязание, зрение, вкус, обоняние и слух.
Например, абсолютный трешхолд для звука будет минимальное значение громкости на магнитоле, которое человек может обнаружить.
> “JND — минимальное изменение громкости, которое человек сможет ощутить между уровнями громкости.”
Кто придумал и как исследовали?
Изначальная теория
Эрнст Генрих Вебер — немецкий психофизиолог. В 1834 году он обнаружил, что воспринимается не абсолютный, а относительный прирост силы раздражителя.
Для каждого из чувств были найдены константные доли, на которые необходимо изменить значение сигнала, чтобы оно было заметным. Также затем нашли и много ограничений для этого закона.
размером вознаграждения в зависимости от квалификации работника
размером скидки для покупателей в магазинах
ценообразованием на новую и старую модель одного и того же автомобиля
Они пришли к такому выводу:
> “20% — это порог различения в вопросе ценообразования и качества”
Важно понимать, что эти результаты основаны на результатах наблюдения и интервью, поэтому они основаны на субъективных ощущениях наблюдателей и респондентов. Исследователи минимизировали погрешности и вывели среднее значение, но это не означает, что оно работает для всех и всегда.
Применимость в бизнесе: онлайн
С конца 90-х и в начале 00-х разродилась целая гора книг и исследований о применимости этих знаний в маркетинге, в т.ч. онлайн. Самая популярная книга, которая упоминается чуть ли не везде — Consumer Behaviour за авторством Leon G. Schiffman и Joseph Wisenblit. В ней рассказывают про маркетинговые трюки с вниманием и ценообразованием. Все это приправлено ссылками на исследования и солидным опытом авторов.
В 2014 году вышла статья, где JND рассматривается в разрезе применимости к социальным группам: Rethinking the Concept of Just Noticeable Difference in Online Marketing. Автор сделал симулятор, где сравнивал “разреженные” и “плотные” соц.группы. Можно провести аналогию — рабочий коллектив из 3–5 человек = “разреженная” группа. Фейсбук с 1000 друзей — “плотная”.
В “разреженных” группах изменение, которое не пересекло средний порог различения вероятнее всего останется незаметным. Знание не распространится внутри группы. В “плотных” группах, если кто-то один заметит, то все остальные рано или поздно об этом узнают, как бы это не скрывали хитрые маркетологи.
Если вы работаете с изменениями, которые пересекают средний JND (допустим вы сделали анонс чего-то нового), то меняется только скорость распространения информации. Но даже значительные изменения могут остаться незамечиными в маленькой соц.группе.
Как использовать при разработке продукта и бизнесе?
Позитивные изменения
Делаете рефакторинг и оптимизируете скорость загрузки приложения? Убедитесь, что ваши пользователи заметят прирост как минимум на 20% и смело пишите об этом в описании обновления.
Сокращаете количество действий для определенного юзкейса на сайте? 9 вместо 10 — плохо. 7–8 вместо 10 — хорошо.
Планируете дать скидку на товар? 20% простимулируют к покупке.
Негативные изменения
Повышаете цену? Делаете это по 5–10%, чтобы не пересечь JND.
