Юзабилити‑тестирование без иллюзий, или почему технических тестов недостаточно?

Знакомая история: команда полгода шлифовала функционал, тестировщики уничтожили все баги, а пользователи уходят. Аналитик разводит руками, поддержка задыхается от тикетов, маркетинг угрожает продакту, а продакт – дизайнеру. В это время CFO считает расходы и грустно вздыхает.

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

Юзабилити – это не про удобство и красоту

Стиль, комфорт и лояльность пользователей – это побочные эффекты. Истинная цель юзабилити – прибыль. Бизнес существует, чтобы зарабатывать деньги. Пользователи легко доходят до целевого действия, и это влияет на конверсию, конверсия – на выручку, и, соответственно, бизнес выживает. Любой шаг в этой цепочке, который вы упрощаете на 10%, в финале может дать кратный рост денег. И наоборот: каждая лишняя кнопка или невразумительный элемент ведут к потерям. Когда вы и ваша команда это поймёте, то всё встанет на свои места.

Чем юзабилити‑тестирование отличается от UX‑дизайна?

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

UX‑проектирование создаёт интерфейс. Это про гипотезы, исследования, паттерны, прототипы, принятие решений.

Юзабилити‑тестирование проверяет, насколько то, что создал UX‑проектировщик, работает. Это про реальные взаимодействия живых пользователей с готовым интерфейсом (или хотя бы прототипом).

UX‑дизайн – это весь процесс от ресёрча до финальных макетов. Юзабилити‑тестирование – это один из этапов внутри этого процесса. Вот как выглядит здоровый цикл:

1. UX‑дизайнер рисует прототип нового мобильного приложения.

2. Тестировщик проводит юзабилити‑тест с пользователями.

3. Выясняется, что 3 из 5 не могут найти кнопку «Сохранить». Здравствуй, проблема на ровном месте.

4. UX‑дизайнер вносит правки и проверяет снова.

5. Готовый прототип уходит в UI, появляется боевой интерфейс.

6. Снова юзабилити‑тест, правки и релиз.

Именно такой цикл максимально правильный. Без него вы релизите свои домыслы, а не продукт, который нужен пользователям.

Шесть групп вопросов, на которые отвечает юзабилити‑тест

1. Продукт решает проблему пользователя, несёт пользу? Или мы его нарисовали, потому что нам показалось красиво? Это самый болезненный вопрос – и его пропускают чаще всего, потому что страшно услышать ответ.

2. Сколько действий, кликов, минут уходит у пользователя на достижение цели? И сколько из них – лишние? Каждое лишнее действие – это упущенная конверсия.

3. Нужна ли инструкция, чтобы продуктом пользоваться, понятен ли он интуитивно? Хороший интерфейс в расшифровках не нуждается. Точка.

4. Может ли пользователь сам ошибиться в процессе использования? Случайно удалить что‑то важное. Кликнуть не туда. Если для отмены случайного действия нужно писать в поддержку – поздравляю, есть над чем работать.

5. Понимает ли пользователь, что произойдёт на следующем шаге? Может ли вернуться назад? Может ли остановиться, проверить и поправить? Чувство контроля рождает доверие к продукту.

6. Хочется ли пользователям возвращаться к продукту? Это про эмоциональный след. Удовлетворённость – самая «софт‑скилловая» часть, но именно она формирует LTV.

Готовимся к юзабилити‑тестированию без ошибок

Юзабилити‑тест без подготовки – это интервью без вопросов, опрос без репрезентативности, и в итоге – данные, на которые невозможно опереться. А состоит подготовительный этап из 5 обязательных шагов.

Шаг 1. Определите цели теста

Самый главный шаг. Без чёткой цели тест превращается в профанацию. Цели бывают разные. Маркетинг хочет повысить конверсию в регистрацию. Поддержка задыхается из‑за проблем с личным кабинетом, появился сильный конкурент, и продукт нужно отстраивать и т. д. Вариантов миллион. Главное – сформулировать цель до того, как вы выбрали методику. Сначала вопрос – потом инструмент.

Шаг 2. Выберите методику и инструмент

