Юзабилити-тестирование сайтов и приложений: методика

Юзабилити-тестирование сайтов и приложений: как найти, где спотыкаются пользователи

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

Юзабилити-тестирование — способ увидеть продукт глазами нового пользователя. Реальные люди выполняют типичные задачи, а исследователь наблюдает, где они сомневаются, ошибаются, возвращаются назад или сдаются. Метод относится к качественным: здесь важна не статистика, а понимание того, почему возникает проблема.

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

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

Тестировать можно на любом этапе жизни продукта, и на каждом этапе задачи немного отличаются.

Прототип

Кликабельный макет без реальной логики. Проверяется структура, навигация, понятность названий. Исправления стоят дёшево.

Перед запуском

Рабочая версия на тестовом стенде. Ловятся критичные ошибки сценариев: регистрация, оплата, отправка заявки.

Действующий продукт

Поиск причин низкой конверсии, высокой доли отказов, обращений в поддержку. Сравнение с конкурентами.

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

Цели и гипотезы

Тестирование «всего интерфейса» без фокуса даёт размытый результат. Перед стартом стоит определить, какие сценарии критичны для бизнеса и где есть подозрения на проблемы. Источники гипотез:

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

Если у вас уже есть массив отзывов, полезно предварительно их систематизировать — о подходах к этому рассказано в статье об анализе отзывов и пользовательского контента.

Как составить задания

Задание — ключевой элемент теста. От его формулировки зависит, увидите ли вы реальное поведение или подсказанное.

Сценарий вместо инструкции

Плохо: «Нажмите на “Каталог”, выберите раздел “Обувь” и добавьте товар в корзину». Пользователь просто выполняет инструкцию. Хорошо: «Вы хотите купить себе кроссовки для бега до определённой суммы. Найдите подходящую пару и подготовьте заказ». Здесь человек сам решает, куда идти, — и именно это интересно.

Без слов из интерфейса

Если в задании звучит название кнопки, пользователь ищет это слово, а не решает задачу. «Оформите возврат» подскажет раздел «Возврат». Нейтральнее: «Кроссовки оказались малы. Что вы будете делать?»

Реалистичность и мотивация

Задание должно быть правдоподобным для участника. Человеку без автомобиля сложно убедительно «выбирать страховку для своей машины». Поэтому задания адаптируются под профиль или участников отбирают под задания.

Понятный критерий успеха

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

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

Сколько нужно участников

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

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

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

Форматы проведения

Формат	Как проходит	Сильные стороны	Ограничения
Модерируемый очный	Участник и модератор в одной комнате, запись экрана и лица	Глубина, видны эмоции, можно уточнять	Дороже, ограничена география
Модерируемый удалённый	Видеозвонок с демонстрацией экрана участника	Широкая география, своё устройство	Зависимость от связи и техники
Немодерируемый удалённый	Участник сам выполняет задания на платформе, экран и голос записываются	Быстро, много участников	Нельзя уточнить, ниже глубина
Партизанский	Короткие тесты с людьми в кафе, коворкинге, торговом центре	Очень дёшево и быстро	Случайная аудитория, поверхностно

Для мобильных приложений особенно важно тестирование на собственных устройствах участников: привычные жесты, размер экрана и настройки системы сильно влияют на опыт.

Кого приглашать

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

Ведение сессии

Вступление. Объясните, что тестируется продукт, а не человек, и ошибок здесь не бывает. Попросите говорить вслух всё, что думает участник.
Фоновые вопросы. Как часто пользуется подобными сервисами, какими, с какого устройства. Это контекст для интерпретации.
Задания. Модератор зачитывает сценарий и молчит. Если участник просит помощи, модератор отвечает вопросом: «А как вы думаете?», «Что бы вы сделали, если бы меня не было?».
Уточнения после задания. Не во время, а после: «Я заметил, что вы задержались на этой странице. Что вы там искали?»
Итоговая беседа. Общее впечатление, что было сложнее всего, что бы участник изменил. Иногда — короткая стандартизированная анкета удобства.

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

Метрики и фиксация проблем

Хотя тест качественный, несколько простых показателей помогают структурировать результаты:

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

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

Приоритизация и отчёт

Список из пятидесяти проблем без приоритетов парализует команду. Поэтому каждая проблема получает оценку серьёзности:

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

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

Практические выводы

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

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

Нужна помощь с исследованием? Специалисты NRay проведут исследование под вашу задачу — от постановки целей до презентации результатов. Оставьте заявку или напишите на [email protected].

Юзабилити-тестирование сайтов и приложений: как найти, где спотыкаются пользователи