Как найти трение в одном пользовательском сценарии

Границы одного пути

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

Уточняю, для кого строю путь: новый посетитель на телефоне и постоянный клиент с сохранёнными данными сталкиваются с разными препятствиями. В руководстве Nielsen Norman Group карта пути тоже привязана к определённому участнику и сценарию. Не стоит смешивать всех пользователей в одну универсальную схему.

Карточка препятствия: от экрана до проверки

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

• Участник и цель: новый посетитель с телефона хочет забронировать выбранное время.
• Шаг: после календаря открывается форма контактов.
• Ожидание: понять, что осталось до подтверждения.
• Ответ системы: обязательное поле телефона без пояснения его назначения.
• Наблюдение: на экране нет ответа, для чего нужен контакт. Уход посетителей по этой причине пока не установлен.
• Гипотеза: часть людей сомневается, как будет использован номер.
• Проверка: сначала выяснить реальное назначение поля у команды, затем проверить понимание точного пояснения с подходящими участниками.

Рядом оставьте место для даты, устройства, версии экрана и подтверждения. Снимок покажет отсутствие пояснения, но не мотив человека. Если номер нужен для звонка специалиста, нельзя написать "только для подтверждения записи" ради более спокойного впечатления.

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

Наблюдение и его объяснение

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

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

На чём основан вывод

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

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

Первое изменение для проверки

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

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