Полезное
Заголовок

Создавать опросы еще удобнее в новом конструкторе DIY PRO 2.0

Узнать подробнее
  • Fastuna
    →
  • Блог
    →
  • Метрики UX — как измерить пользовательский опыт

Метрики UX — как измерить пользовательский опыт

Как понять, что продукт действительно стал удобнее? Пользователи стали быстрее оформлять заказ? Или реже ошибаются при заполнении формы? Говорят, что им было проще? Или чаще готовы рекомендовать продукт другим?
В UX недостаточно полагаться только на ощущения команды или отдельные отзывы пользователей. Даже если интерфейс выглядит аккуратно, это не гарантирует, что люди легко достигают своих целей. 
Именно для этого нужны UX-метрики. Они помогают измерять пользовательский опыт не абстрактно, а через конкретные показатели: успешность выполнения задач, время, ошибки, удовлетворенность, усилия, лояльность и другие параметры.
UX-метрик много, и на практике они часто вызывают путаницу. Одни метрики похожи друг на друга: например, CSAT, CSI и NPS так или иначе говорят об отношении пользователя к продукту, а другие измеряют разные стороны одного и того же сценария: пользователь мог выполнить задачу, но потратить слишком много времени, совершить ошибки или оценить процесс как сложный.
Поэтому важно не просто знать названия метрик, а понимать, какой аспект опыта измеряет каждая из них, в каком контексте ее применять и какие решения можно принять на основе результата.
Мы решили структурировать основное поле UX-метрик, определить область применения, а также показать ограничения использования. В конце вас ждет небольшая табличка-шпаргалка по всем упомянутым метрикам.
Карта метрик
В UX-исследованиях метрики часто удобно делить на две большие группы:
  • Отношенческие метрики — это отношение, эмоции, восприятие. Показывают, что пользователь говорит (например, Понравилось ли? Было ли легко выполнить задачу? Стал бы пользователь рекомендовать?).
  • Поведенческие метрики — показывают реальные факты о том, что пользователь делает (например, Справился ли с задачей? Сколько времени потратил? Сколько ошибок сделал?).
Важное замечание: ни одна из групп не лучше другой. Они работают хорошо только в связке друг с другом, например, пользователь может успешно оформить заказ (выполнить задачу), но ему будет неприятен каждый клик. Или наоборот: он может все хвалить, но бросить задачу на полпути.
Любая метрика должна отвечать на вопрос «Что делать дальше?». Если метрика не помогает принять решение, ее использование бессмысленно.
В 2010 году исследователи Google разработали фреймворк HEART, чтобы очертить поле UX-метрик для измерения пользовательского опыта. HEART можно использовать как для отдельных функций продукта, так и для продукта в целом.
В основе фреймворка лежит разделение всех метрик на пять групп:
  • H — Happiness (Счастье) — отношенческие метрики, по которым замеряем удовлетворенность пользователей продуктом.
  • E — Engagement (Вовлеченность) — поведенческие метрики, по которым замеряем фактические данные вовлеченности пользователей в продукт.
  • A — Adoption (Принятие) — поведенческие метрики, по которым замеряем фактические данные о новых пользователях продукта.
  • R — Retention (Удержание) — поведенческие метрики, по которым замеряем фактические данные о сохранении существующих пользователей продукта за определенное количество времени.
  • T — Task Success (Успех) — поведенческие метрики, по которым замеряем фактические данные об успехе выполнения задач пользователей во время взаимодействия с продуктом.
Рассмотрим каждую группу метрик:
  • Метрики «Счастья». Например, NPS, CSAT, CSI, SUS, UMUX, SUPR-Q и другие.
  • Метрики «Вовлеченности». Например, количество посещений сайта в день, количество взаимодействия с продуктом, количество запросов и другие.
  • Метрики «Принятия». Например, количество новых пользователей за день/неделю, количество новых пользователей конкретной функции продукта по сравнению со старыми пользователями функции и другие.
  • Метрики «Удержания». Например, количество постоянных пользователей продукта за определенный промежуток времени, коэффициент оттока и другие.
  • Метрики «Успеха». Например, Успешность задачи (Task Success Rate), Время выполнения задачи (Time on Task), Частота ошибок (User Error Rate) и другие.
Чтобы использовать HEART, нужно пройти 3 шага:
  1. Определить цели того, что необходимо достичь относительно пользователей продукта.
  2. Определить сигналы, по которым будет понятно, что цели достигнуты.
  3. Выбрать подходящие метрики, которые можно регулярно и надежно измерять.