Тут начинается самое весёлое. В юзабилити‑тестировании около 20 методик, и каждая – под свою задачу. Вот короткий навигатор по методам: какой под какую задачу.

Think‑aloud – пользователь вслух комментирует свои мысли и действия. Идеально на ранних этапах, когда нужно понять ментальные модели.

Session Recording (запись сессий и тепловые карты) – Hotjar, Яндекс Метрика, всё это семейство. Включается на проде, фиксирует клики, скроллы, движения. Когда применять: когда уже есть массовая аудитория и нужно понять, где она отваливается. Лендинг с низкой конверсией? Включаем запись и смотрим, где пользователь стопорится.

Time to Done (время до выполнения задачи) – простая, но мощная штука. Засекаем, сколько времени уходит на ключевой сценарий. Идеально, когда нужно сравнить две версии или оценить эффект редизайна. Стало быстрее или медленнее – вот вам конкретная цифра.

Card Sorting (сортировка карточек) – тяжёлая артиллерия для информационной архитектуры. Даёте пользователю карточки и просите их сгруппировать. Открытая сортировка – без заданных категорий, закрытая – с готовыми. Применяется, когда нужно спроектировать меню, навигацию, структуру каталога. Особенно полезно, когда пользователи уже жалуются на структуру.

GOMS‑анализ – модель из четырёх компонентов (Goals, Operators, Methods, Selection rules). Аналитик пошагово раскладывает действия пользователя и считает время и усилия. Без живого пользователя, чисто на бумаге. Применяется в профессиональном ПО – там, где интерфейс используют каждый день и каждая секунда экономии – это деньги. Интерфейс оператора call‑центра, рабочее место трейдера, админ‑панель – типичные кейсы.

KLM (Keystroke‑Level Model) – упрощённая GOMS, считает время по базовым действиям: клик, движение мыши, нажатие клавиши. Когда применять: при мелких изменениях, когда полноценная фокус‑группа избыточна. Уменьшили количество кликов в форме с пяти до трёх – KLM покажет, насколько это критично сэкономило время.

SUS (System Usability Scale) – стандартизированный опросник из 10 вопросов. Универсальная метрика для оценки юзабилити, результат – индекс от 0 до 100. Очень удобно для регулярных замеров: сделали обновление, прогнали SUS, сравнили с предыдущим. Если SUS падает – что‑то идёт не так.

UMUX (Usability Metric for User Experience) – младший брат SUS, всего 4 вопроса. Когда нужна быстрая количественная метрика без перегрузки респондента – UMUX в помощь. Особенно хорош для продуктов с быстрым циклом релизов: 4 вопроса легко встроить в воронку.

Cognitive walkthrough (когнитивный разбор) – эксперт сам проходит сценарий от лица пользователя и задаёт себе вопросы: «Понятно ли, что делать? Понятна ли реакция системы? Понятно ли, что я на правильном пути?». Применяется на этапе проектирования, когда живых пользователей ещё нет. Идеален для онбординга – провели walkthrough, убрали базовые косяки, и только потом несём продукт к реальным людям.

Хронометраж сессий – в отличие от Time to Done, тут смотрим время на сессию целиком, на этапы. Применяется в B2B‑системах для повышения продуктивности: сколько менеджер тратит на типовую операцию? Особенно эффективно работает на «тяжёлых» процессах – оформление возврата, согласование документа, выгрузка отчёта.

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

Коридорные тесты – ультрабыстрые тесты с «первым встречным» прямо в офисе. 5–10 минут с коллегой из соседнего отдела или случайным человеком. Когда дизайнер хочет быстро проверить макет, когда стартап готовится к питчу, когда внесли критичные правки и хотят убедиться, что не стало хуже. Это не научный метод, но он невероятно быстрый – и часто отлавливает то, что просмотрела вся команда.

WCAG (Web Content Accessibility Guidelines) – стандарты доступности интерфейсов для людей с ограниченными возможностями. Контраст, навигация с клавиатуры, альтернативный текст и так далее. Уровни A, AA, AAA. Обязательно применяется в госуслугах, образовательных платформах, при выходе на международные рынки и в рамках сертификационных аудитов.

