Как измерить качество UX в цифрах: SUS, HEART и PURE без занудства

«Дизайн хороший» — это не аргумент. «Дизайн хороший, потому что SUS = 78, task completion rate = 87%, и ни один пользователь из восьми не сделал critical error» — это уже разговор.

Три фреймворка — SUS, HEART и PURE — решают одну проблему: как перевести качество UX в числа, с которыми можно работать. Каждый из них подходит для разных ситуаций. В этой статье — как они устроены и когда что использовать.

## Зачем вообще измерять UX

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

Но без измерений нельзя:

Приоритизировать. Есть три проблемы. Какую чинить первой? Данные о severity и frequency помогают решить.

Доказать прогресс. «Стало лучше» — не аргумент для бизнеса. «SUS вырос с 54 до 71 после редизайна» — аргумент.

Сравнить варианты. Два дизайна, нужно выбрать один. Без измерения это субъективный выбор.

Зафиксировать базлайн. Прежде чем улучшать, нужно знать, что именно улучшается. Иначе непонятно, было ли улучшение.

## SUS (System Usability Scale)

### Что это

SUS — опросник из 10 вопросов, разработанный Джоном Бруком в 1986 году. Один из самых популярных инструментов измерения юзабилити в мире — и один из самых простых.

Каждый вопрос — утверждение, которое пользователь оценивает по шкале от 1 («Полностью не согласен») до 5 («Полностью согласен»).

### Вопросы SUS

1. Я думаю, что хотел бы использовать эту систему часто
2. Я нашёл систему излишне сложной
3. Я думал, что систему легко использовать
4. Думаю, что мне понадобится помощь технического специалиста для использования этой системы
5. Я нашёл, что различные функции в этой системе хорошо интегрированы
6. Я думал, что в этой системе слишком много непоследовательности
7. Я бы предположил, что большинство людей быстро научатся использовать эту систему
8. Я нашёл систему очень громоздкой для использования
9. Я чувствовал себя очень уверенно при использовании системы
10. Мне нужно было освоить многое, прежде чем я смог начать работать с этой системой

### Как считать

Нечётные вопросы (1, 3, 5, 7, 9) — позитивные: вычти 1 из оценки пользователя. Чётные вопросы (2, 4, 6, 8, 10) — негативные: вычти оценку из 5.

Сумму всех 10 результатов умножь на 2.5. Итог — число от 0 до 100.

Пример:

• Вопрос 1 (позитивный): пользователь поставил 4 → 4 − 1 = 3
• Вопрос 2 (негативный): пользователь поставил 2 → 5 − 2 = 3
• …и так для всех 10 вопросов
• Сумма = 28, результат = 28 × 2.5 = 70

### Интерпретация

Средний SUS по индустрии — около 68. Если ниже — юзабилити хуже среднего по рынку. Если выше 80 — отличный результат.

### Когда использовать

• Юзабилити-тест с 5–8 пользователями
• Сравнение двух версий продукта
• Бенчмарк перед редизайном
• Быстрая оценка прототипа

Минимальная выборка: 5–8 пользователей дают стабильный результат. До 5 — данные слишком нестабильны.

### Ограничения SUS

• Не говорит, что именно плохо — только что «что-то не так»
• Субъективен: разные пользователи интерпретируют «сложный» по-разному
• Не учитывает context of use — SUS для банковского приложения и для игры несравнимы напрямую
• Один и тот же SUS может означать разные проблемы

## HEART (Google)

### Что это

HEART — фреймворк, разработанный в Google для измерения UX на масштабе. Расшифровка: Happiness, Engagement, Adoption, Retention, Task Success.

В отличие от SUS, HEART не один опросник — это система для выбора правильных метрик под конкретный продукт. Используется в связке с матрицей «Goals — Signals — Metrics».

### Пять измерений HEART

Happiness (Счастье) Субъективное отношение пользователя к продукту. Насколько доволен, насколько доверяет, насколько готов рекомендовать.

Метрики: NPS, CSAT, App Store рейтинг, результаты опросов удовлетворённости.

Когда важно: когда удовлетворённость напрямую связана с retention (подписочные продукты, B2C) или когда продукт работает в конкурентной среде и разница именно в «ощущении».

Engagement (Вовлечённость) Насколько глубоко и регулярно пользователи используют продукт.

Метрики: DAU/MAU ratio, количество сессий в неделю, время в приложении, количество ключевых действий за период.

Когда важно: для social-продуктов, media-платформ, инструментов продуктивности. Если engagement падает — продукт теряет «место» в жизни пользователя.

Adoption (Принятие) Как быстро новые пользователи начинают использовать продукт или отдельную фичу.

Метрики: количество новых пользователей, adoption rate новой фичи, time to first key action, onboarding completion.

