Метрики · 22 сентября 2026 г.

Шкала SUS: как посчитать и понять индекс удобства продукта

Шкала SUS (System Usability Scale) — стандартный опросник из десяти утверждений, который переводит субъективное ощущение удобства продукта в единый балл от 0 до 100. Участник после сессии работы с продуктом оценивает каждое утверждение по пятибалльной шкале согласия, а исследователь пересчитывает ответы по фиксированной формуле, где чётные пункты учитываются в обратную сторону. Итоговый балл сравнивают с опубликованным бенчмарком: среднее по индустрии составляет около 68 баллов, и это удобная точка отсчёта, а не абсолютный эталон качества. Дальше разберём формулу, интерпретацию, нужную выборку и ограничения метода.

Что измеряет SUS и откуда он взялся

SUS придумал Джон Брук в 1986 году как быстрый способ сравнить удобство разных систем без сложной методологии. С тех пор опросник стал одним из самых используемых стандартизированных инструментов юзабилити именно благодаря простоте: десять утверждений, пять минут на заполнение, одна формула на выходе. Его сила не в глубине — он не объясняет, почему продукт неудобен, — а в сопоставимости. Один и тот же опросник, заданный одинаково, позволяет сравнить версии продукта до и после редизайна, сравнить два конкурирующих решения на одной задаче или отследить динамику удобства во времени на одной и той же метрике.

Десять утверждений SUS чередуются по полярности: нечётные пункты сформулированы позитивно («я думаю, что хотел бы пользоваться этой системой часто»), чётные — негативно («я считаю систему излишне сложной»). Чередование сделано намеренно, чтобы участник не мог механически ставить одну и ту же оценку по всем пунктам подряд, не читая формулировки. Именно поэтому нельзя менять порядок утверждений или убирать часть из них — опросник валидировался как целостный набор, и любое упрощение ломает сопоставимость результата с опубликованными бенчмарками.

Формула подсчёта итогового балла

Каждое утверждение участник оценивает от 1 («полностью не согласен») до 5 («полностью согласен»). Для нечётных пунктов (1, 3, 5, 7, 9) из ответа вычитают единицу. Для чётных пунктов (2, 4, 6, 8, 10) ответ вычитают из пяти. Это и есть та самая обратная шкала: она нужна, чтобы после пересчёта высокий балл по каждому пункту всегда означал «хорошо», независимо от того, была формулировка позитивной или негативной изначально. После пересчёта все десять значений лежат в диапазоне от 0 до 4.

Сумму этих десяти пересчитанных значений умножают на 2,5 — так итоговый балл приводится к шкале от 0 до 100. Важная деталь, которую путают чаще всего: получившееся число — это не процент, хотя визуально похоже. SUS-балл 70 не означает «семьдесят процентов пользователей довольны» — это условная единица на собственной шкале опросника, которую можно сравнивать только с другими SUS-баллами или с опубликованными бенчмарками, а не интерпретировать напрямую как долю или проценты чего-либо.

Разберём подсчёт на условном примере — цифры ниже придуманы только для того, чтобы показать порядок расчёта, а не отражают реальный продукт. Участник ответил на пункт 1 («хотел бы пользоваться часто») оценкой 4 — из неё вычитаем единицу, получаем 3. На пункт 2 («система излишне сложна») он ответил 2 — вычитаем из пяти, получаем 3. Допустим, все десять пересчитанных значений в среднем дали 2,8 на пункт. Сумма по десяти пунктам — 28. Умножаем на 2,5 — получаем 70 баллов. Это выше медианного бенчмарка 68, значит по адъективной шкале продукт попадает в категорию около «good». Такой расчёт занимает пару минут в таблице и не требует специального софта.

Как читать результат: бенчмарк и адъективная шкала

Опубликованный бенчмарк около 68 баллов — это медиана по большой базе SUS-измерений разных продуктов, собранной исследователем Джеффом Сауро. Его удобно использовать как ориентир: балл выше 68 говорит, что продукт удобнее типичного среднего по широкой выборке систем, балл ниже — что есть системные проблемы. Но бенчмарк усреднён по очень разным категориям продуктов — от корпоративного софта до потребительских приложений, — и прямое сравнение своего конкретного продукта с этим числом стоит делать с поправкой на класс продукта, а не как строгий норматив.

Для более интуитивной интерпретации к числовому баллу добавляют адъективную шкалу (adjective rating scale): диапазоны переводят в словесные оценки от «awful» до «excellent», где 68 примерно соответствует границе «good» и «ok». Это полезно для презентации результата нетехнической аудитории: сказать «продукт получил оценку good по стандартной шкале SUS» понятнее, чем голое число 71,4. Но словесная шкала не заменяет само число — для сравнения версий продукта во времени нужен именно числовой балл, а не категория, потому что категории слишком грубые, чтобы заметить движение на пять-семь пунктов между итерациями.

Сколько участников нужно для устойчивого среднего

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

