Юзабилити-тестирование
Usability Testing
Юзабилити-тестирование (usability testing) показывает, где люди спотыкаются о продукт. Участнику дают реалистичную задачу, например оформить заказ или найти настройку, и наблюдают, как он её выполняет. Исследователь фиксирует, где человек буксует, ошибается или теряет ориентацию.
- Сроки
- 3–14 дней
- Респонденты
- 5–7 человек
- Команда
- 1–2 человека
- Бюджет
- Низкий
- Сложность
- Средний
- Популярность
- Часто
Содержание
Когда использовать
Метод отвечает на вопрос «почему» там, где аналитика показывает только «где». Почему бросают корзину, почему не находят раздел, почему не доходят до конца регистрации. Аналитика видит провал воронки, тест показывает, что человек в этот момент искал и чего не понял.
Тестировать можно на любом этапе. Подойдёт прототип любой детализации, даже наброски на бумаге, если на них можно выполнить осмысленную задачу (гайд Контура). Тест на прототипе дешевле всего, потому что править макет быстрее, чем готовый продукт. Тестировать обязательно, если готовится редизайн или крупная новая функция, если затронуты критичные сценарии или изменения коснутся большинства пользователей.
Тест бывает качественным и количественным. Качественный ищет проблемы и их причины, на нём строится большинство исследований. Количественный измеряет долю выполненных задач и время, его используют для сравнения с прошлой версией или конкурентом, и участников для него нужно заметно больше. Ещё тест бывает модерируемым и немодерируемым: с ведущим на связи или без него, когда участник проходит задания сам в онлайн-сервисе.
Тест показывает поведение, а не мнения и мотивы. Он не ответит, купят ли продукт, и не поможет расставить приоритеты по тому, что участникам понравилось. Из вежливости люди хвалят то, что им показывают, а на маленькой выборке их оценкам нельзя доверять. Зачем человеку вообще нужен продукт, выясняют на глубинных интервью. Нормальная роль теста — инструмент работы над прототипом, а не экзамен, за который интерфейс получает оценку.
Что нужно для старта
- Вопрос исследования — что именно хотите узнать
- Прототип или работающий продукт, на котором можно выполнить задачу
- Сценарий из нескольких коротких задач
- Доступ к пяти-семи людям из аудитории — свои пользователи или онлайн-панель
- Видеосвязь с показом и записью экрана, если тест удалённый
- Второй человек для заметок или запись сессии
Как провести
-
Вопрос исследования
Решите, что хотите узнать, например «почему люди не завершают регистрацию» или «находят ли новички раздел с тарифами». От вопроса зависят задачи и то, кого звать на тест.
-
Задачи
Несколько коротких задач работают лучше одной длинной. Формулируйте их от жизненной ситуации и не называйте кнопки и разделы. «Найдите подарок другу до 3000 рублей» вместо «Откройте раздел Подарки и настройте фильтр цены». Перед первой сессией проведите пробную встречу с коллегой, как рекомендует и британская служба госуслуг GOV.UK в руководстве по тестированию. Так находятся непонятные задачи и дыры в прототипе.
-
Прототип
Прототип не должен воспроизводить весь сервис, хватит экранов, по которым проходит задача. Данные в нём должны быть правдоподобными и одинаковыми на всех экранах. Контур приводит пример: организация «ОАО Звезда смерти» и дата 31 сентября отвлекают бухгалтера от задачи, а «ОАО Цифровые технологии» и 23 августа — нет. Ошибки в текстах и цифрах участник замечает и перестаёт доверять тесту.
-
Участники
Зовите реальных или вероятных пользователей. На модерируемый тест хватает пяти-семи человек. Для качественного теста одной группы достаточно пяти. Если групп две, хватит трёх-четырёх из каждой, если три и больше — по три. Для количественного теста нужно от двадцати участников.
-
Сессия
Сессия длится 30–60 минут, в день лучше проводить не больше шести, с перерывом от 15 минут между ними. Ведущий объясняет, что проверяют продукт, а не человека, просит думать вслух и дальше в основном молчит. Второй человек записывает наблюдения, а если работаете в одиночку — включите запись экрана.
-
Заметки по горячим следам
Записывайте проблему с контекстом. «Не нашёл кнопку» — плохая запись. «Искал кнопку Добавить в корзину в шапке, зону под баннером не посмотрел» — хорошая.
-
Тяжесть проблем
Найденное сводят в список и оценивают по шкале от 0 до 4. Ноль — не проблема, один — косметическая, два — небольшая, три — серьёзная, четыре — катастрофа, которую нужно исправить до выпуска. На оценку влияют три вещи: как часто проблема встречается, насколько мешает и повторяется ли. Оценке одного человека доверять не стоит, лучше усреднить оценки трёх.
-
Следующий раунд
Исправьте найденное и протестируйте снова. Ждать конца раунда не обязательно. Если после двух-трёх сессий видна критичная ошибка, поправьте прототип и продолжайте уже на новой версии. Три раунда по пять человек с правками между ними дают больше, чем один тест на пятнадцать. Простой раунд занимает около трёх дней — подготовка, пять сессий, анализ.
Результат
Главный результат — список проблем. У каждой указано, на какой задаче она возникла, что сделал участник, его слова, сколько участников столкнулись и тяжесть по шкале от 0 до 4. Сверху списка — серьёзные проблемы и катастрофы, их чинят в первую очередь. К каждой проблеме прикладывают нарезку видео с этим моментом. Хранить стоит и исходные записи с транскриптами (гайд Контура по артефактам), чтобы проверить выводы или ответить на новый вопрос без новых встреч.
Типичные ошибки
-
Подсказывать участнику
Участник замолчал на несколько секунд, и ведущий говорит «а вы пробовали посмотреть здесь?». Теперь уже не узнать, нашёл бы он это сам. Подсказки меняют поведение участника. Вмешиваться можно, только если человек совсем застрял. Тогда отметьте это и не считайте задачу выполненной самостоятельно.
-
Наводящие вопросы
Вопрос «почему у вас были трудности с навигацией?» сам подсказывает ответ и перекладывает вину на участника. Нейтральный вариант — «что было легко или трудно, когда вы искали нужное?». Не называйте элементы интерфейса, а показывайте на область и спрашивайте, что это.
Российская специфика
Если своих пользователей позвать нельзя, участников ищут через онлайн-панели. Например, Tiburon Research, по данным сервиса около 670 тысяч респондентов и отдельная панель для B2B, и Анкетолог, около 330 тысяч активных. Рекрутинг именно на юзабилити-тесты оба сервиса прямо не описывают, условия уточняют у менеджера.
Кто использует
Ozon Банк проводит немодерируемые тесты на прототипах в Figma. UX-исследователь банка описала на Хабре, как их готовят. Анкету сначала проверяют на пилоте из 20–30 человек. В тестах на сравнение макеты отличаются только проверяемой деталью, а прототип не должен вести участника единственным путём.
Место в процессе
- Экспертная оценкаЭкспертная оценка (heuristic evaluation) проверяет интерфейс по набору принципов юзабилити. Несколько экспертов проходят продукт самостоятельно, каждый записывает найденные проблемы, потом списки сводят в один. Пользователи не участвуют.
- Кабинетное исследованиеКабинетное исследование (desk research, или secondary research) изучает то, что уже известно по теме, прежде чем идти к пользователям. Это прошлые исследования команды, аналитика, обращения в поддержку, публикации и открытые данные. Метод дёшево уточняет вопрос и подсказывает, что стоит проверять на людях, но сам не заменяет интервью и тесты.
Инструменты для результатов
Источники и что почитать
Сервисы
Источники
- Выбор метода ЮТ
- Подготовка прототипа к юзабилити-тестированию
- Принципы пользовательских исследований
- Анализ данных исследования
- Артефакты исследований
- Как составлять анкеты для немодерируемых UX-тестов: пошаговое руководство
- Сервис онлайн-исследований
- Сервис опросов и панель респондентов
- Usability (User) Testing 101
- Why You Only Need to Test with 5 Users
- A Mathematical Model of the Finding of Usability Problems
- Beyond the five-user assumption: benefits of increased sample sizes in usability testing
- Why you only need to test with five users (explained)
- Thinking Aloud: The #1 Usability Tool
- Severity Ratings for Usability Problems
- Avoid Leading Questions to Get Better Insights from Participants
- Using moderated usability testing