Когда важно: при запуске нового продукта или новой значимой фичи. Если adoption низкий — проблема в discovery, онбординге или в понимании ценности.

Retention (Удержание) Возвращаются ли пользователи.

Метрики: D1/D7/D30 retention, churn rate, renewal rate для подписок.

Когда важно: всегда, но особенно для продуктов с моделью на повторном использовании. Retention — основа всего.

Task Success (Успех задач) Насколько успешно пользователи выполняют конкретные задачи.

Метрики: task completion rate, time on task, error rate, success rate без помощи.

Когда важно: для utility-продуктов, инструментов с конкретными задачами. Если пользователь не может сделать то, зачем пришёл — нет смысла говорить об остальных измерениях.

### Матрица Goals — Signals — Metrics

HEART работает в связке с этой матрицей. Для каждого из пяти измерений нужно ответить на три вопроса:

Goals (Цели): Чего мы хотим достичь для пользователя в этом измерении?

Signals (Сигналы): Как изменится поведение пользователя, если мы достигнем цели?

Metrics (Метрики): Как мы можем измерить этот сигнал?

Пример для фичи «Поиск» в документальном сервисе:

### Когда использовать HEART

• При запуске новой фичи или продукта — для определения метрик успеха
• При ревизии того, что вообще измерять
• Для согласования с командой: разные роли часто смотрят только на своё измерение
• Для оценки большого продукта с несколькими флоу

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

## PURE (Pragmatic Usability Rating by Experts)

### Что это

PURE — экспертная оценка юзабилити, разработанная Petter Ivarsson. Позволяет быстро оценить интерфейс без пользовательских тестов.

PURE оценивает задачи по трём критериям:

1. Ease — насколько легко выполнить задачу
2. Navigation — насколько легко найти нужные функции
3. Wording — насколько понятны тексты, лейблы, инструкции

Каждый критерий оценивается по 3-балльной шкале: 1 (хорошо), 2 (с трудностями), 3 (очень сложно / невозможно).

### Как проводить PURE-оценку

Шаг 1. Составь список задач, которые нужно оценить. Это должны быть конкретные задачи реального пользователя («Создать новый проект», «Изменить пароль», «Найти историю транзакций»).

Шаг 2. Один эксперт (или несколько независимо) проходит каждую задачу и оценивает по трём критериям.

Шаг 3. Если экспертов несколько — усредни результаты.

Шаг 4. Задачи с оценкой 3 по любому критерию — критические проблемы. С оценкой 2 — средние. С 1 — всё хорошо.

### Пример PURE-оценки

Из такой таблицы сразу видно: «Изменить email» и «Экспортировать данные» требуют немедленного внимания.

### Когда использовать PURE

• Быстрый аудит продукта без бюджета на пользовательские тесты
• Приоритизация проблем в существующем интерфейсе
• Оценка прототипа перед тестом с пользователями
• Сравнение двух версий экспертами

PURE быстрее SUS — можно оценить весь продукт за 2–4 часа без рекрутинга пользователей. Но PURE субъективнее: эксперт не пользователь, и может не заметить то, что заметит реальный человек.

### Ограничения PURE

• Экспертная оценка ≠ пользовательское поведение. Эксперт может посчитать задачу простой, а пользователи — нет.
• PURE не даёт количественных данных о поведении пользователей
• Зависит от квалификации эксперта

## Как выбрать: SUS, HEART или PURE?

Не нужно выбирать один инструмент навсегда. Они дополняют друг друга:

• PURE → найти что сломано
• SUS → подтвердить с пользователями
• HEART → определить как измерять прогресс

## Практика: как внедрить измерение UX в работу команды

### Начни с базлайна

Прежде чем что-то улучшать — измерь текущее состояние. Провести SUS-опрос на пяти пользователях и получить базлайн — это 2–3 часа работы. После этого каждое изменение можно оценивать объективно.

### Включи метрики в definition of done

Задача «готова» не тогда, когда дизайн одобрен, а тогда, когда измерение показывает, что она решена. Это поднимает планку и делает прогресс видимым.

### Делай измерение регулярным

Разовый SUS ничего не даёт. Ежеквартальный SUS — это тренд. Именно тренд показывает, движешься ты в правильном направлении или нет.

### Рассказывай команде

Данные об UX должны быть видны всей команде, а не лежать в папке дизайнера. Регулярный «UX health check» — 5 минут на планёрке с ключевыми метриками — создаёт общую картину и вовлекает команду.

## Чеклист: какой инструмент и когда

• Начинаешь новый проект → HEART, чтобы определить метрики успеха
• Проводишь юзабилити-тест → добавляй SUS-опросник в конце
• Нет времени/бюджета на тест, нужна быстрая оценка → PURE с двумя экспертами
• Закончил редизайн → сравни SUS до и после
• Запускаешь новую фичу → используй HEART Adoption и Task Success
• Нужно обосновать бюджет на UX перед менеджментом → покажи SUS в сравнении с бенчмарком индустрии