Предлагаем подробнее остановиться на некоторых метриках «Счастья» (отношенческие метрики) и на некоторых метриках «Успеха (поведенческие метрики) — именно они чаще других вызывают вопросы у исследователей.
А для замера метрик «Вовлеченности», «Принятия» и «Удержания» необходимы технические данные взаимодействия пользователей с продуктом — их можно получить с помощью сторонних аналитических инструментов или внутренних логов продукта.
Некоторые отношенческие метрики
Для начала мы рассмотрим общие метрики, по которым можно понять, что в продукте есть проблема. К ним относятся:
  • CSAT (оценка удовлетворенности пользователя после взаимодействия с продуктом);
  • NPS (оценка общей лояльности пользователя к продукту/компании и готовность рекомендовать);
  • CSI (комплексная оценка удовлетворенности пользователя после взаимодействия с продуктом. Учитывает не только общую удовлетворенность, но и важность различных атрибутов продукта для пользователей).
Далее перейдем к более точечным метрикам, которые замеряют конкретные действия пользователя с продуктом. К ним относятся:
  • CES (оценка прилагаемых усилий пользователя при взаимодействии с продуктом);
  • SEQ (оценка легкости выполнения конкретного задания).
И в конце дойдем до более «хардовых» метрик, для которых необходимы более сложные опросники. Они охватывают больший спектр обратной связи пользователей и требуют больше аналитических затрат. К таким метрикам относятся:
  • SUS (оценка сложности использования продукта, уровня удобства и обучаемости взаимодействия с продуктом);
  • UMUX (оценка юзабилити продукта, аналогичная SUS, но с меньшим количеством вопросов);
  • SUM (оценка удобства использования продукта, показатель объединяет объективные и субъективные метрики).
  • SUPR-Q (оценка качества взаимодействия пользователя с сайтами и приложениями: удобства использования, доверия, внешнего вида и лояльности).
CSAT (Customer Satisfaction Score)
Метрика показывает субъективную оценку уровня удовлетворенности пользователя после взаимодействия с продуктом, услугой или сервисом. Это одна из наиболее простых в использовании и широко применяемых метрик для измерения пользовательского опыта.
Как измеряется
Замерить CSAT можно с помощью вопроса «Насколько вы удовлетворены продуктом / функцией /услугой / взаимодействием?». Пользователь отвечает по 5 или 10-балльной шкале от «Очень недоволен» до «Очень доволен». Шкала может быть и в виде смайликов от грустного до счастливого.
Область применения
  • Любой этап продукта: после ключевых действий.
  • CSAT хорошо подходит для быстрого выявления проблем и оперативного реагирования на них.
  • Когда есть необходимость в мониторинге изменений удовлетворенности во времени.
  • Для сравнения качества взаимодействия разных каналов.
  • Для раннего выявления проблем с взаимодействием для предотвращения оттока пользователей.
Подход к интерпретации результатов
Хороший показатель CSAT обычно на уровне 80%, но нормы могут отличаться в зависимости от отрасли, например, они выше для простых понятных продуктов чем для более сложных сервисов. Больше всего пользы от CSAT можно получить, отслеживая показатель в динамике.
Что делать. Если CSAT падает после конкретного действия, нужно анализировать именно эту точку соприкосновения.
Ограничения. Метрика не показывает глобальную лояльность. CSAT может быть завышен из-за социальной желательности, формулировки вопроса, момента показа опроса или нежелания пользователя давать негативную оценку. Метрика не объясняет причины оценки — для этого можно добавить открытый вопрос, например, «Почему вы поставили такую оценку» или «Что мы могли бы улучшить?».
NPS (Net Promoter Score)
Метрика показывает уровень лояльности пользователей, измеряя готовность человека рекомендовать продукт или компанию. В отличие от CSAT, которая оценивает удовлетворенность конкретным взаимодействием, и CES, которая измеряет затраченные усилия, NPS направлена на оценку общего отношения к компании или продукту и долгосрочной лояльности.
Как измеряется
Замерить NPS можно с помощью вопроса «Как бы вы оценили вашу готовность рекомендовать этот продукт/компанию/услугу своим друзьям и знакомым?». Пользователь оценивает по шкале от «Точно не готовы рекомендовать» до «Точно буду рекомендовать», при этом шкала всегда 11-балльная, от 0 до 10.
После оценки пользователей делят на три группы:
  1. Промоутеры (9−10 баллов) — пользователи, которые заявляют высокую готовность рекомендовать продукт и, как правило, считаются более лояльной группой.
  2. Пассивные (7−8 баллов) — удовлетворенные клиенты, но не энтузиасты, могут уйти к конкурентам.
  3. Детракторы (0−6 баллов) — недовольные клиенты, могут распространять негативные отзывы и тормозить рост.
Область применения
  • Подходит для оценки целостного продукта.
  • Помогает выявлять промоутеров для программ лояльности.
  • Помогает обнаруживать риск оттока пользователей через мониторинг детракторов.
  • Если есть необходимость прогнозирования долгосрочного роста бизнеса.
  • Если нужна сегментация клиентской базы для персональной работы.
  • Для мониторинга динамики лояльности пользователей.
  • Для оценки эффективности внедрения стратегических решений.
