HEART Framework (Google, метрики пользовательского опыта)

Команда переработала процесс оформления заказа в приложении и с гордостью показывает результат: конверсия в завершённый заказ выросла на 8%. Отдельное качественное исследование месяц спустя показывает, что пользователи не стали любить процесс больше — просто старые пути отказа были незаметно убраны, и людям стало труднее выйти из воронки, а не приятнее в ней остаться. Бизнес-метрики (конверсия, доход, число посещений) показывают, что сделали пользователи, но не показывают, было ли им приятно и эффективно это делать. Именно этот разрыв закрывает HEART — фреймворк пользовательских метрик, который разработали в Google исследовательницы Кэрри Родден, Хилари Хатчинсон и Синь Фу и описали в статье 2010 года «Measuring the User Experience on a Large Scale». В этой статье — что именно написано в оригинальной статье Google, чем HEART отличается от предыдущего набора метрик PULSE, как работает процесс Goals-Signals-Metrics, какие примеры продуктов Google приведены в первоисточнике, где фреймворк ограничен и как использовать фрейм OrgDevTools.

Что такое HEART и когда он нужен

По формулировке из аннотации оригинальной статьи, всё больше продуктов и сервисов развёрнуто в вебе, и это создаёт новые вызовы и возможности для измерения пользовательского опыта в большом масштабе. Существует острая потребность в пользовательских метриках для веб-приложений, которые можно использовать для измерения прогресса к ключевым целям и для принятия продуктовых решений. Авторы описывают фреймворк HEART для пользовательских метрик, а также процесс сопоставления продуктовых целей с метриками, и приводят практические примеры того, как HEART-метрики помогли продуктовым командам принимать решения, одновременно основанные на данных и ориентированные на пользователя.

HEART нужен, когда команда меняет продукт или функцию и хочет оценить не только «что стало происходить чаще», но и «стало ли пользователям лучше»: при редизайне, запуске новой функции, сравнении вариантов в A/B-тесте. Авторы прямо предупреждают: метрики не должны существовать сами по себе — их нужно триангулировать с находками из других источников, таких как исследования удобства использования и полевые исследования, что ведёт к лучшим решениям; метрики полезны в первую очередь для оценки уже запущенных продуктов и не заменяют раннее или формативное исследование пользователей. Иначе говоря, HEART дополняет, а не заменяет исследование пользовательского опыта (UX Research) и юзабилити-тестирование. Смежные методы измерения продукта и удовлетворённости: North Star Metric, пиратские метрики AARRR, NPS, анализ удовлетворённости клиентов, анализ оттока клиентов и модель Кано.

Происхождение и исследовательская база

Статья «Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications» опубликована в 2010 году исследовательницами Google Кэрри Родден, Хилари Хатчинсон и Синь Фу. Авторы обобщили опыт работы в крупной компании, чьи продукты покрывают широкий спектр категорий (и потребительские, и для бизнеса), почти все веб-ориентированы и у каждого миллионы пользователей. Они пишут, что фреймворк и процесс обобщены на достаточном количестве продуктов компании, чтобы авторы были уверены: команды в других организациях смогут повторно использовать или адаптировать их. К моменту публикации фреймворк и процесс были доведены за более чем год использования, применены к более чем 20 разным продуктам и проектам в самых разных областях Google.

Отправная точка для HEART — недостатки набора метрик, который авторы называют PULSE: Page views (просмотры страниц), Uptime (время безотказной работы), Latency (задержка), Seven-day active users (число уникальных пользователей за последние семь дней) и Earnings (доход). Это самые распространённые крупномасштабные метрики, фокусирующиеся на бизнес- и технических аспектах продукта, и авторы признают, что все они крайне важны и связаны с пользовательским опытом: продукт с частыми сбоями (низкий uptime) или очень медленный (высокая latency) вряд ли привлечёт пользователей, а сайт электронной коммерции с процессом покупки из слишком многих шагов заработает меньше денег. Но эти метрики либо очень низкоуровневые, либо косвенные показатели опыта, что делает их проблематичными при оценке влияния изменений интерфейса, и их интерпретация может быть неоднозначной.

Метрики не должны существовать сами по себе — их нужно проверять вместе с находками юзабилити-исследований и полевых исследований (К. Родден, Х. Хатчинсон, С. Фу, 2010; перевод формулировки из статьи).

Академическая теория: как устроен HEART