Запомните: методика всегда выбирается под цель, а не наоборот. Если кто‑то с серьёзным лицом говорит: «Давайте сделаем юзабилити‑тест!» – переспросите: «Какой именно? Зачем?». Если внятного ответа нет – методика не выбрана, тест провалится.

Шаг 3. Определите целевую аудиторию

Тестировать продукт на «случайных людях» – это путь в никуда. Если приложение для бронирования авиабилетов протестировать на любителях железной дороги, полезной информации вы не получите. Аудитория должна соответствовать продукту.

Где брать понимание ЦА? Из четырёх источников:

1. Анализ продукта. Кому он предназначен? Какие проблемы решает? Есть ли уже сегментация – новички, эксперты, администраторы? Если приложение для бронирования авиабилетов – ЦА – это люди, которые часто путешествуют, привыкли к онлайн‑сервисам и ценят скорость. Юзабилити для них – это «купить билет за две минуты», а не «красивая анимация на сплеш‑скрине».

2. Анализ текущих пользователей. Если продукт уже живой – ныряем в Google Analytics, Яндекс Метрику, проводим анкетирование. Демография, поведение, устройства, время сессий. Кто реально пользуется – а не кого вы себе представляли в момент написания брифа.

3. Интервью со стейкхолдерами. Маркетологи, продакт‑менеджеры, поддержка. У каждого своё видение аудитории. Поддержка знает в лицо тех, кто отваливается. Маркетинг – тех, кто конвертируется. Продакт пытается их склеить. Поговорите со всеми, иначе вы протестируете один сегмент, а отвалится другой.

4. Конкурентный анализ. На кого ориентируются конкуренты? Их ЦА – часто и ваша. Какие паттерны они используют? Какие сегменты обслуживают, а какие игнорируют? Это даст вам и данные о рынке, и понимание, где можно отстроиться.

После этой работы должно получиться чёткое описание участника теста в духе: «женщина 28–40 лет, доход выше среднего, путешествует от 3 раз в год, бронирует онлайн, использует мобильник как основное устройство».

Шаг 4. Подготовьте задачи и сценарии

Тут совершают самую частую и самую болезненную ошибку: дают пользователю инструкцию вместо сценария.

❌ Плохой сценарий: «Найдите раздел „Книги“, выберите жанр „Фантастика“, добавьте книгу в корзину».

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

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

Шаг 5. Подберите инструмент

Инструментов сейчас много – на любой вкус и кошелёк. Zoom и Google Meet – для модерируемых сессий. Яндекс Метрика и Hotjar – для записи сессий и тепловых карт. UXtweak, Maze, PlaybookUX, Useberry – специализированные платформы для удалённых юзабилити‑тестов. Fullstory – для глубокой аналитики поведения. SurveyMonkey и Google Forms – для опросов и SUS‑анкет. Выбор инструмента – это уже мелочь, если первые четыре шага сделаны нормально.

Проводим тестирование юзабилити правильно

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

Пилотный прогон

Перед тем как звать настоящих пользователей, потренируйтесь. Идеально – на ком‑то близком к ЦА, но точно не на дизайнере или разработчике, которые знают продукт. Знакомый, который никогда не видел ваше приложение, – золото.

Главное – ведите себя как с настоящим участником. Не говорите: «Ой, это просто тест, не парься», не подсказывайте, не упрощайте инструкции. Проведите всё «по‑настоящему»: вступление, инструкции, задачи, финальные вопросы. Запишите сессию. Даже если это ваш близкий друг. Затем пересмотрите запись. Наверняка вы внезапно обнаружите, что половину времени перебивали собеседника, давали наводки и нагнетали ситуацию невнятными формулировками.

После пилота прогоните себя по чек‑листу:

• Задачи понятны, не перегружены, чётко сформулированы?

• Элементы грузятся, нет ли багов в прототипе?

• Технически всё готово (запись, шеринг экрана, звук голоса)?

• Не даёте ли вы наводящих подсказок? Чётко ли озвучиваете инструкции?

• Анкету заполнять удобно? Не слишком ли длинная?