Подход к интерпретации результатов
Интеграция NPS с другими метриками позволяет создать комплексную систему оценки и улучшения пользовательского опыта. Например, NPS + CSAT для детальной оценки конкретных взаимодействий, а NPS + CES для выявления и устранения сложностей в пользовательском пути.
На «норму» NPS влияют отрасль, стадия развития компании, географический регион, культурные особенности и другие факторы.
Что делать. Если NPS падает, то сегментировать пользователей и искать причины через открытые ответы, интервью и поведенческие данные.
Ограничения. NPS бесполезен для небольших интерфейсных фич, имеет ограниченную диагностическую ценность (не указывает на конкретные сильные стороны или проблемы) и сильно зависит от контекста опроса и культурных аспектов. Метрика не показывает причины без дополнительных открытых вопросов.
CSI (Customer Satisfaction Index)
Метрика показывает комплексную оценку уровня удовлетворенности пользователей после взаимодействия с продуктом. CSI учитывает не только общую удовлетворенность, но и важность различных атрибутов продукта для пользователей. 
CSI более широкая CX-метрика, которую можно применять и в UX-контексте, если среди атрибутов есть удобство, скорость, понятность, доверие и другие параметры взаимодействия с продуктом.
Как измеряется
Чтобы измерить CSI, необходимо определить ключевые атрибуты продукта, которые влияют на удовлетворенность (например: качество продукта, уровень сервиса, скорость работы, удобство использования, доверие к бренду и другие).
После определения атрибутов происходит сбор оценок по каждому по шкале (обычно 5, 7 или 10-балльная) от «Очень недоволен» до «Очень доволен» и от «Совсем не важно» до «Очень важно». 
Для расчета CSI есть несколько подходов, выбор каждого зависит от необходимой глубины анализа (детальность, веса важности атрибута, сегментация), шкалы оценки (5, 7 или 10 баллов), количества атрибутов (для 1−2 критериев достаточно простого среднего, а для 5+ критериев оправдан взвешенный расчет), ресурсов компании (время, бюджет, экспертиза) и бизнес-целей (оперативное реагирование или стратегическое планирование).
Область применения
  • Выявление важных аспектов продукта, которые имеют низкую удовлетворенность.
  • Выявление скрытых потребностей через анализ атрибутов высокой важности
  • Сегментация пользователей на основе приоритетных атрибутов с последующим созданием персонализированного подхода к сегментам.
  • Мониторинг динамики удовлетворенности во времени.
  • Оптимизация ресурсов с помощью переориентации на более важные атрибуты.
  • Выявление конкурентных преимуществ с помощью анализа важных атрибутов.
Подход к интерпретации результатов
Уровень CSI от 0 до 50 считается критически низким, а от 80 и выше уже высокий. Однако при интерпретации CSI важно учитывать отраслевые бенчмарки, так как для разных сфер есть своя норма.
Отдельно рекомендуется анализировать CSI в динамике и в контексте с другими метриками (NPS и CES).
Что делать. Если CSI показывает низкую удовлетворенность по важному атрибуту, то приоритизировать улучшение этого атрибута.
Ограничения. CSI требует двойной оценки по каждому атрибуту (важность + удовлетворенность), что увеличивает длину опроса и риск усталости респондентов. Интерпретация результатов непростая: приоритеты атрибутов могут меняться со временем и контекстом, а сам индекс не показывает скрытые потребности.
Чтобы не переоценить очевидное и не упустить неожиданное, лучше комбинировать CSI с качественными методами (интервью, наблюдение), а сам опросник и набор атрибутов периодически обновлять, особенно для инновационных продуктов, где ожидания пользователей еще не устоялись.
CES (Customer Effort Score)
Метрика показывает оценку усилий пользователя, измеряет, насколько сложно ему выполнить конкретное действие при взаимодействии с продуктом. В отличие от NPS и CSAT, которые фокусируются на общей удовлетворенности и лояльности, CES измеряет конкретно прилагаемые усилия.
Как измеряется
Измерить CES можно различными вопросами, выбор зависит от используемой версии метрики. Например, вопросами «Сколько усилий вам лично пришлось приложить, чтобы выполнить действие?», «Продукт сделал выполнение действия легким для меня» и Насколько легко было выполнить конкретное действие в продукте?".
При использовании CES важно следить за направлением шкалы: в одних формулировках высокий балл означает большие усилия, в других — легкость выполнения. Поэтому перед расчетом нужно зафиксировать, что считается хорошим результатом.
Область применения
  • Оценка более сложных операций (например, при восстановлении пароля или возврате товара).
  • Выявление конкретных этапов, требующих чрезмерные усилия.
  • Приоритизация улучшений продукта на основе данных о наиболее сложных этапах.
  • Сравнение эффективности различных решений с точки зрения минимизации усилий.
  • Оптимизация ресурсов поддержки пользователей за счет облегчения пути.
  • Уменьшение показателей оттока.
  • Поиск возможностей для создания конкурентного преимущества за счет предоставления более простого решения.