Проблема метрики «активных пользователей за семь дней»

Авторы разбирают на конкретном примере, почему число уникальных пользователей за период (например, seven-day active users) — плохой показатель качества опыта. Такая метрика измеряет общий объём пользовательской базы, но не даёт понимания уровня преданности пользователей продукту — например, насколько часто каждый из них заходил в течение этих семи дней. Она также не различает новых и вернувшихся пользователей. В худшем сценарии, при стопроцентной ротации пользовательской базы неделя к неделе, счётчик активных пользователей за семь дней теоретически мог бы всё равно расти. Именно эта проблема и породила три новых категории HEART — Engagement, Adoption, Retention.

Пять категорий: две обобщённые и три новые

Исходя из недостатков PULSE — и для измерения качества опыта, и для получения данных, на основе которых можно действовать, — авторы создали дополнительный фреймворк метрик HEART: Happiness, Engagement, Adoption, Retention и Task success. Это категории, из которых команды затем определяют конкретные метрики для отслеживания прогресса к целям. Happiness и Task Success — обобщение уже существовавших метрик пользовательского опыта: Happiness включает удовлетворённость, а Task Success включает и эффективность, и результативность. Engagement, Adoption и Retention — новые категории, ставшие возможными благодаря поведенческим данным большого масштаба.

Happiness описывает метрики, имеющие установочную (attitudinal) природу: субъективные аспекты опыта — удовлетворённость, визуальная привлекательность, готовность рекомендовать, воспринимаемая простота использования. С помощью общего, хорошо спроектированного опроса можно отслеживать одни и те же метрики во времени, чтобы видеть прогресс по мере внесения изменений. Task Success охватывает несколько традиционных поведенческих метрик — эффективность (например, время выполнения задачи), результативность (например, процент завершённых задач) и частоту ошибок; один из способов измерить их в большом масштабе — удалённое исследование удобства использования или бенчмаркинговое исследование с назначенными задачами; если для конкретной задачи существует оптимальный путь (например, многошаговый процесс регистрации), можно измерить, насколько точно пользователи ему следуют.

Кейс Gmail: как выбрать метрику вовлечённости

Команда Gmail хотела понять уровень вовлечённости пользователей глубже, чем позволяла метрика PULSE «активные пользователи за семь дней» (которая просто считает, сколько пользователей заходили в продукт хотя бы раз за последнюю неделю). Рассуждая, что вовлечённые пользователи должны проверять почту регулярно, как часть ежедневного распорядка, команда выбрала метрику: процент активных пользователей, заходивших в продукт пять или более дней за последнюю неделю. Авторы также обнаружили, что эта метрика сильно предсказывала удержание в более долгосрочной перспективе и поэтому могла служить раннем индикатором для метрики Retention.

Adoption и Retention: различить новых и вернувшихся

Метрики Adoption и Retention дают более глубокое понимание количества уникальных пользователей за период, решая проблему различения новых пользователей от существующих. Adoption отслеживает, сколько новых пользователей начинают использовать продукт за заданный период (например, число созданных учётных записей за последние семь дней), а Retention — сколько пользователей из заданного периода остаются активными в некий более поздний период (например, процент активных за семь дней пользователей данной недели, которые остаются активными за семь дней спустя три месяца). Что именно считается «использованием» продукта, зависит от его природы и целей: иногда достаточно простого визита на сайт, иногда посетителя засчитывают только после успешного выполнения ключевой задачи, например создания учётной записи. Как и Engagement, Retention можно измерять за разные периоды — для одних продуктов уместнее неделя к неделе, для других — месяц или 90 дней. Adoption и Retention особенно полезны для новых продуктов и функций или для продуктов, проходящих редизайн; для более устоявшихся продуктов они со временем стабилизируются, кроме сезонных изменений или внешних событий.

Не все пять категорий применимы всегда

Авторы прямо указывают: не всегда уместно применять метрики из каждой категории, но обращение к фреймворку помогает принять явное решение о включении или исключении конкретной категории. Например, Engagement может быть неосмысленным в корпоративном контексте, если от пользователей ожидается использование продукта как части их работы; в этом случае команда может сфокусироваться больше на Happiness или Task Success. Но Engagement всё же может иметь смысл на уровне отдельной функции, а не всего продукта в целом.

Процесс Goals — Signals — Metrics

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