• Укладываетесь в 30–45 минут? Длиннее – пользователь обычно устаёт и начинает врать или терять концентрацию.

Если хоть один пункт «не очень» – переделывайте. Лучше потерять день на пилоте, чем неделю на сессиях с реальными пользователями, где половина данных будет неприменима.

Запуск и сбор данных

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

«Тест проходит интерфейс, а не вы».

Это снимает напряжение и переключает участника с режима «как бы правильно ответить» в режим лёгкости и честности. Попросите думать вслух. Предупредите, что вы будете молчать большую часть времени, чтобы не сбивать его с мысли.

Во время сессии:

• Аудио-, видео- и экранную запись ведите всегда. С разрешения, конечно.

• Пишите краткие заметки прямо по ходу – Google Doc, Excel, что угодно. Постфактум вы половину забудете.

• Не подсказывайте. Совсем.

• Отмечайте моменты, где человек спотыкается, путается, бесится, не может найти элемент, возвращается назад. Эмоции – это данные.

Ловите паттерны, а не единичные случаи

Самое опасное на этапе анализа – паника от первой же ошибки. «Боже, у нас в макете огромная проблема, надо переделать!» – кричит дизайнер после первой же сессии, на которой пользователь не нашёл кнопку.

Спокойно. Один человек – это не показатель. А вот если больше 3 пользователей запнулись на одном и том же месте – это сигнал. Вот это уже паттерн, и его надо чинить. Кстати, по канонам Якоба Нильсена 5 пользователей выявляют около 85% юзабилити‑проблем. Главное – чтобы эти пять человек были из вашей реальной ЦА.

После всех сессий сгруппируйте проблемы по категориям:

• Навигация.

• Тексты.

• Визуальное оформление.

• Функционал.

• Мобильная версия.

Теперь у вас не «сорок отдельных багов», а карта проблем, по которой можно бить точечно.

Как агрегировать данные?

Вот такая таблица закроет 80% задач:

Severity по 3‑балльной шкале – критическое, среднее, низкое. Этого хватит, чтобы расставить приоритеты для команды разработки. Хотите красивее – Miro, FigJam, Notion для визуальной карты инсайтов, отчёт в слайдах с цитатами и скринами. Цитаты пользователей в отчёте – отдельная магия: одна фраза от пользователя «А где вводить промокод?» убеждает продакта сильнее, чем десять страниц аналитического отчёта.

Итоговый чек-лист по юзабилити-тестированию

Если вы дочитали до этого места и в голове крутится: «Ладно‑ладно, а с чего начать?» Вот выжимка для немедленного применения.

Перед тестом

• Сформулирована конкретная цель теста.

• Выбрана методика, которая решает именно эту цель.

• Описана ЦА теста.

• Сценарии написаны как истории, без терминов из интерфейса.

• Прототип или продукт работает без багов.

• Проведён пилотный прогон с записью, проведена работа над ошибками.

• Заготовлен шаблон заметок и таблица для агрегации.

Во время сессии

• Сказали: «Тест проходит интерфейс, а не вы».

• Попросили думать вслух.

• Включили запись (с разрешения).

• Молчите. Не подсказываете.

• Фиксируете моменты затыков, эмоций, ошибок.

• Укладываетесь в 30–45 минут.

После сессии

• Считаете паттерны, а не единичные случаи.

• Группируете проблемы по категориям.

• Расставляете severity, приоритезируете.

• Пишете отчёт с цитатами и видеофрагментами.

• Обсуждаете с командой план действий, вносите изменения, тестируете повторно.

А теперь вернёмся к началу

Так что общего у классных, но мёртвых релизов? Скорее всего, юзабилити‑тестирования у них либо не было совсем, либо было: «Ну мы там показали макет коллегам и маме нашего лида, они сказали – норм». Это не тест.

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

Если вы интересуетесь темой тестирования, управления, разработки и улучшения качества IT‑продуктов – у нас есть телеграм‑канал с полезным контентом. Там мы публикуем разные гайды, чек‑листы, экспертные статьи. Заходите, если для вас это актуально. И пишите в комментариях, как у вас на проектах с проверкой юзабилити.