Подход к интерпретации результатов
Интерпретация результатов зависит от выбранной шкалы и способа расчета. Можно рассчитывать средний балл по всем ответам, процент выбравших верхние баллы шкалы (легко) или нижние баллы (сложно) или чистый показатель усилий: процент положительных оценок минус процент отрицательных.
Результаты можно анализировать в разрезах: по каналам, типам запросов, сегментам клиентов, сотрудникам или продуктам.
Что делать. Если CES высокий (пользователи тратят много усилий), то упрощать сценарий или снижать лишние усилия.
Ограничения. Метрика не показывает причины без дополнительных открытых вопросов. Также в оценке присутствует субъективность восприятия усилий: не для всех «сложно» — это одно и то же. Активное облегчение усилий может привести к чрезмерному упрощению в ущерб безопасности или функциональности продукта. 
Не все продукты должны быть легкими, например, в играх часто нужно усложнение механики, чтобы пользователям было интересно.
SEQ (Single Ease Question)
Метрика показывает воспринимаемую пользователем оценку легкости выполнения задания. Преимущество SEQ — в быстроте и простоте оценки того, насколько сложно или легко пользователю выполнить определенные действия при взаимодействии с продуктом. Метрика важна, так как дает «голос пользователя», например, иногда задача может быть решена, но в процессе решения пользователь чувствовал себя некомфортно.
Как измеряется
Замерить SEQ можно с помощью вопроса «Насколько вам было просто выполнить это действие?». Пользователь отвечает по шкале (7 баллов или менее чувствительная — 5 баллов) от «Очень сложно» до «Очень легко». Показатель SEQ рассчитывается как среднее (иногда медианное) значение. 
  • При 7-балльной шкале среднее значение выше 4 обычно рассматриваться как положительное, указывая, что большинству пользователей задача далась легко, а значение выше 5 сигнализирует высокий уровень удобства.
  • При 5-балльной шкале можно взять 3 как пороговое значение, выше которого будет указывать на хорошее удобство использования продукта.
Область применения
  • Полезна на любом этапе продукта.
  • Когда важна скорость замера взаимодействий пользователя с продуктом: в опроснике SEQ всего 1 шкальный вопрос, что позволяет оценить множество задач или сценариев в рамках одного исследования, не вызывая усталости у респондентов.
  • Если необходимо быстрое выявление проблемных задач для приоритезации улучшений.
  • Когда необходимо сравнить альтернативные решения на основе объективных данных.
  • Когда необходимо повысить конверсии с помощью упрощения задач, которые пользователи оценивают как сложные.
  • Если нужно оптимизировать ресурсы — благодаря точному выявлению проблемных областей можно снизить затраты на поддержку и сфокусировать ресурсы разработки.
  • Когда нужно отслеживать прогресс в улучшении пользовательского опыта со временем.
Подход к интерпретации результатов
Важно учитывать, что нормальный показатель SEQ может отличаться в зависимости от целей исследования и конкретных задач, которые выполнял пользователь.
Что делать. Если SEQ низкий, то провести интервью или анализ записи сессий, чтобы понять, где возникло ощущение сложности.
Ограничения. Метрика показывает субъективную оценку (зависит от опыта пользователей и контекста) и не объясняет причины. Для понимания причин можно добавить в опросник открытый вопрос «Почему вы поставили такую оценку?» или использовать другие качественные методы. SEQ не учитывает различные аспекты сложности, такую как когнитивную, эмоциональную и физическую.
SUS (System Usability Scale)
Метрика показывает воспринимаемую пользователем оценку сложности использования продукта, уровень удобства и обучаемости взаимодействия с продуктом. В отличие от SEQ, SUS не получится использовать после каждого действия пользователя, однако SUS охватывает более широкий спектр обратной связи.
Как измеряется
Замерить SUS можно с помощью опросника из 10 утверждений, пользователь оценивает каждое утверждение по 5-балльной шкале от «Совсем не согласен» до «Полностью согласен».
Стандартный список утверждений:
  • Этим продуктом я буду пользоваться часто.
  • Использование продукта кажется мне слишком сложным.
  • Я считаю, что продукт прост в использовании.
  • Я думаю, что для использования продукта мне потребуется помощь специалиста.
  • Я обнаружил, что различные функции в этом продукте хорошо интегрированы.
  • Я думаю, что в продукте слишком много несогласованностей.
  • Я полагаю, что большинство людей сможет быстро освоить этот продукт.
  • Я нахожу продукт очень неудобным в использовании.
  • Я чувствовал себя уверенно при работе с этим продуктом.
  • Мне пришлось многому научиться, прежде чем я смог начать пользоваться этим продуктом.