Цели (Goals). Первый шаг — определить цели продукта или функции, особенно в терминах пользовательского опыта: какие задачи нужно решить пользователям, чего пытается достичь редизайн. Фреймворк HEART используют, чтобы подсказать формулировку целей (важнее ли привлечь новых пользователей или вовлечь уже существующих?). Полезные советы авторов: разные члены команды могут расходиться в понимании целей проекта, и этот процесс — хорошая возможность собрать разные идеи и прийти к консенсусу (и заручиться поддержкой выбранных метрик); цели успеха конкретного проекта или функции могут отличаться от целей продукта в целом; на этом этапе не стоит слишком беспокоиться о том, удастся ли найти подходящие сигналы или метрики — это забота следующих шагов.

Сигналы (Signals). Далее нужно подумать, как успех или неудача в достижении целей может проявиться в поведении или установках пользователей: какие действия указывали бы на достижение цели, какие чувства или восприятия коррелировали бы с успехом или неудачей. На этом этапе стоит продумать источники данных для сигналов: для поведенческих сигналов на основе логов — логируются ли сейчас нужные действия или можно ли начать их логировать; для установочных сигналов — как собирать их регулярно, например через опрос. Логи и опросы — два источника сигналов, которые авторы использовали чаще всего, но есть и другие возможности, например панель экспертов-оценщиков. Полезные советы: выбирайте сигналы, чувствительные и специфичные именно к цели — они должны изменяться только когда меняется качество опыта, а не по другим, не связанным причинам; иногда неудачу проще идентифицировать, чем успех (например, отказ от выполнения задачи, события «отменить», признаки фрустрации).

Метрики (Metrics). Наконец, нужно подумать, как перевести эти сигналы в конкретные метрики, подходящие для отслеживания во времени на дашборде. Полезные советы: сырые счётчики будут расти по мере роста пользовательской базы, и их нужно нормализовать — доли, проценты или средние на пользователя часто полезнее; обеспечение точности метрик на основе веб-логов сопряжено с трудностями, например нужно отфильтровывать трафик от автоматических источников (роботы, спам) и убедиться, что все важные действия пользователя логируются — это не происходит по умолчанию, особенно для приложений на AJAX или Flash; если важно сравнивать свой продукт или проект с другими, может потребоваться отслеживать дополнительные метрики из стандартного набора, который используют эти другие продукты.

Кейс iGoogle: как метрика счастья спасла редизайн от поспешной отмены

У сайта Google есть персонализированная домашняя страница iGoogle. Команда отслеживала ряд метрик через еженедельный опрос внутри продукта, чтобы понимать влияние изменений и новых функций. После запуска крупного редизайна команда увидела первоначальное снижение своей метрики удовлетворённости пользователей (измеряемой по семибалльной биполярной шкале). Однако эта метрика восстановилась со временем, что указывало на то, что причиной, вероятно, было неприятие изменений (change aversion), и что, привыкнув к новому дизайну, пользователи стали относиться к нему лучше. Обладая этой информацией, команда смогла принять более уверенное решение оставить новый дизайн — без такой метрики временное падение удовлетворённости после запуска легко можно было бы принять за провал редизайна и откатить хорошее изменение.

Ключевые идеи и принципы HEART

1. Принцип: пользовательская метрика должна быть привязана к цели

   Метрика сама по себе, даже пользовательская, вряд ли будет полезной на практике, если не связана явно с целью и не позволяет отслеживать прогресс к ней. Именно ради этого существует процесс Goals-Signals-Metrics: не выбирать метрику первой.

2. Принцип: attitudinal и behavioral данные дополняют друг друга

   Happiness (установочные данные, обычно из опросов) и Task Success/Engagement/Adoption/Retention (поведенческие данные из логов) отвечают на разные вопросы: что пользователи чувствуют и что они реально делают. Полная картина требует обоих типов данных.

3. Принцип: не все категории нужны всегда

   Фреймворк — не чек-лист «заполнить все пять», а инструмент для явного решения, какие категории релевантны текущей задаче: команда выбирает 2-3 наиболее значимые, а не отрабатывает формально все.

4. Принцип: сырые счётчики нужно нормализовать

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

5. Принцип: метрики триангулируют с качественными исследованиями

   HEART дополняет, а не заменяет юзабилити-тестирование и полевые исследования; он полезен для оценки уже запущенных изменений и не подходит как единственный инструмент раннего, формативного исследования.