## Как проводить SUS-тест правильно: детали, которые важны

Теория SUS понятна, но при проведении теста есть нюансы, которые влияют на качество результата.

### Рекрутинг участников

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

Минимум 5 участников для стабильного результата. Оптимально — 8–12. Более 12 — убывающая отдача.

### Порядок проведения

1. Дай пользователю задачи (не инструкцию по пользованию — задачи)
2. Наблюдай за выполнением без подсказок
3. После завершения задач — предъяви опросник SUS
4. Не объясняй как правильно использовать продукт до заполнения опросника

Ошибка: давать SUS-опросник после того, как объяснил пользователю как работает интерфейс. Оценка будет завышена — ты снял все проблемы объяснением.

### Нейтральность формулировок

Вопросы в SUS сформулированы намеренно. Не перефразируй их «более понятно» — изменение формулировки меняет психометрику опросника.

Если переводишь на русский — используй официальные или проверенные переводы, а не самостоятельный.

### Как сравнивать SUS-результаты

SUS надёжен как инструмент сравнения:

• До и после изменений
• Версия A vs. версия B
• Твой продукт vs. конкурент (если провести тест с одними и теми же участниками)

Как абсолютное значение SUS менее надёжен — сильно зависит от контекста (сложность задач, аудитория, устройство).

## HEART на практике: как провести сессию за 2 часа

HEART — концептуальный фреймворк. Но его можно превратить в рабочий инструмент за одну рабочую встречу.

### Формат воркшопа

Участники: дизайнер, продакт, аналитик. Опционально — разработчик.

Длительность: 2 часа.

Что нужно: большая доска (физическая или в Miro/FigJam), стикеры.

Структура:

Шаг 1 (20 мин) — Определение scope. Что именно оцениваем? Весь продукт? Конкретная фича? Конкретный флоу? Это важно зафиксировать в начале — иначе команда будет говорить о разных вещах.

Шаг 2 (30 мин) — Goals. Для каждого из 5 измерений HEART: какова наша цель для пользователя? Стикер для каждого измерения, одно предложение. Не КПИ — а то, что мы хотим чтобы пользователь чувствовал/делал.

Шаг 3 (30 мин) — Signals. Как изменится поведение пользователя если мы достигнем цели? Для каждой цели — 1–2 сигнала. Конкретные наблюдаемые действия.

Шаг 4 (30 мин) — Metrics. Как мы можем измерить каждый сигнал? Что уже есть в аналитике? Что нужно добавить?

Шаг 5 (10 мин) — Приоритизация. Какие измерения наиболее критичны прямо сейчас? Что будет фокусом следующего квартала?

Итог: заполненная матрица Goals-Signals-Metrics, согласованная командой.

## Как выбрать инструмент измерения под задачу: детальные критерии

Простая таблица «когда что использовать» не передаёт всех нюансов. Вот более детальное руководство.

### SUS выбирай когда

• Нужен количественный результат, а не список проблем
• Есть возможность провести юзабилити-тест (живой или удалённый модерируемый)
• Нужно сравнение: до/после, версия A vs. B
• Аудитория разнородна — SUS работает для широкого спектра пользователей

### PURE выбирай когда

• Нет времени или бюджета на тест с пользователями (нужен быстрый результат сегодня-завтра)
• Задача — приоритизировать проблемы, а не измерить общий уровень юзабилити
• Нужна экспертная оценка нескольких продуктов или экранов быстро
• Команда хочет выработать общее понимание проблем (двое-трое делают PURE независимо, потом сравнивают)

### HEART выбирай когда

• Начинаешь новый продукт или значимую фичу и нужно определить метрики успеха
• Нужно согласовать команду по тому что и как измерять
• Текущие метрики не связаны с целями пользователя
• Нужен взгляд на продукт целиком, а не на конкретный флоу

### Комбинации

• Запуск фичи: HEART → определить метрики → SUS после запуска → оценить результат
• Аудит продукта: PURE → найти проблемы → SUS → измерить с пользователями → HEART → определить метрики для мониторинга
• A/B-тест: SUS для каждого варианта → объективное сравнение

## Что делать с результатами: от данных к действиям

Инструменты дают данные. Но данные сами по себе ничего не меняют. Важен процесс преобразования данных в действия.

### После SUS

SUS дал балл 58 (удовлетворительно, ниже среднего). Что дальше?

1. Не останавливайся на балле. SUS не говорит что именно плохо. Смотри на отдельные вопросы — какие получили низкие оценки? Вопрос 2 («Система слишком сложная») высокая оценка → сложность. Вопрос 6 («Много непоследовательности») высокая оценка → inconsistency.