На малой выборке SUS всё же можно использовать, но не как строгую метрику для сравнения, а как быстрый ориентир вместе с качественными находками того же теста. Если пять участников юзабилити-теста дали SUS от 45 до 90 с большим разбросом, само по себе среднее почти ничего не говорит — важнее посмотреть, что объединяет тех, кто поставил низкую оценку, и было ли у них конкретное затруднение на сессии. Числа в таком случае служат подсказкой, куда смотреть в качественных заметках, а не самостоятельным выводом.

На практике полезно смотреть не только на среднее, но и на разброс индивидуальных баллов внутри одной выборки. Если из десяти участников восемь поставили оценку в диапазоне 70–85, а двое — около 20, среднее по группе получится вполне приличным, но этот разброс — самостоятельный сигнал: скорее всего у двух участников был свой специфический сценарий использования, где продукт ломается, и его стоит разобрать отдельно, а не растворять в общем среднем. SUS хорошо показывает такие выбросы именно потому, что считается на уровне отдельного участника, а не собирается сразу как одна усреднённая цифра.

Как правильно проводить замер

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

1. Дайте участнику выполнить реальные задачи в продукте перед заполнением опросника.
2. Предложите SUS сразу после сессии, не откладывая на следующий день.
3. Сохраняйте оригинальный порядок и формулировку всех десяти пунктов без изменений.
4. Используйте один и тот же перевод во всех волнах измерения одного продукта.
5. Считайте балл по стандартной формуле: обратная шкала для чётных пунктов, сумма умножается на 2,5.
6. Фиксируйте размер выборки вместе с баллом — число без контекста выборки вводит в заблуждение.

Культурная и языковая адаптация

Оригинальный SUS написан на английском для англоязычной аудитории, и прямой дословный перевод формулировок иногда искажает смысл. Например, слово «cumbersome» в пункте про громоздкость системы не имеет точного однословного русского эквивалента, и разные переводы («неудобной», «громоздкой», «сложной в использовании») слегка сдвигают, как участники понимают вопрос. Для внутреннего использования это не критично, но при сравнении своих результатов с зарубежными бенчмарками стоит помнить, что бенчмарк собран на оригинальных англоязычных формулировках, и прямое сопоставление баллов между разными переводами не такое строгое, каким кажется на первый взгляд.

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

Ограничения: что SUS не показывает

SUS даёт одно число и ничего не объясняет о причинах. Балл 55 говорит, что с продуктом что-то не так, но не говорит, что именно: путаная навигация, медленная загрузка, непонятные формулировки кнопок — узнать это можно только качественными методами вроде юзабилити-теста или интервью, где виден процесс, а не только итоговая оценка. Использовать SUS в одиночку, без сопровождающих качественных находок, — значит знать, что температура повышена, но не знать диагноза.

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

Полезно сопоставлять SUS-балл с прямым показателем успеха задач из того же юзабилити-теста — долей участников, которые довели сценарий до конца без посторонней помощи. Иногда эти два показателя расходятся неожиданным образом: все пять участников формально справились с задачей, но поставили низкий SUS, потому что путь до цели был неприятным, долгим или тревожным, хотя технически привёл к успеху. И наоборот — участник не смог закончить задачу, но поставил приемлемую оценку, потому что винит в неудаче себя, а не продукт. Такое расхождение само по себе находка: оно показывает, что «продукт работает» и «продукт приятно использовать» — разные вещи, и одной метрики недостаточно, чтобы различить их.

Типичные ошибки

• Менять формулировки пунктов или их порядок ради «более понятного» звучания.
• Забывать про обратную шкалу для чётных пунктов и считать все ответы напрямую.
• Интерпретировать балл как процент довольных пользователей.
• Сравнивать SUS-баллы на выборках по три-пять человек как окончательное доказательство.
• Задавать опросник через день-два после использования продукта вместо сразу после сессии.
• Использовать SUS как единственный источник данных без качественных находок о причинах.
• Менять перевод формулировок между волнами измерения одного и того же продукта.
• Сравнивать SUS-балл мобильного приложения напрямую с бенчмарком, собранным преимущественно на десктопных продуктах.

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

С чего начать

Если SUS в компании ещё не использовали, самый простой способ начать — добавить его как последний шаг в уже запланированный юзабилити-тест. Десять пунктов, пять минут, участники уже здесь и уже закончили работу с продуктом. Посчитайте балл по формуле для каждого участника и общее среднее, зафиксируйте размер выборки рядом с числом и сохраните результат как точку отсчёта. При следующей волне теста после доработок интерфейса повторите тот же опросник в том же переводе — и разница между двумя волнами станет первым количественным подтверждением того, что качественные находки действительно улучшили продукт, а не просто выглядят так изнутри команды. В «До Сути» такой опрос из десяти готовых формулировок SUS можно собрать по ссылке за несколько минут и переиспользовать анкету в каждой следующей волне без переверстки заново.