UX-метрики: SUS, успешность задач и как измерять UX
Продвинутое3 минРедакция Innovialabs
Коротко
Удобство интерфейса измеряют поведенческими метриками (успешность задач, время, ошибки) и метриками восприятия (SEQ после каждой задачи, SUS в конце теста). Сравнивать итерации можно только при одинаковых задачах, критериях успеха и сопоставимых участниках.
Короткий ответ
UX измеряют двумя группами метрик:
- поведенческие — что человек сделал: справился ли с задачей, сколько времени потратил, сколько ошибок допустил;
- метрики восприятия — как он это оценил: насколько лёгкой была задача (SEQ) и насколько удобна система в целом (SUS).
Вместе они дают картину, которую не даёт ни одна метрика по отдельности: пользователь может выполнить задачу, но с трудом, или быстро, но с ошибкой.
Пять основных метрик
| Метрика | Что показывает | Когда собирать |
|---|---|---|
| Task success rate | доля успешно выполненных попыток | на каждую задачу |
| Time on task | сколько времени уходит на задачу | на каждую задачу |
| Error rate | как часто совершаются ошибки | на каждую задачу |
| SEQ | субъективная лёгкость задачи | сразу после задачи |
| SUS | общее восприятие удобства системы | в конце сессии |
Успешность задач
Task success rate = успешные попытки / все попытки. До теста запишите критерий успеха: например, «заказ оформлен с правильным адресом доставки». Без этого модераторы будут засчитывать результат по-разному.
Можно учитывать частичный успех (справился с подсказкой), но тогда заранее договоритесь, как он считается, и не смешивайте разные правила между итерациями.
Время на задачу
Считайте время от начала задачи до достижения критерия успеха. Практические правила:
- учитывайте в основном успешные попытки — время неудачных искажает картину;
- распределение времени обычно скошено вправо, поэтому смотрите медиану, а не среднее;
- в модерируемых тестах с «думанием вслух» время растёт, так что сравнивайте только сессии одного формата.
Доля ошибок
Сначала определите, что считается ошибкой: неверный клик в навигации, неправильно заполненное поле, отправка формы с некорректными данными. Затем считайте либо число ошибок на задачу, либо долю участников, допустивших хотя бы одну ошибку. Важно не только сколько, но и какие: ошибки группируют по причинам и превращают в задачи для дизайна.
SEQ — один вопрос после задачи
Single Ease Question: «Насколько сложно или легко было выполнить эту задачу?» по шкале от 1 (очень сложно) до 7 (очень легко). Вопрос задают сразу после каждой задачи. SEQ быстро показывает, какие сценарии воспринимаются тяжелее, даже если формально они выполнены.
SUS — общий опросник
System Usability Scale — 10 утверждений с ответами от 1 до 5, нечётные сформулированы позитивно, чётные — негативно. Расчёт:
- для нечётных вопросов: ответ − 1;
- для чётных: 5 − ответ;
- сумму умножают на 2,5 и получают балл от 0 до 100.
function sus(answers) { // массив из 10 ответов от 1 до 5
const sum = answers.reduce((acc, a, i) =>
acc + (i % 2 === 0 ? a - 1 : 5 - a), 0);
return sum * 2.5;
}
Балл SUS — не процент. В опубликованных исследованиях часто приводится ориентир около 68 как средний результат, но надёжнее всего сравнивать продукт с собственными прошлыми замерами.
Как сравнивать итерации
- Те же задачи и критерии успеха для каждой версии.
- Сопоставимые участники по опыту и сегменту.
- Один формат теста: модерируемый или нет, одно устройство.
- Смотрите на разброс. На маленьких выборках разница в несколько пунктов может быть случайной — указывайте доверительные интервалы или хотя бы диапазон значений.
- Сочетайте цифры с наблюдениями. Метрика говорит, что стало хуже, а записи сессий — почему.
Типичные ошибки
- Менять формулировки задач между раундами.
- Считать среднее время вместе с неудачными попытками.
- Подавать SUS как «процент удовлетворённости».
- Делать выводы о значимости на нескольких участниках.