Область применения
  • Метрика полезна на любом этапе продукта.
  • Когда важны и скорость сбора данных, и качество полученной оценки общего уровня юзабилити.
  • Если есть необходимость сравниться относительно конкурентов и отраслевых стандартов.
  • Когда есть необходимость валидировать результаты внесения изменений в продукт.
  • Метрика особенно ценна тем, что предоставляет субъективную оценку удобства использования непосредственно от пользователей, дополняя объективные метрики производительности.
  • Дает возможность отслеживать прогресс в улучшении пользовательского опыта со временем.
Подход к интерпретации результатов
Результаты SUS измеряются в диапазоне от 0 до 100, существуют отраслевые стандарты. Часто значение около 68 считают ориентировочным средним уровнем SUS, но интерпретация зависит от категории продукта, аудитории и контекста использования.
Для получения максимальной выгоды от SUS можно посмотреть, какие утверждения получили низкие оценки (это покажет точки роста), и проанализировать различия между типами пользователей (например, между новичками и опытными).
Что делать. Если SUS низкий, то искать системные проблемы: консистентность, обучаемость, уверенность пользователя.
Ограничения. Балл SUS — это одна итоговая цифра, которая сама по себе не диагностирует конкретные проблемы юзабилити и требует дополнительных методов для понимания причин оценок. Метрика может не отражать специфические аспекты юзабилити определенных продуктов, так как утверждения стандартизированы.
UMUX (Usability Metric for User Experience)
Метрика для оценки юзабилити продукта, похожа на SUS, но с меньшим количеством вопросов, что делает ее удобнее для быстрого сбора данных. UMUX позволяет оценить эффективность и удовлетворенность пользователей.
Как измеряется
Замерить UMUX можно с помощью опросника из 4 утверждений, пользователь оценивает каждое утверждение по 7-балльной шкале от «Совсем не согласен» до «Полностью согласен».
Стандартный список утверждений:
  • Этот продукт полностью соответствует моим требованиям.
  • Мой опыт использования этого продукта оказался неудовлетворительным.
  • Этот продукт прост в использовании.
  • Мне нужно потратить слишком много времени, чтобы исправить проблемы с этим продуктом.
Область применения
  • Метрика полезна на любом этапе продукта.
  • Когда нужна быстрая количественная субъективная оценка юзабилити продукта.
  • Более простая метрика, но сопоставимая со стандартом SUS.
  • Отлично подходит для итеративной разработки продукта, где необходим регулярный сбор обратной связи, при этом без нагрузки на пользователей большими анкетами.
  • Когда необходима возможность отслеживать прогресс в улучшении пользовательского опыта со временем.
Подход к интерпретации результатов
Результаты UMUX измеряются в диапазоне от 0 до 100 в процентах. Для UMUX не существует универсального «нормального» значения, которое было бы приемлемо для всех продуктов и контекстов.
Результаты UMUX могут быть преобразованы в эквивалентные баллы SUS для сравнения с существующими бенчмарками.
Средний балл SUS составляет около 68, что соответствует примерно 65 баллам UMUX.
Результаты выше 70−80 обычно считаются хорошими и указывают на то, что большинство пользователей считают продукт удобным в использовании. Для более точной интерпретации лучше сравнивать показатель с вашей отраслью и отслеживать его в динамике.
Что делать. Если UMUX низкий, то поговорить с пользователями, чтобы выяснить, какие именно неудобства они испытывали при использовании продукта.
Ограничения. UMUX имеет меньшую детализацию по сравнению с другими опросными метриками, такими как SUS. Итоговая цифра UMUX не диагностирует конкретные проблемы юзабилити и требует дополнительных методов для понимания причин оценок. По сравнению с тем же SUS, UMUX имеет меньшую нормативную базу для сравнения.
SUM (Single Usability Metric)
Метрика оценки удобства использования продукта, которая объединяет в себе несколько отдельных показателей юзабилити для комплексной оценки пользовательского опыта. В SUM входят объективные и субъективные показатели, которые замеряются в процессе выполнения пользователя типичных задач. Метрика основана на стандартах ISO 9241−11, которые определяют юзабилити через три измерения: результативность, эффективность и удовлетворенность.
Как измеряется
Чтобы замерить SUM, необходимо определиться с объективными и субъективными метриками.
К первым относятся Task Success Rate (процент пользователей, успешно выполнивших задачу), Time on Task (время выполнения задачи) и Error count (количество ошибок).
К субъективным относятся отношенческие метрики, такие как ощущаемые затраты времени, ощущаемая сложность и удовлетворенность пользователя опытом взаимодействия с продуктом. Субъективные метрики обычно замеряются с помощью 5-балльной шкалы.
Область применения
  • Помогает для снижения субъективности в оценке продукта.
  • Если нужна количественная оценка эффективности и производительности продукта.
  • Когда необходимо упрощение выбора версий продукта и коммуникации внутри команд за счет единой числовой метрики.
  • Нужна для отслеживания изменений в юзабилити со временем.
  • Помогает установить внутренние бенчмарки.
