Юзабилити-тестирование на пяти пользователях: когда работает и когда нет

Откуда взялась цифра пять

Правило основано на модели Якоба Нильсена и Томаса Ландауэра, опубликованной в 1993 году. Они описали долю найденных проблем формулой 1 − (1 − L)^n, где n — число участников, а L — вероятность того, что один участник столкнётся с конкретной проблемой. В проектах, которые они анализировали, среднее значение L оказалось около 31%.

Подставим числа: при L = 0,31 пять участников обнаруживают примерно 84–85% проблем. Каждый следующий участник добавляет всё меньше нового: кривая быстро выходит на плато. В 2000 году Нильсен популяризировал этот вывод в статье о том, почему достаточно тестировать с пятью пользователями, и с тех пор цифра живёт отдельно от формулы.

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

Где правило работает

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

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

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

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

Где правило ломается

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

Вторая — редкие проблемы. Формула чувствительна к L. Если проблема затрагивает 10% пользователей, вероятность встретить её хотя бы раз у пяти участников — около 41%. Для сценариев, где редкая ошибка стоит дорого, например при переводе денег или вводе медицинских данных, маленькая выборка даёт ложное спокойствие.

Третья — количественные вопросы. Пять человек не отвечают на вопросы «насколько быстрее», «какой процент справится» или «какая версия лучше». Даже если все пятеро успешно выполнили задачу, нижняя граница 95% доверительного интервала для доли успеха будет около 50%. Для количественных юзабилити-исследований Nielsen Norman Group рекомендует ориентироваться минимум на 20 участников, а для A/B-сравнений нужен расчёт мощности.

Четвёртая — сложные продукты. В больших системах с десятками сценариев пять сессий не успеют покрыть даже основные пути. Тут правило применимо к каждому сценарию отдельно, а не к продукту целиком.

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

Три раунда по пять лучше одного на пятнадцать

Если бюджет позволяет пятнадцать сессий, соблазнительно провести их подряд. Но последние десять участников в основном повторят то, что показали первые пять, а интерфейс за это время не изменится. Гораздо полезнее разбить исследование на три раунда с исправлениями между ними.

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

Такой подход требует быстрых правок, поэтому лучше работает на прототипах: изменить кликабельный макет между раундами проще, чем выпустить релиз. Если интерфейс уже в продакшене, делайте паузу между раундами под цикл разработки.

Как подготовить сессии, чтобы пятёрка сработала

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

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

Используйте метод размышления вслух и минимально вмешивайтесь. Модератор не объясняет интерфейс и не защищает решения, а уточняет: «Что вы ожидали увидеть?», «Что вас остановило?». Пилотная сессия с одним человеком до основного раунда помогает поймать ошибки в сценарии и прототипе.

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

Анализ: от наблюдений к решениям

Сведите наблюдения в общую таблицу: строки — проблемы, колонки — участники. Такую матрицу иногда называют «радужной таблицей», потому что каждого участника отмечают своим цветом. Она сразу показывает, какие проблемы повторяются, а какие встретились один раз.

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

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

Чем дополнить маленькую выборку

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

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

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

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

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