6. Принцип: сигналы должны быть чувствительны именно к цели

   Хороший сигнал меняется, когда меняется качество опыта, а не по посторонним причинам; иногда неудачу (отказ от задачи, отмена действия, признаки фрустрации) проще заметить, чем успех.

Как внедрить HEART: пошаговая инструкция

Практическая последовательность на основе процесса Goals-Signals-Metrics из оригинальной статьи. Начните с продукта или функции, которую собираетесь оценивать, и соберите команду для формулировки целей: какие задачи должны решать пользователи, чего должен достичь редизайн или новая функция — привлечь новых пользователей или вовлечь уже существующих. Дайте разным членам команды высказать своё понимание целей и придите к консенсусу; помните, что цели конкретного проекта могут отличаться от целей продукта в целом, и не отвлекайтесь пока на вопрос, найдутся ли подходящие сигналы и метрики.

Обратитесь к пяти категориям HEART и явно решите, какие 2-3 из них релевантны именно этой задаче (Happiness, Engagement, Adoption, Retention, Task Success) — не заполняйте все категории по умолчанию. Для каждой выбранной категории и цели подумайте о сигналах: какие действия пользователя укажут на достижение цели, какие установки коррелируют с успехом или неудачей, и через что вы будете их собирать — через логи или через опрос. Проверьте, что сигналы специфичны именно к цели, а не будут меняться по не связанным причинам. Затем переведите сигналы в конкретные метрики для дашборда: нормализуйте сырые счётчики в доли и средние на пользователя, отфильтруйте автоматический трафик, убедитесь, что нужные действия действительно логируются. Запустите сбор данных, установите базовую линию до изменения и наблюдайте динамику после запуска, помня, что первоначальное отклонение (как в кейсе iGoogle) может отражать привыкание, а не реальный провал. Триангулируйте метрики с юзабилити- или полевыми исследованиями, прежде чем принимать окончательное решение.

Пример из практики: 20+ продуктов Google

По данным авторов, к моменту публикации статьи фреймворк и процесс Goals-Signals-Metrics были доработаны за более чем год использования и применены к более чем 20 разным продуктам и проектам из самых разных областей Google. Авторы отмечают, что и ядро фреймворка, и ядро процесса оставались стабильными на протяжении этого времени, а категории фреймворка оказались достаточно всеобъемлющими, чтобы вписывать в них новые идеи метрик. Урок для внедрения: фреймворк создавался не как разовая теоретическая конструкция, а как рабочий инструмент, испытанный на разнородных продуктах — и именно это, по словам авторов, даёт уверенность, что команды в других организациях смогут повторно использовать или адаптировать его успешно.

Ограничения, слепые зоны и критика HEART

Типовые ошибки при внедрении HEART

1. Ошибка 1: метрики выбирают раньше формулировки целей.

   Команда сразу решает «будем отслеживать retention» без формулировки, какую именно цель эта метрика должна отражать в контексте конкретной функции.

   Как избежать

   всегда проходить последовательность Goal → Signal → Metric, а не начинать сразу с выбора метрики.

2. Ошибка 2: бизнес-метрики интерпретируют как достаточное подтверждение хорошего опыта.

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

   Как избежать

   дополнять бизнес-метрики хотя бы одной категорией HEART, отражающей качество, а не только количество взаимодействий.

3. Ошибка 3: заполняют все пять категорий формально.

   Команда пытается отработать все категории «для полноты», получая размытые, нерелевантные метрики вместо 2-3 значимых.

   Как избежать

   явно решать, какие категории релевантны конкретной задаче, и осознанно исключать неприменимые.

4. Ошибка 4: сырые счётчики принимают за метрики опыта.

   Абсолютное число активных пользователей растёт вместе с базой, маскируя ухудшение вовлечённости на одного пользователя.

   Как избежать

   нормализовать метрики: использовать доли, проценты и средние на пользователя, а не сырые счётчики.

5. Ошибка 5: реагируют на первое отклонение метрики после запуска.

   Метрика удовлетворённости падает сразу после редизайна, и команда откатывает изменение, не дав пользователям привыкнуть.

   Как избежать

   наблюдать динамику метрики за период, достаточный для отличия неприятия изменений от реального ухудшения опыта.

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

   Решения принимают только по дашборду метрик, не проверяя находки юзабилити- или полевыми исследованиями.

   Как избежать

   триангулировать метрики HEART с качественными методами перед окончательным решением.