Подход к интерпретации результатов
Финальный показатель SUM обычно представляется в виде числа от 0 до 100, где более высокие значения соответствуют лучшему пользовательскому опыту. Это делает метрику легко интерпретируемой и понятной даже для нетехнических заинтересованных сторон.
Обычно высоким показателем SUM считается уровень 80. Однако стоит брать во внимание отраслевые отклонения.
SUM рекомендуется использовать вместе с другими инструментами оценки продукта (NPS, CES, UMUX-Lite и другими), чтобы получить всестороннее понимание потребностей и ожиданий пользователей.
Что делать. Если SUM низкий, то поговорить с пользователями, чтобы выяснить, какие именно проблемы они испытывали при использовании продукта.
Ограничения. Важно учитывать, что SUM — это агрегированная метрика, в связи с чем она может скрывать конкретные недостатки отдельных аспектов юзабилити.
Для замера метрика требует проведения тестирования или сопоставления внутренних логов продукта (объективных метрик) с обратной связью пользователей (субъективных метрик). Это увеличивает и время, и затраты на получение данных, по сравнению с более простыми метриками, такими как UMUX. SUM может показывать хорошие результаты для простых задач, но не отражать проблемы, возникающие при длительном использовании.
SUPR-Q (Standardised Usability Percentile Rank Questionnaire)
Метрика для комплексной оценки качества взаимодействия пользователей с сайтами и приложениями. SUPR-Q представляет собой стандартизированный опросник, который включает 4 ключевых измерения: удобство использования, доверие, внешний вид и лояльность (которая включает замер NPS).
Как измеряется
Замерить SUPR-Q можно с помощью опросника из 8 вопросов. 7 из них — утверждения, которые замеряются по 5-балльной шкале от «Полностью не согласен» до «Полностью согласен» и последний вопрос в стандартной формулировке («Как бы вы оценили вашу готовность рекомендовать этот продукт/компанию/услугу своим друзьям и знакомым?») и шкале NPS.
Область применения
  • Для проведения комплексной оценки качества продукта по всем ключевым аспектам пользовательского опыта в рамках одного исследования.
  • Когда необходим бенчмаркинг с отраслевыми показателями и конкурентами (можно приобрести базу данных SUPR-Q).
  • Когда нужно определить конкретные проблемные аспектов пользовательского опыта.
  • Помогает сэкономить ресурсы за счет скорости сбора данных.
  • Для установления корреляций с бизнес-показателями, такими как конверсия и удержание пользователей.
  • Для оценки эффективности внедренных изменений.
Подход к интерпретации результатов
Как и с многими другими метриками (например, SUM, UMUX и SUS), «нормальный» показатель SUPR-Q может варьироваться в зависимости от отрасли.
Показатели SUPR-Q интерпретируются на основе перцентильных рангов, где каждый ранг указывает на то, как веб-сайт или приложение соотносится с другими сайтами в базе данных SUPR-Q. 50-й процентиль считается средним уровнем.
Дополнительно рекомендуется проводить регулярные замеры, чтобы отслеживать показатель в динамике, а также для полной картины использовать SUPR-Q в сочетании с другими метриками, например, CSAT или CES.
Что делать. Если SUPR-Q низкий, то просчитать показатель для каждого из 4 ключевых измерений, чтобы понять, какое из них проседает, и дальше «копать» в открытую обратную связь по проблемным измерениям.
Ограничения. SUPR-Q — это агрегированная метрика, в связи с чем она может скрывать конкретные недостатки отдельных аспектов взаимодействия пользователей с продуктом.
Метрика сфокусирована на анализе веб-продуктов, в связи с чем имеет ограниченную применимость для физических продуктов. Требует дополнительного анализа для понимания причин низких оценок. База данных SUPR-Q платная.
Некоторые поведенческие метрики
Ниже мы рассматриваем три базовых поведенческих метрики: Task Success Rate, Time on Task и User Error Rate. Данные метрики не включают в себя открытую обратную связь от респондентов и являются объективными.
Они хорошо показывают себя в связке друг с другом, помогают получить цельную картину взаимодействия с продуктом. Однако без обратной связи от пользователей (субъективные метрики, качественные методы сбора обратной связи) не покажут причины проблем.
Успешность задачи (Task Success Rate)
Одна из базовых метрик, которая показывает процент пользователей, которые успешно выполнили задачу. Если продукт не решает задачу — все остальное не имеет смысла. Ее возможно измерить только если точно сформулировать конечную цель, например, зарегистрироваться на сайте, оформить заказ или найти контакты организации.
Как измеряется
Метрика рассчитывается по формуле:
TSR = (Количество успешно выполненных заданий / Общее количество попыток выполнить задание) * 100
Область применения
  • Полезна на любом этапе продукта, особенно важна, когда нужно проверить, справляются ли пользователи с ключевым сценарием.
  • При редизайне интерфейса, чтобы сравнить старую и новую версии.
  • После запуска новой функции.
  • При поиске проблем в сценариях с низкой конверсией.