2. Совмести с наблюдениями. Что пользователи делали во время теста? Где застревали, где ошибались? SUS-балл плюс качественные наблюдения = полная картина.

3. Сформулируй гипотезы для каждой выявленной проблемы.

4. Приоритизируй по частоте и severity.

5. Задокументируй и запланируй проверку результата через 2–3 месяца.

### После PURE

PURE дал список задач с оценкой 3 (критично) и 2 (средне). Что дальше?

1. Критичные задачи (оценка 3) → немедленно в backlog с высоким приоритетом

2. Для каждой критичной задачи — разбор: в каком именно критерии (Ease, Navigation, Wording) проблема? Это определяет тип решения.

3. Средние (оценка 2) → следующий спринт или следующий квартал

4. Результаты PURE лучше подтвердить с 2–3 реальными пользователями — экспертная оценка не заменяет пользовательское тестирование

### После HEART

Матрица Goals-Signals-Metrics готова. Что дальше?

1. Проверь, что все метрики реально собираются. Если нет — поставь задачу аналитику на добавление трекинга.

2. Зафиксируй базлайн по каждой метрике.

3. Добавь ключевые метрики в дашборд.

4. Поставь цели на квартал по каждому измерению.

5. Ревизия через квартал: метрики двигаются в правильном направлении?

## ИИ и UX-метрики: как использовать Claude для измерения качества интерфейса

ИИ не заменяет пользователей в тестах — но помогает подготовиться к ним, обработать результаты быстро и сформулировать выводы.

### Промпт: подготовить SUS-тест

Перед тестом нужно выбрать задачи. ИИ помогает сформулировать их правильно:

Я планирую юзабилити-тест с SUS-опросником для [описание продукта].

Целевая аудитория: [кто пользователи]
Ключевые флоу, которые хочу проверить: [список]

Составь 5 задач для теста в формате "сценария пользователя" (не инструкции, а ситуации).

Требования к задачам:
— Задача не должна подсказывать как её выполнить
— Должна описывать реальную ситуацию, а не функцию продукта
— Должна иметь чёткое завершение (пользователь знает когда закончил)

### Промпт: интерпретировать результаты SUS

Вот результаты SUS-теста для [продукт]:

Пользователь 1: [10 оценок]
Пользователь 2: [10 оценок]
...

Рассчитай итоговый SUS-балл для каждого пользователя и средний по группе.
Интерпретируй результат: что означает этот балл, как соотносится с индустриальными бенчмарками.

Также проанализируй отдельные вопросы: какие получили наихудшие оценки? О чём это говорит с точки зрения UX-проблем?

Claude сам посчитает SUS-баллы по формуле и интерпретирует — не нужно держать таблицу в Excel.

### Промпт: провести PURE-оценку с помощью ИИ

Это неочевидный, но мощный сценарий. Claude может выступить как «второй эксперт» при PURE-оценке:

Я провожу PURE-оценку следующего флоу:

Задача: [описание задачи пользователя]
Текущий интерфейс: [описание экранов, шагов, элементов. Или загрузи скриншоты]

Оцени задачу по трём критериям PURE (1 = хорошо, 2 = с трудностями, 3 = очень сложно):
— Ease: насколько легко выполнить задачу?
— Navigation: насколько легко найти нужные функции?
— Wording: насколько понятны тексты и подписи?

Для каждой оценки не 1 — объясни конкретно что именно создаёт проблему.

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

### Промпт: построить HEART-матрицу

Продукт: [описание]
Конкретный контекст: [фича / флоу / весь продукт]

Помоги заполнить матрицу Goals–Signals–Metrics по фреймворку HEART.

Для каждого из 5 измерений (Happiness, Engagement, Adoption, Retention, Task Success):
— Предложи цель (Goal) — что мы хотим для пользователя
— Предложи сигнал (Signal) — как изменится поведение при достижении цели
— Предложи метрику (Metric) — как измерить сигнал

В конце — какие 2–3 измерения наиболее критичны для этого продукта прямо сейчас и почему.

### Промпт: обработать качественные данные из теста

После теста часто остаётся куча заметок — цитаты, наблюдения, «пользователь сказал что...». ИИ помогает систематизировать:

Вот мои заметки с юзабилити-теста (5 пользователей, тест [название продукта]):

[вставь заметки в любом формате — даже хаотичном]

Систематизируй данные:
1. Сгруппируй проблемы по частоте (сколько пользователей из 5 столкнулись)
2. Классифицируй по severity: critical (блокирует выполнение задачи) / major (сильно замедляет) / minor (раздражает но не блокирует)
3. Предложи приоритизированный список проблем для исправления
4. Отдельно выдели паттерны в том что пользователям понравилось