Тестирование юзабилити: практическое руководство по его проведению

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

Это руководство описывает планирование, проведение и анализ юзабилити-тестирования с использованием метода «рассуждения вслух» (think-aloud protocol), оценки SUS и показателя успешности выполнения задач, с использованием реальных артефактов фасилитации вместо абстрактной теории.

Юзабилити-тестирование вкратце

Исследование Якоба Нильсена, опубликованное Nielsen Norman Group, показало, что пять участников в одном раунде юзабилити-тестирования выявляют примерно 85% проблем с удобством использования. Более позднее рецензируемое исследование (Faulkner, 2003) показало, насколько сильно это варьируется: индивидуальные выборки из пяти пользователей находили от 55% до 99% проблем, в то время как любая выборка из десяти пользователей находила не менее 80%.

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

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

Юзабилити-тестирование — это метод исследования, при котором фасилитатор наблюдает за тем, как реальный пользователь выполняет репрезентативные задачи в продукте, а затем фиксирует показатель успешности выполнения задач, время выполнения и уровень удовлетворенности, чтобы выявить проблемы до выпуска продукта. Согласно ISO 9241-11, юзабилити охватывает три измеримых измерения: эффективность, результативность и удовлетворенность — определение, которое стандарт сохраняет с 1998 года.

Якоб Нильсен превратил это определение в повторяемую практику в Nielsen Norman Group: проводите небольшие качественные исследования рано и часто, вместо одного крупного валидационного исследования в конце разработки.

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

Зачем проводить юзабилити-тестирование перед выпуском

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

Две метрики решают спор. Показатель успешности выполнения задач говорит вам, может ли участник завершить процесс оформления заказа или этап онбординга без посторонней помощи; шкала юзабилити системы (SUS) дает вам нормированную оценку удовлетворенности, которую можно сравнивать с предыдущими релизами.

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

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

Типы юзабилити-тестирования: модерируемое, немодерируемое и удаленное

Модерируемое или немодерируемое тестирование — это первая развилка в любом плане юзабилити-тестирования, а удаленное юзабилити-тестирование применимо к обоим вариантам. Фасилитатор, проводящий модерируемую сессию в реальном времени и задающий уточняющие вопросы в рамках протокола «рассуждения вслух», понимает причины провала задачи.

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

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

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

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

Как проводить удаленное мобильное юзабилити-тестирование

Удаленное юзабилити-тестирование на мобильных устройствах проводится на собственном телефоне участника, через его собственную сеть, и в этом весь смысл: оно выявляет реальные проблемы, которые скрывает Wi-Fi-соединение в лаборатории.

Фасилитатор модерирует процесс через программное обеспечение для демонстрации экрана, такое как Lookback или UserTesting, наблюдая за охватом большим пальцем, изменениями ориентации и поведением при переключении приложений, пока участник следует протоколу «рассуждения вслух».

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

Запускайте сценарий задач как минимум на двух версиях ОС (текущая iOS, текущая Android) и варьируйте условия сети, поскольку медленные соединения обнажают проблемы с загрузкой и тайм-аутами, которые никогда не проявляются при офисном Wi-Fi.

Придерживайтесь того же размера выборки в 5 пользователей на раунд, который рекомендует исследование Якоба Нильсена для модерируемых исследований, а затем регистрируйте рейтинги серьезности для каждого вывода перед приоритизацией исправлений (User Interviews). Тегирование транскриптов с помощью ИИ теперь значительно сокращает время анализа многосессионных исследований, хотя человеческое прочтение исходной записи все равно позволяет заметить задачи, которые пропускает поиск по ключевым словам.

Элементы сессии юзабилити-тестирования

Сессия юзабилити-тестирования состоит из пяти фиксированных частей: инструктаж модератора, сценарии задач, протокол «рассуждения вслух», наблюдение и ведение заметок, а также дебрифинг, в ходе которого оценивается показатель успешности выполнения задач и часто заполняется анкета по шкале юзабилити системы (SUS). Пропустите любой из этих элементов, и данные станет труднее защитить перед скептически настроенной продуктовой командой.

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

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

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

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

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

