UX-метрики: SUS, HEART, task success — что и как измерять

Почему UX нужно измерять, а не только обсуждать

Качественные исследования — интервью, юзабилити-тесты с наблюдением — отвечают на вопрос «почему». Они показывают, где человек споткнулся и что он при этом думал. Но они плохо отвечают на вопросы «насколько» и «стало ли лучше». Для этого нужны количественные метрики, которые можно сравнивать между версиями, сегментами и конкурентами.

Метрики UX полезно разделять на два типа. Поведенческие описывают, что люди делают: доля успешно выполненных задач, время, число ошибок, возвраты, конверсия шага. Отношенческие описывают, что люди думают и чувствуют: оценка удобства, удовлетворённость, готовность рекомендовать. Хорошая система измерений включает оба типа, потому что они часто расходятся.

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

SUS: десять вопросов, одна цифра

System Usability Scale — опросник, который британский инженер Джон Брук предложил в середине 1980-х. Он состоит из десяти утверждений, которые респондент оценивает по пятибалльной шкале от «полностью не согласен» до «полностью согласен». Нечётные утверждения сформулированы позитивно («Я думаю, что мне было бы легко пользоваться этой системой»), чётные — негативно («Я нашёл систему излишне сложной»).

Подсчёт стоит знать наизусть, потому что его часто делают неправильно. Для нечётных пунктов из ответа вычитается 1, для чётных ответ вычитается из 5. Получается вклад от 0 до 4 для каждого пункта. Сумма десяти вкладов умножается на 2,5, и итог оказывается на шкале от 0 до 100. Важно: это не процент. 70 баллов не означают «70 % удобства».

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

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

• Нечётные пункты: ответ − 1.
• Чётные пункты: 5 − ответ.
• Сумма × 2,5 = балл от 0 до 100.
• Средний ориентир — около 68, но важнее динамика.

HEART: от целей к метрикам

HEART — фреймворк, который исследователи Google описали в 2010 году для измерения пользовательского опыта в крупных веб-продуктах. Название — аббревиатура пяти категорий: Happiness (удовлетворённость), Engagement (вовлечённость), Adoption (принятие новых функций), Retention (удержание) и Task success (успешность выполнения задач).

Ключевая ценность HEART не столько в категориях, сколько в процессе Goals — Signals — Metrics. Сначала команда формулирует цель: например, «пользователи быстро находят нужный документ». Затем — сигналы, по которым видно, что цель достигнута или нет: открытие документа после поиска, повторный поиск, отказ от поиска. И только потом — конкретные метрики: доля поисков, завершившихся открытием документа; медианное время от запроса до открытия.

Не нужно заполнять все пять категорий для каждой функции. Для нового раздела важнее Adoption и Task success, для зрелого ядра продукта — Retention и Happiness. Пустая клетка в таблице HEART — нормальный результат, если команда осознанно решила, что эта категория сейчас не важна.

Распространённая ошибка — сразу брать готовые продуктовые метрики вроде DAU и называть их UX-метриками. Количество активных пользователей зависит от маркетинга, сезона и десятка других факторов; удобство интерфейса — лишь один из них. HEART помогает выбрать метрики, которые действительно связаны с опытом пользователя в конкретном сценарии.

Task success, время и ошибки

Самые прямые метрики юзабилити получаются из тестов на конкретных задачах. Task success — доля участников, которые выполнили задачу. Её можно считать бинарно (выполнил или нет) или по шкале: выполнил без помощи, выполнил с трудностями, не выполнил. Критерий успеха нужно определить до теста: что именно считается выполнением задачи.

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

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

После каждой задачи полезно задать один короткий вопрос об оценке сложности — например, Single Ease Question: «Насколько сложной или простой была эта задача?» по семибалльной шкале. Он даёт отношенческую оценку на уровне отдельной задачи, тогда как SUS оценивает систему целиком.

• Task success — доля выполнивших задачу по заранее заданному критерию.
• Время — медиана по успешным попыткам.
• Ошибки — где и как часто люди сбиваются.
• SEQ — оценка сложности сразу после задачи.

Сколько участников нужно и как не обмануть себя

Для качественного юзабилити-теста, цель которого — найти проблемы, часто хватает пяти участников на итерацию: этот ориентир хорошо известен благодаря работам Якоба Нильсена. Но он относится именно к поиску проблем. Для количественных выводов — «новая версия лучше старой» — пяти человек мало: интервалы неопределённости будут огромными.

При малой выборке всегда указывайте доверительный интервал, а не только точку. «Задачу выполнили 8 из 10» звучит убедительно, но реальная доля успеха в генеральной совокупности при такой выборке может лежать в широком диапазоне. Для доли при малых выборках обычно используют скорректированный интервал Вальда (метод Агрести — Коулла), он корректнее простого.

Сравнивайте сравнимое. Если старая версия тестировалась на опытных пользователях, а новая — на новичках, разница в метриках ничего не говорит об интерфейсе. Одинаковые задачи, одинаковый профиль участников, одинаковый протокол — без этого цифры превращаются в аргумент для спора, а не в знание.

Как собрать систему измерений в команде

Начните с малого. Выберите 3–5 ключевых сценариев продукта и для каждого — одну поведенческую и одну отношенческую метрику. Например, для оформления заказа: доля сессий, дошедших от корзины до оплаты, и оценка SEQ после тестовой покупки. Добавьте SUS раз в квартал или после крупных релизов.

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

И наконец, показывайте метрики рядом с качественными находками. Цифра «время на задачу выросло на 40 секунд» сама по себе вызывает только тревогу; та же цифра рядом с видеофрагментом, где пользователь ищет кнопку «Далее» под клавиатурой, сразу подсказывает решение.

Редакция Флагштока

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.