7. Ошибка 7: не проверяют, что нужные действия логируются.

   Метрика выбрана, но данные для сигнала не собираются или собираются с пропусками (особенно в AJAX-интерфейсах), и метрика молча искажена.

   Как избежать

   до запуска отслеживания проверить, логируются ли нужные действия, и отфильтровать автоматический трафик.

Метрики: как оценивать сам процесс внедрения HEART

Универсальных нормативов нет; фиксируйте по своим данным:

• Число категорий с полным путём Goal → Signal → Metric: из выбранных 2-3, а не из всех пяти.

• Happiness: удовлетворённость по регулярному опросу (например, семибалльная шкала, как в кейсе iGoogle).

• Engagement: доля активных пользователей, использующих продукт с нужной частотой (пример Gmail — 5+ дней из 7).

• Adoption: число новых пользователей/учётных записей за период.

• Retention: доля пользователей периода X, остающихся активными в периоде X+N.

• Task Success: время выполнения задачи, доля завершённых задач, частота ошибок.

• Полнота логирования: доля нужных действий, которые действительно попадают в логи.

Рост конверсии показывает, что сделали пользователи. HEART создан, чтобы показать, было ли им приятно и эффективно это делать.

План внедрения HEART по неделям

1. Неделя 1: категории и цели

   Выберите 2-3 наиболее релевантные категории HEART для оцениваемого продукта или функции и сформулируйте цели в каждой.

2. Неделя 2: сигналы

   Определите наблюдаемые сигналы, указывающие на достижение цели, и источники данных для них (логи или опросы).

3. Неделя 3: метрики

   Переведите сигналы в конкретные измеримые метрики, нормализованные в доли и средние на пользователя.

4. Неделя 4: сбор данных и первый отчёт

   Внедрите сбор данных, проверьте полноту логирования и подготовьте первый отчёт по выбранным метрикам.

   Далее: регулярно пересматривайте метрики HEART наряду с бизнес-метриками при оценке изменений продукта, триангулируя их с качественными исследованиями.

Как реализовать план с помощью фрейма «HEART Framework» в OrgDevTools

Фрейм показывает таблицу из пяти строк — по одной на каждую категорию HEART (Happiness, Engagement, Adoption, Retention, Task Success) с краткой подсказкой к каждой. У каждой строки — чекбокс «релевантна» (по умолчанию включён у всех пяти) и три текстовых поля: Goal, Signal, Metric — в точности процесс из оригинальной статьи. Строку можно исключить из подсчёта, снятием галочки «релевантна», без удаления самой категории.

• Неделя 1 — категории и цели: снимите галочку с нерелевантных категорий и заполните Goal для оставшихся 2-3.

• Неделя 2 — сигналы: заполните поле Signal для каждой релевантной категории.

• Неделя 3 — метрики: заполните поле Metric для каждой релевантной категории.

Вердикт строится по ступеням: если релевантных категорий не выбрано — предложение выбрать 2-3; если ни одна релевантная категория не прошла путь Goal → Signal → Metric полностью — предупреждение; если часть категорий доведена до метрики, а часть нет — сообщение «N из M доведены»; если все выбранные категории доведены до конкретных метрик — зелёное подтверждение. Кнопка создания задачи называется «Внедрить измерение метрики HEART».

Чего фрейм не делает. Он не собирает данные и не строит дашборд: поле «Metric» — это текстовое описание того, что нужно измерять, а не подключение к аналитике. Он не проверяет, специфичен ли сигнал именно к цели и логируются ли нужные действия, — это ручная проверка, описанная в статье, но не автоматизированная во фрейме. Он не нормализует метрики и не считает пороги «хорошо/плохо» для Happiness, Engagement, Adoption, Retention или Task Success — эти цифры зависят от конкретного продукта и в оригинальной статье не унифицированы. Порядок из пяти строк фиксирован и совпадает с порядком HEART; добавить шестую категорию или переименовать существующую нельзя. Вердикт «все доведены до метрик» означает только, что три поля заполнены текстом, а не то, что метрика реально отслеживается на практике.

Книги и материалы по теме HEART

К. Родден, Х. Хатчинсон, С. Фу — «Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications» (CHI 2010 Extended Abstracts). Первоисточник фреймворка HEART и процесса Goals-Signals-Metrics, доступен как PDF на сайте исследований Google.