Правило 5 пользователей Якоба Нильсена: объяснение

Правило размера выборки Якоба Нильсена гласит, что пять участников позволяют выявить примерно 85% проблем с юзабилити за один раунд тестирования, исходя из формулы N(1−(1−L)ⁿ), где L — средняя вероятность того, что один пользователь столкнется с конкретной проблемой (обычно принимается за 31%).

Согласно оригинальному исследованию Nielsen Norman Group, привлечение шестого или седьмого участника в основном приводит к повторному обнаружению проблем, которые уже нашли первые пять. Это кривая убывающей отдачи, а не жесткий предел.

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

Исследование Фолкнер 2003 года, опубликованное в Behavior Research Methods, показало, что в отдельных выборках из пяти пользователей было выявлено от 55% до 99% проблем, поэтому один раунд может пропустить гораздо больше, чем предполагает среднее значение. Десять пользователей увеличили худший показатель до 80%. Воспринимайте это как эвристику для планирования, а не как гарантию.

Как проводить юзабилити-тестирование: пошаговый рабочий процесс

Юзабилити-тестирование строится на шестиэтапном рабочем процессе. Пропустите один шаг, и данные быстро станут зашумленными.

• Пишите сценарии задач, а не инструкции. «Найдите более дешевый авиабилет на следующий вторник» лучше, чем «нажмите кнопку фильтра»; второе тестирует ваш текст в интерфейсе, а не рабочий процесс.
• Набирайте от пяти до восьми участников на каждый сегмент, подбирая реальные профили пользователей, а не случайных людей.
• Проинструктируйте фасилитатора о нейтральных подсказках. Задача фасилитатора — спрашивать «о чем вы сейчас думаете?» и в остальное время молчать; подсказки делают результаты невалидными.
• Проводите протокол «мыслей вслух» в реальном времени, модерируемо или немодерируемо, записывая экран и звук.
• Отмечайте проблемы по степени серьезности (косметические, незначительные, серьезные, блокирующие) по ходу дела, а не после завершения.
• Оценивайте уровень успешности выполнения задач и Систему оценки юзабилити (SUS) в сравнении с предыдущим раундом.

Вот пример нейтральной подсказки модератора:

> «Вы оформляете заказ на 45 долларов. Пожалуйста, проговаривайте то, что вы видите по мере выполнения. Начинайте, когда будете готовы». [пауза] «Что бы вы нажали дальше и почему?»

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

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

Команды все чаще используют первичную разметку транскрипций сессий с помощью ИИ, а затем поручают исследователю-человеку подтвердить оценки серьезности перед включением их в отчет.

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

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

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

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

Методы, инструменты и кто должен быть вовлечен

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

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

По вопросу «создавать или покупать»: стек вендоров (Maze, UserTesting, Lookback, Optimal Workshop) предлагает недорогие ежемесячные подписки на рабочее место и позволяет запустить исследование в тот же день.

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

Мы рекомендуем инструменты вендоров до тех пор, пока частота тестирования не превысит одно исследование на спринт для нескольких команд; после этого порога математика внутренней разработки начинает склоняться в пользу создания собственной панели.

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

Анализ результатов: оценки SUS и повышение конверсии

Оценка SUS ниже отраслевого стандарта говорит о том, что в дизайне есть проблема юзабилити, которую стоит исправить до того, как она попадет в A/B-тестирование; уровень успешности задач показывает, какая именно задача сломана. Вместе эти два числа превращают качественное юзабилити-тестирование в бизнес-кейс, на который может повлиять продуктовая команда.

Согласно анализу 500 исследований, проведенному MeasuringU, средняя оценка SUS составляет 68 из 100. Воспринимайте оценки ниже этого уровня как дефицит юзабилити, а не как погрешность округления. Уровень успешности задач должен стоять рядом: если фасилитатор фиксирует 60% завершения задачи оформления заказа при оценке SUS 54, это указывает на одну и ту же проблему в потоке.

Ранжируйте каждую находку по степени серьезности (критическая, серьезная, незначительная, косметическая), чтобы инженеры занимались исправлением, а не спорили о мнениях. Анализ транскрипций «мыслей вслух» и записей сессий с помощью ИИ теперь значительно сокращает время разметки для многосессионных исследований, что важно, когда исследования проводятся в рамках спринта.

