Коротко. Customer Journey Map (CJM) — карта пути клиента от возникновения потребности до результата: этапы, действия, точки контакта, вопросы, ожидания, эмоции и барьеры. Чтобы построить карту, выбирают один сегмент и один сценарий, собирают факты из интервью и аналитики, раскладывают путь на этапы и находят барьеры. Найденные барьеры превращают в возможности, а приоритетные возможности — в функциональные и нефункциональные требования к продукту.
Что показывает Customer Journey Map
Customer Journey Map, или карта пути клиента, показывает, как человек движется от потребности к результату. Она объединяет действия, точки контакта, вопросы, ожидания, эмоции и препятствия на разных этапах.
CJM не является схемой экранов. Пользовательский путь может начинаться в поиске, продолжаться на сайте, переходить в звонок или офлайн-точку и завершаться уведомлением после услуги. Если нанести только интерфейс будущего продукта, команда потеряет контекст и причины поведения.
Карта нужна, чтобы увидеть процесс глазами конкретного сегмента и связать наблюдения с решениями продукта.
Из каких слоёв состоит карта пути клиента?
Каждый этап описывают набором слоёв: что человек делает, о чём думает, что чувствует, где взаимодействует с брендом и что мешает ему двигаться дальше.
| Слой карты | Что фиксируем | Зачем нужен |
|---|---|---|
| Этапы | Изменение состояния пользователя и цель этапа | Показывают, где человек движется, а где застревает |
| Действия | Что человек делает: ищет, сравнивает, заполняет форму, ждёт | Обозначают реальное поведение, а не интерфейс |
| Мысли и вопросы | Какой информации не хватает на каждом шаге | Подсказывают содержание и объяснения в продукте |
| Эмоции | Моменты уверенности и тревоги с конкретной причиной | Указывают места наибольшего напряжения — на основе исследования, а не выдумки |
| Точки контакта | Поиск, сайт, приложение, письмо, звонок, офлайн | Показывают разрывы между каналами |
| Барьеры и риски | Что мешает перейти дальше или увеличивает усилие | Становятся источником возможностей и требований |
Выбрать сегмент и сценарий
Одна карта должна описывать понятного участника и одну цель. Путь нового клиента отличается от пути постоянного. Профессиональный пользователь решает задачу иначе, чем человек, который впервые столкнулся с темой.
Сценарий формулируют как результат: выбрать и получить услугу, купить билет, найти материал, опубликовать содержимое или восстановить доступ. Слишком широкая цель превращает карту в поверхностный обзор всего продукта.
Перед началом фиксируют контекст. Что произошло до первого шага? Какой триггер заставил действовать? Какие ограничения есть у человека? Как он поймёт, что задача завершена?
Собрать факты о текущем пути
Источниками служат интервью, наблюдения, аналитика, обращения в поддержку, записи сессий и данные текущего процесса. Интервью с сотрудниками полезны, но не заменяют разговор с пользователями: организация часто представляет идеальный процесс, а люди используют обходные пути.
Нужно отделять факт от предположения. «Пользователь сравнил три варианта» может быть наблюдением. «Он хочет видеть больше фильтров» — гипотезой, пока не выяснена реальная причина затруднения.
Если данных мало, карту можно построить как рабочую гипотезу. Важно явно обозначить участки, которые требуют проверки.
Разложить путь на этапы
Этапы описывают изменение состояния пользователя, а не страницы сайта. Типовая последовательность может включать возникновение потребности, поиск, оценку вариантов, решение, выполнение действия, получение результата и опыт после него.
Для каждого этапа фиксируют цель. На этапе поиска человек хочет сформировать набор вариантов. На этапе оценки — снизить неопределённость. Во время оформления — завершить действие без ошибки. После результата — убедиться, что всё прошло и понять следующий шаг.
Количество этапов должно помогать анализу. Слишком крупные скрывают проблемы, слишком мелкие превращают карту в длинную инструкцию.
Зафиксировать действия, мысли и эмоции
Действия показывают, что человек делает: вводит запрос, читает, сравнивает, обращается к сотруднику, заполняет форму или ждёт ответа.
Мысли и вопросы объясняют, какой информации не хватает. «Подходит ли этот вариант?», «Можно ли изменить решение?», «Почему нужна эта информация?», «Что произойдёт после оплаты?»
Эмоции помогают определить моменты уверенности и тревоги, но их нельзя придумывать для красивого графика. Они должны опираться на исследование. Полезнее записать конкретную причину напряжения, чем просто поставить отрицательный смайлик.
Также отмечают точки контакта: поиск, сайт, приложение, письмо, звонок, физическое пространство и взаимодействие с сотрудником.
Найти барьеры и точки риска
Барьер мешает перейти к следующему этапу или увеличивает усилие. Это может быть непонятный термин, отсутствие информации, слишком раннее требование данных, разрыв между каналами или ожидание без статуса.
Точки риска особенно важны в критических сценариях. Потеря введённых данных, неоднозначный результат оплаты, отсутствие подтверждения или невозможность восстановить действие создают не только неудобство, но и операционные затраты.
Следует отмечать и внутренние причины. Если сотрудник вручную переносит данные между системами, клиент может видеть задержку, хотя проблема находится за пределами интерфейса.
Связать проблемы с возможностями
После выявления барьеров команда формулирует возможности. Не «добавить кнопку», а «помочь человеку сравнить варианты», «снизить неопределённость перед оплатой» или «сохранить прогресс при прерывании».
Одна возможность может иметь несколько решений. Сравнение поддерживается фильтрами, таблицей, рекомендацией или консультацией. Выбор зависит от частоты задачи, сложности данных и стоимости реализации.
Возможности приоритизируют по влиянию на цель пользователя и бизнеса, распространённости проблемы, риску и затратам. Не каждая неприятная эмоция требует новой функции.
Пример: для FoodTech-приложения маркетплейса CJM стала основой переработки UX, а концепции поисковой и рекомендательной механик проверили на исследовании более 100 000 поведенческих реакций (кейс).
Как из барьеров получить требования, а не список фич?
Приоритетную возможность описывают сценарием будущего состояния, из него выводят функциональные и нефункциональные требования, а затем связывают каждое требование с этапом карты и наблюдаемой проблемой.
Превратить карту в требования
Для приоритетных возможностей описывают сценарий будущего состояния. Кто действует? В каком контексте? Какой результат должен получить? Какие данные и правила необходимы?
Затем формулируют функциональные и нефункциональные требования. Подтверждение операции становится требованием к статусу и уведомлению. Продолжение после прерывания — к сохранению данных. Работа в дороге — к мобильной версии и производительности.
Каждое требование полезно связать с этапом CJM и наблюдаемой проблемой. Такая трассировка помогает защищать приоритет и удалять функции, потерявшие основание.
Как это выглядит на практике: для театрального портала собранная CJM превратилась в техническую документацию с требованиями к архитектуре и функционалу, а улучшенный интерфейс поднял конверсию на 17% (кейс).
Карта также подсказывает метрики: успешность сценария, время прохождения, долю отказов, повторные обращения и количество переходов в другой канал.
Как поддерживать CJM актуальной
Путь меняется после запуска продукта, изменения процесса и появления новых каналов. Карта не должна оставаться архивом исследования.
После релиза её проверяют по аналитике и обратной связи. Где пользователи останавливаются? Какие вопросы поступают в поддержку? Какие предположения не подтвердились?
Иногда проверка по данным меняет приоритеты сильнее новой функции: в приложении для автомобилистов исправленная аналитика показала реальное узкое место удержания, и возврат базовой push-механики удвоил retention (кейс).
Для крупных изменений обновляют соответствующий сценарий, а не полностью перерисовывают все карты. Важно сохранять связь между наблюдением, возможностью, решением и метрикой.
CJM полезна не как большая схема на стене, а как инструмент решений. Она помогает команде увидеть целый путь, найти причины затруднений и превратить пользовательский опыт в конкретные требования к продукту и процессу.
В продуктовой экологии Roirate путь клиента, аналитика и приоритизация задач разбираются как одна система — карта становится частью этой работы, а не отдельным артефактом.