Подход к интерпретации результатов
Интерпретировать результат нужно с учетом сложности задачи, критичности сценария и уровня подготовки пользователей. Универсальной «нормы» для Task Success Rate нет: для простого сценария вроде поиска контактов даже 80% может быть тревожным результатом, а для сложного профессионального инструмента такой показатель может быть приемлемым на раннем этапе.
Анализировать Task Success Rate лучше по сегментам пользователей, например, новички и опытные. Также, замер Task Success Rate можно проводить вместе с Time on Task и User Error Rate и добавить качественные наблюдения, чтобы комплексно оценить ситуацию.
Важно не ограничиваться только итоговым процентом. Два сценария могут иметь одинаковую успешность, но разное качество прохождения: в одном пользователи выполняют задачу быстро и уверенно, а в другом, наоборот, долго, с ошибками и сомнениями.
Что делать. Если TSR низкий, то пересмотреть сценарий, навигацию, тексты, доступность ключевых действий.
Ограничения. Метрика сама по себе не объясняет почему пользователь не справился. Для этого нужны качественные методы вдобавок. Также метрика зависит от того, как сформулирована задача. Если задание слишком прямолинейное или подсказывает путь, показатель может быть искусственно завышен. Если задача сформулирована неоднозначно, результат может быть занижен. Успешное выполнение не всегда означает хороший опыт.
Время выполнения задачи (Time on Task)
Также базовая метрика, показывает, сколько секунд (или минут) требуется для выполнения типового сценария. Метрика показывает, есть ли лишние шаги, неоптимальная навигация или скрытые задержки.
Как измеряется
  • С помощью сторонних аналитических инструментов или внутренних логов продукта можно настроить отслеживание событий и таймеров, чтобы фиксировать, когда пользователь начинает и завершает задачу.
  • В юзабилити-исследованиях можно засечь время выполнения задания пользователями.
Область применения
  • На любом этапе продукта.
  • Для оценки эффективности прохождения сценария.
  • Для проверки ключевых пользовательских сценариев.
  • Для оптимизации процессов, где важна скорость (оформление заказа, поиск информации, заполнение формы и т. д.).
  • Для поиска лишних шагов в пользовательском пути.
Подход к интерпретации результатов
При анализе данных Time on Task рекомендуется использовать медиану, а не среднее значение, так как медиана более устойчива к выбросам (например, могут быть пользователи, которые тратят на задачу значительно больше времени из-за отвлекающих факторов). ф
Также полезно посмотреть распределение времени, а не только итоговое число, различия между новичками и опытными пользователями, время по успешным и неуспешным попыткам, динамику показателей до и после изменений в продукте.
Time on Task особенно полезна в связке с Task Success Rate. Например, если успешность высокая, но время выполнения слишком большое, это может говорить о том, что пользователи справляются, но путь к цели остается неэффективным. А добавление SEQ поможет понять, как пользователь оценил легкость выполнения задачи.
Время выполнения задачи обычно корректнее анализировать:
  • отдельно для успешно завершенных задач;
  • отдельно для неуспешных попыток;
  • с точным определением, когда задача считается завершенной и когда прерванной.
Иначе можно получить искажение, например, пользователь бросил задачу через 20 секунд — формально время маленькое, но это не значит, что сценарий удобный.
Что делать. Если Time on Task растет или оказывается выше ожидаемого, нужно искать лишние шаги, непонятную навигацию, слабые визуальные акценты, перегруженные формы, задержки загрузки или элементы, которые пользователи долго интерпретируют.
Ограничения. Time on Task нельзя интерпретировать изолированно. Быстрое выполнение не всегда означает хороший UX. Пользователь мог быстро бросить задачу, выбрать неправильный путь или формально завершить сценарий, не достигнув нужного результата.
Также не все задачи должны быть быстрыми — в некоторых продуктах длительное взаимодействие может быть нормой или даже частью ценности: обучение, аналитика, игры, творческие инструменты, сложные B2B-системы.
Частота ошибок (User Error Rate)
Метрика показывает, как часто пользователи совершают ошибки при выполнении заданий. Она помогает находить места, где пользователи путаются, неверно интерпретируют интерфейс, пропускают важные шаги или вводят данные неправильно.
Как измеряется
Метрика рассчитывается по формуле:
User Error Rate = (Количество совершенных ошибок всех пользователей / Общее количество возможностей совершить ошибку всех пользователей) x 100%.
Такой способ расчета подходит, если в сценарии заранее известны точки, где пользователь может совершить ошибку. Этот показатель позволяет оценить, насколько часто ошибки возникают относительно всех возможных точек риска.
Область применения
  • Помогает с оценкой качества прохождения сценария, а не только самого факта его завершения.
  • Для оценки сценариев с вводом данных, например, формы, анкеты или заявки.
  • Для проверки новых функций на понятность логики работы.
  • Если нужно протестировать сценарии, где ошибка пользователя может привести к серьезным последствиям: неверная оплата, потеря данных, неправильная настройка, отправка ошибочной заявки.
  • Для оценки качества онбординга, подсказок, валидации и текстов ошибок.