Как только модерируемое юзабилити-тестирование выявит решение, подтвердите его с помощью A/B-тестирования на реальном трафике, а не выпускайте продукт, полагаясь только на уверенность исследователя. Эта последовательность — юзабилити-тест, исправление, A/B-тест — это то, что отличает UX-отчет от результата конверсии, который руководство продукта прочтет дважды.

FAQ: Ответы на вопросы о юзабилити-тестировании

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

Немодерируемое юзабилити-тестирование позволяет участнику выполнять задачи самостоятельно, без присутствия фасилитатора, обычно с записью через ПО вроде Maze или UserTesting. Оно по-прежнему позволяет фиксировать уровень успешности задач и время их выполнения в масштабе. Используйте его для быстрой валидации больших объемов; сочетайте с модерируемыми сессиями, когда вам нужны детали протокола «мыслей вслух».

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

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

Что входит в план юзабилити-тестирования?

План юзабилити-тестирования содержит цель исследования, профиль участников, сценарий задач и метрики успеха; обычно это документ на одну страницу, который исследователь просматривает перед каждой сессией. Минимальный план включает 5 задач и 30 минут времени на выполнение. Пропуск этого этапа — самый быстрый способ собрать данные, на основе которых никто не сможет принять меры.

Юзабилити-тестирование против приемочного тестирования пользователями (UAT): в чем разница?

Юзабилити-тестирование проверяет, могут ли реальные пользователи выполнить задачу с помощью дизайна; приемочное тестирование (UAT) проверяет, соответствует ли готовая функция программного обеспечения критериям приемки, установленным стейкхолдерами. Количественное юзабилити-тестирование с 5–8 участниками проводится на ранних этапах, в то время как UAT выполняется непосредственно перед релизом. Проводите оба вида тестирования, так как они выявляют разные типы ошибок.

Что такое правило 5 пользователей Якоба Нильсена?

Правило 5 пользователей Якоба Нильсена гласит, что тестирование с 5 участниками за один раунд позволяет выявить примерно 85% проблем юзабилити, согласно исследованиям Nielsen Norman Group. Рецензируемые исследования в области взаимодействия человека и компьютера (HCI), включая анализ размера выборки Вирзи 1992 года, подтверждают ту же кривую убывающей отдачи. Проводите несколько раундов по 5 пользователей в ходе итераций, а не одно масштабное исследование.

Сколько стоит юзабилити-тестирование?

Стоимость юзабилити-тестирования варьируется от почти нулевой для самостоятельной сессии с коллегами внутри компании до пятизначных сумм за полноценное исследование с профессиональным фасилитатором. Модерируемое удаленное юзабилити-тестирование обычно стоит от 3000 до 10 000 долларов за исследование, а немодерируемое — от 1000 до 5000 долларов (CleverX). Цена сильно зависит от затрат на подбор участников и дневных ставок исследователей. Бюджет масштабируется в зависимости от количества участников и типа модерации, а не от стоимости подписки на инструмент.

Какие инструменты юзабилити-тестирования лучше всего подходят для прототипов?

Maze, Lookback и UserTesting — наиболее распространенные инструменты для юзабилити-тестирования прототипов, каждый из которых поддерживает кликабельные прототипы Figma или Adobe XD с отслеживанием успешности выполнения задач. Maze подходит для быстрых немодерируемых запусков; Lookback — для модерируемых сессий с видео живого модератора. Выбирайте инструмент в зависимости от того, нужна ли вам глубина модерируемого исследования или объем немодерируемого.

Проверяйте свой дизайн до его выпуска

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

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

Netguru имеет сертификат ISO 27001, а наши дизайнеры работают в соответствии со стандартами доступности WCAG, поэтому планы тестирования подходят и для регулируемых продуктов. Эта работа является частью наших услуг по исследованию пользователей, которые сочетают юзабилити-тестирование с более широкими методами поиска и оценки для снижения рисков при принятии продуктовых решений.

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