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

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

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

Чем юзабилити-тест отличается от опроса и интервью

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

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

Сколько участников нужно: правило Нильсена и его пределы

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

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

Модерируемый и немодерируемый форматы

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

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

Удалённый и очный тест: что выбрать

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

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

Как написать сценарий тестирования

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

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

1. Сформулируйте цель пользователя, а не путь решения: что он хочет получить, а не куда нажать.
2. Уберите из формулировки названия элементов интерфейса — они подсказывают решение.
3. Добавьте короткую легенду с реалистичным контекстом перед задачей.
4. Расположите задачи от простых к сложным, чтобы разогреть участника постепенно.
5. Ограничьте число задач четырьмя-шестью на сессию — усталость снижает качество наблюдений.
6. Пропишите для каждой задачи критерий успеха заранее, до начала сессий.

Как фиксировать находки во время сессии

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

Как анализировать находки после серии сессий

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

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

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

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

• Формулировать задачу как инструкцию с названием кнопки вместо цели пользователя.
• Помогать участнику в момент затруднения вместо того, чтобы зафиксировать сам факт затруднения.
• Считать процент успеха по пяти участникам статистически значимым показателем для всей аудитории.
• Смешивать наблюдение и интерпретацию в одной заметке без разделения.
• Тестировать один сегмент пользователей и переносить выводы на всю аудиторию продукта.
• Останавливаться после одной волны теста и не проверять интерфейс повторно после правок.
• Задавать участнику наводящие вопросы вроде «вам ведь было неудобно здесь?».
• Путать юзабилити-тест с опросом об удобстве и делать выводы о массовости проблемы по пяти сессиям.

Ограничения метода

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

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

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

С чего начать

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