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

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

Почему пяти человек достаточно

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

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

Шаг 1. Определите, что проверяете

Тест без цели превращается в разговор о том, нравится ли людям цвет кнопок. До подготовки выпишите 3–5 ключевых сценариев, от которых зависит продукт. Для сервиса онлайн-записи это может быть:

• найти нужную услугу и мастера;
• выбрать свободное время;
• оставить контакты и подтвердить запись;
• перенести запись на другой день.

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

Шаг 2. Подготовьте прототип

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

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

Шаг 3. Найдите участников

Участники должны быть похожи на ваших реальных пользователей. Если продукт для владельцев автосалонов, тестировать его на коллегах-разработчиках бесполезно: у них другие привычки и другие ожидания.

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

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

Шаг 4. Напишите задания

Задание должно описывать цель, а не путь. Плохая формулировка: «Нажмите на кнопку "Записаться" и выберите мастера Анну». Хорошая: «Вы хотите записаться на стрижку в субботу после обеда. Попробуйте это сделать». В первом случае вы проверяете, умеет ли человек читать, во втором — понятен ли интерфейс.

Шаг 5. Проведите сессию

Структура одной сессии простая:

1. Вступление (5 минут). Объясните, что тестируется продукт, попросите рассуждать вслух и предупредите, что вы не будете подсказывать.
2. Пара вопросов о контексте (5 минут). Как человек решает эту задачу сейчас, какими сервисами пользуется.
3. Задания (20–25 минут). Читайте задание, дальше молчите и наблюдайте. Если участник застрял надолго, можно спросить: «Что вы ожидали здесь увидеть?»
4. Завершение (5 минут). Что было непонятно, что понравилось, чего не хватило.

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

Шаг 6. Запишите наблюдения правильно

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

После пяти сессий сведите наблюдения в таблицу:

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

Шаг 7. Исправьте и проверьте ещё раз

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

Пример сценария для теста

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

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

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

Как превратить находки в задачи для разработки

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

• Что происходит: «Участники не находят, где изменить даты брони. 4 из 5 искали в карточке машины, а не в разделе с бронями».
• Почему это важно: «Сценарий изменения брони не выполняется самостоятельно, клиенты будут звонить».
• Предложение: «Добавить кнопку изменения дат на экран подтверждения брони и в письмо с подтверждением».
• Как проверим: «Повторный тест на трёх участниках, задание №3».

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

Частые ошибки

• Тестировать на команде. Люди, которые знают продукт, не видят его проблем.
• Спрашивать «вам нравится?». Люди вежливы и скажут, что нравится. Смотрите, что они делают, а не что говорят.
• Объяснять интерфейс до задания. Тогда вы проверяете ваше объяснение, а не интерфейс.
• Откладывать тест до готового продукта. Чем позже найдена проблема, тем дороже её исправление.
• Не записывать. Через неделю детали забываются, остаются общие впечатления.

Где это встроить в проект

В наших проектах первый тест проходит на прототипе, ещё до начала разработки, — обычно на второй-третьей неделе. Второй короткий тест — на тестовом стенде перед запуском. Это один из этапов в плане запуска MVP, и он экономит больше времени, чем занимает.

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