В 2010 году в журнале ACM Press экспертами из Google был представлен
фреймворк HEART для измерения пользовательского опыта (User Experience) на большом масштабе. Фреймворк и процесс предназначены для определения пользователь-ориентированных метрик на большом масштабе, включая как аттитюдные (Attitudinal), так и поведенческие (Behavioral) метрики. Подход сформирован на основе практики крупной компании с широким спектром продуктов — как потребительских, так и корпоративных, преимущественно веб-ориентированных и с аудиторией в миллионы пользователей. В рамках применения фреймворк показал свою применимость и полезность на различных продуктах, что указывает на возможность его повторного использования и адаптации в других организациях, например, для
измерения Developer Experience.
Наиболее часто используемые метрики сосредоточены на бизнес или технических аспектах продукта, и они широко применяются во многих организациях для отслеживания общего состояния продукта (Product Health). Эти метрики обозначаются как
PULSE:
- Просмотры страниц (Page views);
- Доступность (Uptime);
- Задержка (Latency);
- Активные пользователи за семь дней (Seven-day active users);
- Доход (Earnings).
С учетом ограничений PULSE-метрик как в измерении качества пользовательского опыта, так и в предоставлении данных, пригодных для принятия решений, был предложен дополнительный фреймворк —
HEART:
- Удовлетворенность (Happiness);
- Вовлеченность (Engagement);
- Принятие (Adoption);
- Удержание (Retention);
- Успешность выполнения задач (Task Success).
Эти категории служат основой, на базе которой команды могут определять конкретные метрики для отслеживания прогресса относительно целей:
- Категории Happiness и Task Success обобщают существующие метрики пользовательского опыта: Happiness включает удовлетворенность (Satisfaction), а Task Success — как результативность (Effectiveness), так и эффективность (Efficiency);
- Категории Engagement, Adoption и Retention являются новыми и стали возможны благодаря анализу поведенческих данных на большом масштабе.
Фреймворк сформирован на основе практики работы с командами по созданию и отслеживанию пользовательских метрик для их продуктов. В процессе применения были выявлены повторяющиеся паттерны в используемых и рекомендуемых метриках, что позволило обобщить их в виде фреймворка, делая принципы более понятными, запоминаемыми и пригодными для использования другими командами. Использование метрик из всех категорий не всегда является целесообразным, однако обращение к фреймворку позволяет явно принимать решение о включении или исключении конкретной категории. Например, вовлеченность (Engagement) может быть незначимой в корпоративном контексте, если пользователи обязаны использовать продукт в рамках своей работы. В таком случае фокус может быть смещен в сторону удовлетворенности (Happiness) или успешности выполнения задач (Task Success). При этом вовлеченность может оставаться релевантной на уровне отдельных функций, а не продукта в целом.
Удовлетворенность (Happiness)Термин Happiness используется для обозначения метрик, имеющих аттитюдный (Attitudinal) характер. Они относятся к субъективным аспектам пользовательского опыта, таким как:
- Удовлетворенность (Satisfaction);
- Визуальная привлекательность (Visual appeal);
- Готовность рекомендовать (Likelihood to recommend)
- Воспринимаемая простота использования (Perceived ease of use).
При наличии хорошо спроектированного опроса возможно отслеживать одни и те же метрики во времени, чтобы видеть прогресс по мере внесения изменений.
Пример из опыта Google: сайт включает персонализированную домашнюю страницу. Команда отслеживает ряд метрик с помощью еженедельного встроенного опроса чтобы понять влияние изменений и новых функций. После запуска крупного редизайна было зафиксировано первоначальное снижение метрики удовлетворенности пользователей (измеряемой по 7-балльной биполярной шкале). Однако со временем показатель восстановился, что указывает на вероятное влияние эффекта неприятия изменений (Change aversion), и на то, что по мере привыкания к новому дизайну пользователи начали оценивать его положительно. Эта информация позволила команде принять более уверенное решение о сохранении нового дизайна.
Вовлеченность (Engagement)Вовлеченность отражает уровень участия пользователя в работе с продуктом. В контексте метрик этот термин обычно используется для обозначения поведенческих прокси (Behavioral proxies), таких как: частота, интенсивность или глубина взаимодействия за определенный период времени. Примерами могут служить:
- количество посещений на пользователя в неделю;
- число загруженных фотографий на пользователя в день.
Как правило, метрики вовлеченности полезнее представлять в расчете на одного пользователя, а не в виде общего количества, поскольку рост общего значения может быть обусловлен увеличением числа пользователей, а не ростом использования.
Пример из опыта Google: команда Gmail стремилась глубже понять уровень вовлеченности пользователей, чем это позволяла PULSE метрика активных пользователей за семь дней, которая лишь отражает количество пользователей, посетивших продукт хотя бы один раз за последнюю неделю. Исходя из предположения, что вовлеченные пользователи должны регулярно проверять свою электронную почту как часть повседневной рутины, в качестве метрики был выбран процент активных пользователей, посетивших продукт пять и более дней за последнюю неделю. Также было выявлено, что этот показатель имеет сильную предсказательную связь с долгосрочным удержанием (Retention) и может использоваться как опережающий индикатор (Bellwether) для данной метрики.
Принятие (Adoption) и удержание (Retention)Метрики принятия и удержания позволяют получить более точное понимание количества уникальных пользователей за заданный период времени, решая проблему различения новых и существующих пользователей. Метрики принятия отражают, сколько новых пользователей начинают использовать продукт за определенный период (например, количество созданных аккаунтов за последние семь дней), а метрики удержания показывают, какая доля пользователей из заданного периода остается активной в более поздний период (например, процент пользователей, активных за семь дней в определенную неделю, которые остаются активными через три месяца).
Определение того, что считается использованием продукта, зависит от его характера и целей. В одних случаях достаточно самого факта посещения сайта. В других — пользователь может считаться принявшим продукт только после успешного выполнения ключевой задачи, например создания аккаунта. Аналогично вовлеченности, удержание может измеряться на разных временных интервалах — для одних продуктов релевантно недельное удержание, для других — месячное или 90 дневное. Метрики принятия и удержания особенно полезны для новых продуктов и функций или для продуктов в процессе редизайна; для более зрелых продуктов они, как правило, со временем стабилизируются, за исключением сезонных изменений или внешних событий.
Пример из опыта Google: во время обвала фондового рынка в сентябре 2008 года сервис Google Finance зафиксировал рост как просмотров страниц (Page views), так и активных пользователей за семь дней (Seven-day active users). Однако эти метрики не позволяли понять, был ли рост обусловлен новыми пользователями, заинтересованными в кризисе, или существующими пользователями, часто проверяющими свои инвестиции. Без понимания того, кто именно генерирует дополнительную активность, было сложно определить, требуется ли изменение продукта и в каком направлении. Анализ метрик принятия (Adoption) и удержания (Retention) позволил разделить эти группы пользователей и оценить, с какой скоростью новые пользователи продолжают использовать сервис. Это дало команде возможность лучше понять возможности, возникающие при всплесках трафика, вызванных внешними событиями.
Успешность выполнения задач (Task Success)Категория Task Success включает ряд традиционных поведенческих метрик пользовательского опыта, таких как:
- Эффективность (Efficiency, например время выполнения задачи);
- Результативность (Effectiveness, например процент завершенных задач);
- Уровень ошибок (Error rate).
Один из способов измерения этих показателей на большом масштабе — проведение удаленных исследований юзабилити или бенчмаркинга, в рамках которых пользователям назначаются конкретные задачи. При анализе логов веб-сервера может быть сложно определить, какую именно задачу пытался выполнить пользователь, в зависимости от характера сайта. Если для конкретной задачи существует оптимальный путь (например, многошаговый процесс регистрации), можно измерять, насколько пользователи ему следуют.
Пример из опыта Google: в Google Maps ранее использовались два типа поисковых полей: двойное поле для локального поиска, где пользователи отдельно вводили «что» и «где» (например, [pizza][nyc]), и единое поле поиска, обрабатывающее все типы запросов (включая локальные, такие как [pizza nyc] или последовательные запросы [nyc], затем [pizza]). Команда предполагала, что подход с одним полем является более простым и эффективным, поэтому в рамках A/B-теста была проверена версия только с одним полем. Сравнение уровня ошибок (Error rate) в двух вариантах показало, что пользователи в варианте с одним полем успешно адаптируют свои поисковые стратегии. Это дало команде основания отказаться от двойного поля для всех пользователей.
Цели-сигналы-метрики (Goals-Signals-Metrics)Независимо от степени ориентированности метрики на пользователя, она вряд ли будет полезна на практике, если явно не связана с целью и не позволяет отслеживать прогресс в ее достижении. Для этого авторы предложили простой процесс, в рамках которого команды последовательно формулируют цели продукта или функции, затем определяют сигналы, указывающие на успех, и, наконец, разрабатывают конкретные метрики для отслеживания на дашборде.
Цели (Goals)Первый шаг заключается в определении целей продукта или функции, в особенности с точки зрения пользовательского опыта:
- Какие задачи должны выполнять пользователи?
- Чего должен достичь редизайн?
Фреймворк HEART используется как инструмент для формулирования целей (например, что важнее — привлечение новых пользователей или повышение вовлеченности существующих). Авторы дают следующие рекомендации:
- Участники команды могут по-разному понимать цели проекта. Этот процесс дает возможность собрать различные точки зрения и прийти к согласованному пониманию (и поддержке выбранных метрик);
- Цели конкретного проекта или функции могут отличаться от целей продукта в целом;
- На этом этапе не следует чрезмерно фокусироваться на том, возможно ли определить соответствующие сигналы или метрики и каким образом это сделать.
Сигналы (Signals)Следующий шаг — определить, как успех или неудача в достижении целей могут проявляться в поведении или установках пользователей:
- Какие действия будут свидетельствовать о достижении цели?
- Какие ощущения или восприятие будут коррелировать с успехом или неудачей?
На этом этапе необходимо также определить источники данных для таких сигналов — например, для поведенческих сигналов на основе логов:
- фиксируются ли нужные действия в текущих логах или это можно реализовать?
- Как будут собираться аттитюдные (attitudinal) сигналы — возможно ли регулярно проводить опросы?
Логи и опросы являются наиболее часто используемыми источниками сигналов, однако возможны и другие подходы. Авторы дают следующие рекомендации:
- Выбирать сигналы, чувствительные и специфичные к цели — они должны изменяться только при улучшении или ухудшении пользовательского опыта, а не по посторонним причинам;
- В ряде случаев неудачи определить проще, чем успех (например, отказ от выполнения задачи, события отмены, фрустрация).
Метрики (Metrics)Заключительный шаг — определить, как выбранные сигналы могут быть преобразованы в конкретные метрики, пригодные для отслеживания во времени на дашборде. Авторы дают следующие рекомендации:
- Абсолютные значения (Raw counts) растут вместе с увеличением пользовательской базы и требуют нормализации; как правило, более полезны отношения, доли (%) или средние значения на пользователя;
- При использовании метрик, основанных на логах веб-приложений, возникает ряд проблем с обеспечением точности, включая необходимость фильтрации автоматического трафика (например, краулеров и спам-ботов), а также гарантию того, что все значимые пользовательские действия действительно логируются;
- Если требуется сопоставимость проекта или продукта с другими, может потребоваться отслеживание дополнительных метрик из стандартного набора, используемого в этих продуктах.
Фреймворк HEART и процесс Goals-Signals-Metrics применялись более чем к 20 различным продуктам и проектам из широкого спектра направлений внутри Google. Приведенные примеры показывают, как полученные метрики помогали продуктовым командам принимать решения, основанные на данных (Data-driven) и ориентированные на пользователя. Фреймворк и процесс также показали высокую полезность для структурирования и фокусировки обсуждений внутри команд. Они были обобщены на достаточное количество продуктов, что позволяет рассматривать их как пригодные для повторного использования и адаптации в других организациях. В дальнейшем был запущен
отдельный лендинг с описанием HEART framework, а процесс Goals-Signals-Metrics использовался для
измерения продуктивности инженеров.
В таблице ниже представлен перечень метрик HEART с соответствующими сигналами и целями: