Юзабилити-тестирование · Сергей Сухаревский

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

Зачем нужно юзабилити-тестирование в Discovery

Что такое юзабилити-тестирование

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

В Discovery это быстрый способ:

найти реальные барьеры пользователя;
убедиться, что новая идея или прототип понятны и работают вживую;
обосновать, что надо дорабатывать до выхода разработки в полноценной реализации.

Пример: тестируют новый прототип страницы оформления заказа. Дают задачу: оформить заказ за 2 минуты. Пользователь путается с адресом и не может перейти к оплате. Это сигнал — еще рано передавать в разработку.

Когда проводить тесты в Discovery

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

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

Как правильно организовать юзабилити-тест в Discovery

Минимальный набор: сценарий, задачи, метрики

Для Discovery не нужен сложный протокол. Достаточно:

Сформулировать 1–3 сценария из жизни пользователя.
Подготовить короткие вводные: что делает пользователь, какая цель.
Продумать, как измерить успех: выполнил ли задачу, где запнулся, сколько времени потратил.

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

Рекрутинг и количество тестов

В Discovery не гонятся за большой выборкой. Часто хватает 5–7 респондентов, чтобы найти 80 % основных проблем. Главное — чтобы это были релевантные пользователи из твоей целевой аудитории.

Пример: B2B сервис тестировал новую навигацию. Взяли 6 менеджеров из разного бизнеса, дали сценарий «найти отчет». Все участники не нашли нужный раздел с первой попытки. Команда пересмотрела логику меню еще до выпуска.

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

Что искать в результатах

Самое важное — находить не однобокие впечатления, а устойчивые паттерны трудностей:

места, где все или почти все пользователи теряются, не понимают, путаются;
лишние клики и шаги, которые никто не может объяснить;
недопонятые формулировки, неузнаваемые кнопки, странные флоу.

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

Как документировать выводы

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

Ошибка — документировать только субъективные отзывы (типа “удобно/неудобно”). Важно связывать вывод с конкретным поведением.

Основные ошибки и антипаттерны

Что делать не стоит

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

Пример: маркетинговая команда просила пользователей пройти тест после подробного рассказа о возможностях продукта. 90 % участников показали хороший результат. Интуитивно интерфейс оказался сложнее, чем показалось на тесте: на проде выросло число жалоб по фиче.

Как использовать результаты для решения о дальнейших шагах

Юзабилити-тест помогает расставить приоритеты: что менять срочно, а что отложить. Если большинство запутались в одной секции, её исправляют в первую очередь. Если проблем много, выделяют 2–3 главные, протестированные снова после апдейта.

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

Источники и доп. материалы

FAQ

Что считать достаточным количеством респондентов для Discovery?

Чаще всего 5–7 реальных пользователей уже находят основные проблемы. Если после изменений новые ошибки не появляются, можно переходить к следующему этапу.

Как отличить баг интерфейса от проблемы юзабилити?

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

Нужно ли записывать видео юзабилити-теста?

Желательно. Видео помогает заметить детали поведения и аргументировать выводы для команды.

Как анализировать противоречивые отзывы?

Смотреть не на слова, а на реальные паттерны ошибок. Если большинство делает одно и то же неверно, это явный сигнал к исправлению.

Сколько сценариев стоит тестировать за раз?

Обычно 2–3 ключевых сценария достаточно, чтобы найти главные блокеры на первом этапе.

Нужно ли делать юзабилити-тесты на каждом спринте?

Нет, в Discovery достаточно 1–2 раундов на этапе проверки новой идеи или больших изменений.