Юзабилити-тест: сколько участников нужно и как его провести

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

Самое ценное здесь не то, что говорят участники, а то, что они делают. Люди не всегда замечают собственные затруднения, но вы замечаете.

Сколько участников нужно

Часто цитируют правило «пяти пользователей». Оно основано на работе Якоба Нильсена и Томаса Ландауэра: в среднем один участник обнаруживает около 31% проблем интерфейса. Пять человек вместе находят около 85%, а дальше повторы: вы снова и снова видите то, что уже нашли.

Из этого вытекают три вещи.

Лучше проводить несколько небольших раундов, чем один большой. Пять человек, правки, ещё пять. Так вы проверите, что исправления сработали, и заметите то, что раньше загораживали главные проблемы.

Для каждой отдельной аудитории нужны свои участники. Новичок и опытный пользователь, покупатель и администратор, телефон и компьютер ведут себя по-разному. Пять-восемь человек на каждый такой сегмент.

Если нужны числа, например «80% справляются с оплатой за минуту», то пятью не обойтись. Для количественных оценок берут обычно от 20 человек, иначе диапазон погрешности слишком широкий.

Как проходит тест

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

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

Как писать задачи

Хорошая задача описывает цель человека, а не движения мышью.

• Плохо: «Найдите кнопку „Оформить заказ“».
• Хорошо: «Вы хотите купить кроссовки до 5 000 ₽ и получить их к выходным. Сделайте это».

В первом случае вы подсказали, что кнопка существует и как называется. Во втором проверяете, найдёт ли человек путь сам. Не используйте в задаче слова из интерфейса и заранее решите, что считать успехом.

Как вести себя модератору

Главное правило: не помогать. Даже невинное «а может, попробуете вот здесь?» портит наблюдение, потому что дома рядом с вами никто не сидит.

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

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

Что считать

• Доля успешных прохождений — главная метрика: справился человек с задачей или нет.
• Время, если вы сравниваете две версии.
• Ошибки и возвраты назад: показывают, где путаются.
• SEQ — один вопрос после каждой задачи: «Насколько легко было это сделать?» по шкале от 1 до 7.
• SUS — десять вопросов в конце с результатом до 100. Средним считается значение около 68.

Как расставить приоритеты

Каждую проблему оцениваем по двум признакам: насколько она мешает и как часто повторяется.

Уровень	Что это значит
Критическая	Человек не смог выполнить задачу
Серьёзная	Справился, но с трудом или после ошибок
Небольшая	Раздражает, но задача выполнена

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

Что чаще всего идёт не так

Тестируют на коллегах. Подсказывают по ходу дела. Дают слишком много задач за раз. Смешивают разные аудитории в одну кучу. Спрашивают «нравится ли вам?» вместо того, чтобы смотреть на действия. И приносят отчёт на 40 замечаний без приоритетов, из которого непонятно, что чинить завтра.

Если нужно проверить сайт, приложение или прототип, посмотрите, как это устроено у нас, на странице юзабилити-тестирования. Если же вам важно понять не «удобно ли», а «зачем людям это нужно», читайте про кастдев-интервью.