Подход к интерпретации результатов
Перед измерением важно заранее определить, какие действия считаются ошибкой. Например: неверный ввод данных, клик не туда, возврат на предыдущий шаг из-за непонимания и так далее.
Интерпретировать показатель нужно не только по общему значению, но и по типам ошибок. Например, один и тот же Error Rate может складываться из разных проблем:
  • пользователи не понимают названия полей;
  • пропускают обязательные шаги;
  • неправильно читают подсказки;
  • не замечают сообщения об ошибке;
  • кликают на элементы, которые выглядят интерактивными, но не являются такими.
Важно не путать User Error Rate с похожими показателями: долей пользователей, допустивших хотя бы одну ошибку, или средним количеством ошибок на одну попытку. Эти показатели тоже полезны, но отвечают на другие вопросы.
Что делать. Если Error Rate высокий, то пересмотреть форму, валидацию, подсказки, онбординг и т.д.
Ограничения. Необходимо четко определить, какие действия считаются ошибкой в контексте продукта или задачи. Метрика показывает, где и как часто пользователи ошибаются, но не отвечает, почему это происходит. Для понимания причин нужны качественные методы.
Не все ошибки одинаково важны. Один критичный сбой может быть важнее десяти мелких неточностей. Поэтому User Error Rate лучше анализировать вместе с критичностью ошибок, успешностью выполнения задачи и комментариями пользователей.
Как выбрать UX-метрику под задачу
Если нужно понять, выполняют ли пользователи задачу, используйте Task Success Rate.
Если важно узнать, сколько времени занимает сценарий, добавьте Time on Task.
Если нужно найти места, где пользователи ошибаются или сбиваются, используйте User Error Rate.
Если важно понять, насколько простой показалась задача, подойдет SEQ.
Если нужно измерить усилия в сложном сценарии, используйте CES.
Если нужно оценить общую воспринимаемую юзабилити продукта, подойдет SUS или более короткая UMUX.
Если нужна комплексная оценка юзабилити с объединением нескольких показателей, можно использовать SUM.
Если нужно измерить удовлетворенность после конкретного взаимодействия, используйте CSAT.
Если важно понять общую лояльность к продукту или бренду, подойдет NPS.
Если нужно оценить вклад разных атрибутов в удовлетворенность, используйте CSI.
Если нужна стандартизированная оценка качества сайта или приложения и бенчмаркинг, подойдет SUPR-Q.
Ни одна метрика не дает полной картины. Лучшая стратегия — комбинировать поведенческие показатели (успешность, время) с отношенческими (SUS, SEQ, CSAT). Например:
  • Task Success Rate + Time on Task + User Error Rate покажут, что пользователь делает и насколько успешно проходит сценарий;
  • SEQ или CES добавят субъективную оценку сложности и усилий;
  • SUS или UMUX помогут отслеживать воспринимаемую юзабилити продукта в целом;
  • CSAT, CSI или NPS покажут удовлетворенность и лояльность на более высоком уровне.
Оптимальный набор метрик зависит от зрелости продукта, целей исследования и решений, которые команда планирует принять по итогам измерения. И держать во внимании ограничения метрик.
Не стоит собирать метрики ради метрик. Всегда важно задать себе вопрос «Какое решение я приму, если показатель упадет?» и не забывать про методы качественных исследований, так как за цифрами всегда стоят живые люди, их мотивы и контекст.
Чтобы не выбирать метрику по названию, сначала сформулируйте исследовательский вопрос: что именно нужно понять — успешность выполнения задачи, скорость, количество ошибок, субъективную сложность, удовлетворенность или лояльность.
Ниже собрали краткую шпаргалку по основным UX-метрикам: что они измеряют, когда применяются и какие ограничения важно учитывать.
Шпаргалка по всем упомянутым метрикам
Скачать в PDF
Поделитесь своими задачами, мы подберем решение :).
Другие статьи:
Конструктор анкет под любые задачи — DIY PRO 2.0
Рассказываем про новый улучшенный инструмент с обновленными интерфейсом, структурой, логикой настроек и отчетом.
ИИ в открытых вопросах: как это работает
Объясняем, что дает новый подход с уточнениями и обработкой данных от искусственного интеллекта.
Подгруппы: зачем они нужны и как с ними работать
Объясняем, что такое подгруппы на платформе и как с ними правильно работать.