Проверка интерфейса на живых людях находит проблемы, которые не видит ни команда, ни аналитика. Команда знает, где что лежит, и не замечает неочевидных названий. Аналитика показывает, что человек ушёл со страницы, но не объясняет причину. Наблюдение за тем, как посторонний человек решает вашу задачу на вашем сайте, объясняет. Для базового результата достаточно пяти человек и часа времени — ниже разберём, как это организовать и что делать с полученными наблюдениями.
Что готовим до встречи
Подготовка занимает больше времени, чем сама проверка, и определяет её ценность. Нужно решить, какие сценарии проверяем: обычно это путь к заявке, поиск цены и один типичный для бизнеса сценарий — подбор товара, запись, расчёт стоимости. Больше трёх сценариев за встречу брать не стоит, человек устаёт и начинает отвечать формально.
Дальше формулируем задания. Задание — это ситуация, а не инструкция: не «нажмите кнопку в шапке», а «вам нужно узнать, во сколько обойдётся замер, и записаться на него». В формулировке не должно быть слов из интерфейса, иначе человек будет искать совпадение по буквам, а не решать задачу. Заодно готовим устройство: половину проверок стоит проводить на телефоне, потому что там ломается больше.
Как проводить
- Давайте задачи, а не вопросы: «оформите заявку на замер», «найдите цену на услугу».
- Просите проговаривать мысли вслух: что человек ищет, чего ждёт, что его смутило.
- Не подсказывайте. Каждое ваше объяснение — это найденная проблема, а не помощь участнику.
- Записывайте, где человек остановился, куда он смотрел и что искал.
- Не защищайте решения команды и не объясняйте замысел до конца встречи.
- После задания спрашивайте, что было непонятно и чего не хватило для решения.
Отдельно предупредите участника, что проверяете сайт, а не его. Люди склонны винить себя («наверное, я невнимательно смотрел») и из вежливости смягчают оценки. Прямая фраза в начале — «если что-то непонятно, это наша ошибка» — заметно повышает честность ответов.
Кого звать
Подбор участников влияет на результат сильнее, чем их количество. Ниже — насколько подходят разные категории.
| Кто | Насколько подходит | Что учитывать |
|---|---|---|
| Реальные клиенты | Предпочтительный вариант | Знают предмет, говорят языком аудитории |
| Люди из целевой аудитории | Подходит | Нужно проверить, что задача им действительно близка |
| Знакомые вне отрасли | Годятся для проверки понятности | Не оценивают полноту предложения |
| Сотрудники компании | Не подходят | Знают контекст и структуру сайта наизусть |
| Коллеги-дизайнеры | Не подходят для проверки сценариев | Обсуждают оформление вместо задачи |
Если реальных клиентов позвать не получается, начните с тех, кто хотя бы раз покупал похожую услугу. Опыт покупки важнее отраслевой принадлежности: такой участник знает, какие вопросы задавать, и его заминки указывают на настоящие пробелы в содержимом страниц.
Что записывать
- Место, где возникла заминка, и сколько она длилась.
- Слова, которыми человек описывает то, что ищет: они часто отличаются от названий разделов.
- Действия, которых он ожидал, но которых не произошло.
- Момент, когда он был готов бросить задачу или сказал «дальше я бы просто позвонил».
- Прямые ошибки: нажал не туда, вернулся назад, потерял введённые данные.
Записывать лучше фактами, а не выводами. «Три раза прокрутил страницу вверх-вниз, искал цену» — наблюдение, с ним можно работать. «Страница неудобная» — оценка, из которой не следует ни одной правки. Выводы делаются позже, когда наблюдения собраны от всех участников.
Чем это дополняет аналитику
Счётчики и записи сеансов отвечают на вопрос «где», проверка на людях — на вопрос «почему». Поэтому мы стараемся использовать их вместе: сначала смотрим в аналитике, на каких страницах и шагах теряется больше всего людей, и берём именно эти места в задания. Так проверка не растекается по всему сайту и подтверждает или опровергает конкретную гипотезу.
Обратный порядок тоже работает. После встречи полезно вернуться к цифрам и посмотреть, подтверждается ли наблюдение массово: если трое из пяти не нашли раздел с ценами, в данных должно быть видно, что до него доходит мало людей. Совпадение двух источников — достаточное основание, чтобы ставить правку в план без дополнительных обсуждений.
Сколько нужно участников
Пять человек находят большинство серьёзных проблем. Дальше начинаются повторы: шестой и седьмой участники спотыкаются там же, где первые. Полезнее провести две небольшие проверки — до и после правок, — чем одну большую: вторая покажет, действительно ли правка сняла проблему или переставила её на шаг дальше.
Если у сайта принципиально разные группы пользователей — например, частные клиенты и снабженцы организаций, — считайте их отдельно: по три-четыре человека на группу. Смешивать их наблюдения нельзя, у групп разные ожидания и разный порядок вопросов.
Удалённый формат и запись
Встречу необязательно проводить лично. Видеозвонок с демонстрацией экрана даёт почти тот же результат и снимает главное ограничение — географию: участника можно позвать из любого города, а запись потом посмотрит вся команда. Единственное, что теряется, — мимика и то, куда человек смотрит; частично это компенсируется просьбой комментировать вслух активнее обычного.
Запись стоит вести всегда, спросив разрешение в начале. По памяти половина деталей теряется уже к вечеру, а спорные моменты потом разбираются по конкретной минуте, а не по пересказу. Для мобильных сценариев достаточно поставить телефон на подставку и снимать экран сверху: специальное оборудование для этого не требуется.
Что делать с результатами
Разложите наблюдения по частоте: то, на чём споткнулись трое из пяти, правится первым. Единичные замечания стоит записать, но не переделывать под них интерфейс — они часто отражают личную привычку, а не общую проблему. Дальше проблемы сортируются по цене исправления: часть из них закрывается изменением подписи или порядка блоков, часть требует переделки раздела.
Результат встречи — не отчёт, а список задач с приоритетом. Мы обычно сводим его в таблицу: что наблюдали, сколько человек, что меняем, кто отвечает. После правок берём те же задания и повторяем проверку на новых участниках — это дешевле любого спора о том, стало лучше или нет.
Частые ошибки организаторов
Первая — присутствие автора интерфейса, который поясняет замысел. Вторая — вопросы вида «удобно ли вам?»: люди отвечают «да» из вежливости, а наблюдение за их действиями за минуту до этого говорит обратное. Третья — проверка на макете вместо рабочего сайта, где нет реальных данных и настоящей скорости загрузки.
Четвёртая, самая обидная, — проверка без последствий. Наблюдения собрали, обсудили, записали в документ и вернулись к плану работ. Если по итогам не изменилось ничего, следующую проверку в команде уже воспринимают как формальность. Лучше взять три проблемы и исправить их, чем составить список из тридцати и не тронуть ни одной.
Приглашение
Если проводить проверку внутри некому или нужен взгляд со стороны, мы разбираем сайт по сценариям и отдаём список проблем с приоритетом и вариантами решения. Посмотрите, что входит в аудит юзабилити сайта, и напишите нам — начнём с обсуждения задач.
Если интерфейс уже мешает продажам, разбираем его по шагам: проектирование интерфейсов с прототипом и тестированием.
