Знакомая история: команда полгода пилила фичу, тестировщики нашли все баги, релиз вышел чистый, как слеза младенца. А пользователи… не оценили. Воронка ломается на третьем шаге, поддержка задыхается от тикетов «не могу найти эту вашу кнопку», CFO смотрит на расходы и тихо плачет.
Что произошло? Да, вполне привычная история. Продукт прошёл функциональное тестирование, но не прошёл главный тест – встречу с реальным человеком. Классический QA не лечит кривой UX. Он вообще не про это. Можно покрыть продукт автотестами на 100%, прогнать регрессию, получить зелёненький отчёт и всё равно слить релиз – потому что пользователь не понял, куда жать.
И вот тут на сцену выходит юзабилити‑тестирование. Не «ещё один вид тестирования», не «опционально, если останется бюджет», а инструмент управления риском провала продукта. Мы подготовили информационный концентрат: что, как и в каком порядке делать.
Главное недоразумение: юзабилити – это не про «удобство»
Если в вашей команде юзабилити‑тестирование воспринимают как «ну, чтобы пользователю было удобненько», то у вас проблема на уровне базовых установок. Юзабилити – не про красоту и не про комфорт. Это побочные эффекты. Истинная цель – прибыль.
В удобном интерфейсе пользователь легко и с удовольствием доходит до целевого действия. Растут конверсии, а за ними и выручка. Каждая лишняя кнопка, каждый невнятный лейбл – это деньги, утекающие мимо кассы. Когда вы это поймёте, юзабилити перестанет быть для вас «второстепенным видом тестирования где‑то после нагрузочного» и станет центром работы по выживанию и росту продукта.
И ещё. UX‑проектирование – это весь процесс создания интерфейса от ресёрча до макетов. Юзабилити‑тестирование – этап обратной связи внутри этого процесса. Без него UX превращается в ритуальные пляски с бубном по канонам Material Design: вроде красиво, а летит ли – непонятно.
Шесть вопросов, на которые отвечает юзабилити‑тест
- Полезный? Продукт вообще решает задачу пользователя – или мы его нарисовали, потому что нам показалось красиво?
- Эффективный? Сколько кликов и минут уходит на цель? Сколько из них лишние? Каждое лишнее действие – упущенная конверсия.
- Понятный? Нужна ли инструкция, чтобы пользоваться? Если да – у нас плохие новости.
- Без ошибок пользователя? Не функциональные баги, а – может ли человек сам ошибиться и насколько легко это исправить?
- Контролируемый? Понимает ли пользователь, что будет на следующем шаге? Может ли вернуться, остановиться, проверить?
- Приносит удовлетворённость? Хочется ли возвращаться?
Не можете уверенно ответить «да» на каждый из шести по своему продукту – садитесь, читаем дальше.
Подготовка: пять шагов, без которых юзабилити‑тест превратится в шапито
Ставим цели
Самый главный шаг и самый игнорируемый, к сожалению. Без чёткой цели тест превращается в «давайте посмотрим, что не так». Цель всегда привязана к стейкхолдеру: маркетинг хочет конверсии, поддержка – снижения тикетов «как это сделать?», продакт – отстройки от конкурента, юристы – соответствия WCAG. Сначала вопрос – потом инструмент.
Выбираем методики под задачи
В юзабилити‑тестировании больше десятка методик, и каждая – под свою задачу. Использовать одну для всего – это забивать гвозди микроскопом.
| Методика | Когда применять |
| Think-aloud | Прототипы, ранние этапы. Когда нужны ментальные модели, а не метрики. |
| Session Recording | Прод с массовой аудиторией. Где люди отваливаются, тепловые карты. |
| Time to Done | Сравнение версий интерфейса. Эффект редизайна в секундах. |
| Card Sorting | Проектирование меню, навигации, структуры каталога. |
| GOMS, KLM | Профессиональное ПО, где каждая секунда на счету (call-центры, трейдинг). |
| SUS, UMUX | Регулярные количественные замеры юзабилити (индекс 0–100). |
| Cognitive walkthrough | Этап проектирования, живых пользователей ещё нет. |
| Хронометраж сессий | B2B-системы, где «длинные» шаги (возвраты, согласования, выгрузки). |
| Эвристики Нильсена | Быстрая ревизия силами эксперта. Когда нет ресурсов на пользовательский тест. |
| Коридорные тесты | 5–10 минут с первым встречным. Проверить, не стало ли хуже после правок. |
| WCAG | Госуслуги, образование, международные рынки, аудиты. |
Определяемся с целевой аудиторией
Тестировать продукт на «случайных людях» – путь в никуда. Бабушка, зашедшая в приложение для зумеров,
не даст вам полезных данных про продукт.
Готовим сценарии
Самая частая ошибка – давать пользователю инструкцию вместо сценария.
❌Плохой сценарий: «Найдите раздел „Книги“, выберите жанр „Фантастика“, добавьте книгу в корзину».
✅Хороший сценарий: «Представьте, что хотите купить подарочную книгу для друга, которому нравится фантастика. Покажите, как бы вы это сделали».
Плохой тестирует, насколько хорошо человек умеет читать инструкции. Хороший – ваш интерфейс. Правило железное: в сценарии не должно быть слов, которые пользователь увидит в интерфейсе. Эту ошибку допускают все – от джунов до продактов с десятилетним стажем. Перечитайте каждый сценарий и отфильтруйте.
Собираем инструменты
Zoom/Google Meet – для модерируемых сессий. Hotjar/Метрика – для записи и тепловых карт. Maze, UXtweak, PlaybookUX, Useberry – специализированные платформы. Если первые четыре шага сделаны нормально – выбор инструмента уже мелочь. Если напортачили – ни Maze, ни Fullstory не спасут.
Хотите научиться быстро и эффективно выбирать подходы для юзабилити‑тестирования?
Мы собрали в одном файле 20 методик юзабилити‑тестирования. Это удобная шпаргалка для QA‑лида, продакт‑менеджера или UX‑исследователя. По каждой из методик: суть, когда и для чего применять, что для этого нужно, какого результата ожидать.
Проведение: от подготовки до сбора данных
Перед запуском обязательно проведите пилотный прогон.
Прогоните первый тест на близком к ЦА пользователе (не на дизайнерах или маркетологах, которые знают продукт). Ведите себя как с настоящим участником: никаких «ой, это просто тест», не делайте подсказок. Запишите пилот на аудио или видео. Пересмотрев, вы внезапно можете обнаружить, что половину времени перебивали или формулировали задачи невнятно. Сделайте работу над ошибками.
Приступайте к работе в реальных условиях
Перед каждой сессией говорите пользователю волшебную фразу: «Тест проходит интерфейс, а не вы». Это переключает участника из режима «как бы не опозориться» в режим «помогаю проекту». Попросите думать вслух, предупредите, что будете молчать.
Во время сессии:
- Запись (с разрешения) – всегда.
- Заметки по ходу – Google Doc, Excel, что угодно.
- Не подсказывайте. Совсем. Если совсем тупик – открытый вопрос: «Что вы ожидаете увидеть здесь?».
- Фиксируйте моменты, где человек спотыкается, бесится, возвращается. Эмоции – это данные.
- Укладывайтесь в 30–45 минут. Длиннее – пользователь устаёт и начинает врать.
В «Лаборатории Качества» мы видели десятки случаев, когда модератор не выдерживал, начинал «помогать» участнику – и весь тест летел в мусорку. Молчать тяжело, но необходимо. Не допускайте эту критическую ошибку.
Анализируйте с умом
Ловите паттерны, а не единичные случаи. Один человек – ещё не показатель, так как есть факторы в виде личностных особенностей, плохого настроения и т. д. А вот если 3+ пользователей запнулись на одном месте – это сигнал. По канонам Якоба Нильсена 5 пользователей выявляют около 85% юзабилити‑проблем – поэтому необязательно собирать огромные выборки. Главное – чтобы эти пять человек были из вашей реальной ЦА.
После всех сессий группируйте проблемы по категориям: навигация, тексты, визуал, функционал, мобилка. Простейшая таблица закрывает 80% задач: участник, сценарий, что получилось, где сложности, цитаты, время, severity (1–3). Цитаты пользователей в отчёте – отдельная магия: одна фраза «А где вводить промокод?» убеждает продакта сильнее, чем десять страниц сухих данных.
Чек‑лист «бери и делай»
Если хотя бы половина пунктов отсутствует в вашем процессе – у вас не юзабилити‑тестирование, а имитация бурной деятельности.
Перед тестом
- Цель сформулирована и привязана к стейкхолдеру.
- Методика выбрана под цель (см. таблицу выше).
- ЦА описана конкретно, с критериями отбора.
- Сценарии – как истории, без слов из интерфейса.
- Прототип работает, кликабелен, без багов.
- Проведён пилот с записью и пересмотром.
Во время сессии
- Сказали «тест проходит интерфейс, а не вы».
- Попросили думать вслух.
- Включили запись.
- Молчите, не подсказываете.
- Уложились в 30–45 минут.
После сессии
- Считаете паттерны (3+), не единичные случаи.
- Группируете по категориям, расставляете severity.
- Делаете отчёт с цитатами и фрагментами видео.
- Команда формирует план действий, вносит правки, при необходимости отдаёт продукт для повторного теста.
Когда мы в «Лаборатории Качества» заходим на проекты по запросу «у нас всё ок, просто помогите ускорить регрессию», часто оказывается, что регрессия – последняя из проблем. На первом месте – пользователь, который не может за три клика сделать то, ради чего вообще пришёл. И вопрос меняется с «как нам быстрее тестировать?» на «как нам перестать делать продукт, который никому не понятен?». Вот ради этого вопроса и существует юзабилити‑тестирование.
А у вас как? На каком этапе тестируете юзабилити – на прототипе, на бете или (а вы любите рисковать) после релиза? Какие методики реально зашли, а какие оказались неоправданными? Делитесь в комментариях.
Если у вас сейчас появилось много вопросов и мыслей – напишите нам, обсудим без галстуков. Реальный опыт – лучшая валюта в нашей отрасли, и мы готовы делиться.
