CJM за 30 минут: карта пути пользователя которую реально используют в работе

Откройте любой Miro-борд с надписью «CJM» в названии. С вероятностью 80% вы увидите красивую разноцветную простыню на 12 колонок, которую сделали полгода назад, показали один раз на стратсессии и больше не открывали. Иногда там даже эмоции пользователя прорисованы кривой линией — но решений, принятых на её основе, нет.

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

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

## Почему длинные CJM не работают

Классическая логика: «давайте опишем весь путь от первого касания до повторной покупки, найдём боли, расставим приоритеты». Звучит правильно. На практике ломается на трёх вещах.

Слишком широкий scope. Когда карта охватывает 8 этапов и 5 каналов, в каждой клетке остаётся по одному слову. Это уже не диагностика, а оглавление.

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

Сделана один раз. Реальный продукт меняется каждый спринт, CJM — нет. Через два месяца карта врёт, и команда это знает. Поэтому в неё и не смотрят.

Карта за 30 минут лечит всё это автоматически. Узкий scope — потому что больше не успеешь. Владелец — тот, кто карту инициировал. Актуальность — потому что её не жалко выкинуть и сделать заново.

## Когда стоит делать CJM, а когда нет

Перед тем как звать команду в переговорку, проверьте себя.

Делать стоит, если:

• В метриках видно проседание на конкретном шаге, но непонятно почему
• Поддержка несколько недель подряд получает похожие жалобы
• Команда спорит «у пользователя тут проблема или нет» — без общей картины
• Запускаете новую фичу и нужно понять, во что она встраивается
• Только что прошли интервью и сырые инсайты надо во что-то сложить

Делать не стоит, если:

• Проблема уже понятна и нужно просто её решить — садитесь и решайте
• Нет ни данных, ни интервью, ни доступа к пользователям — будет фантазия, а не карта
• Цель — «сделать красивый артефакт для презентации руководству». Это не CJM, это слайд

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

## Минимальный набор: что должно быть в карте за 30 минут

Забудьте про шаблоны из интернета на 14 столбцов. Для рабочей карты хватает пяти.

### 1. Шаги сценария

Конкретные действия пользователя, не абстрактные стадии. Не «Awareness — Consideration — Purchase», а «увидел push — открыл приложение — попал на главную — нажал на баннер». Уровень детализации — такой, чтобы каждый шаг можно было показать на скриншоте.

### 2. Цель пользователя на этом шаге

Что он пытается сделать прямо сейчас. Не «получить ценность от продукта», а «понять, сколько стоит доставка до моего города». Если на шаг не получается сформулировать цель — значит, шаг лишний или вы его придумали.

### 3. Что он делает и видит

Действие + интерфейс. Сюда же — каналы (приложение, email, звонок в поддержку). Это якорь к реальности: если на этом шаге у вас в продукте ничего нет, это уже инсайт.

### 4. Боль или трение

Не эмоция в общем («раздражён»), а конкретное препятствие: «не видит кнопку», «не понимает, почему просят паспорт», «ждёт 40 секунд загрузки». Боль должна быть такой, чтобы её можно было превратить в задачу.

### 5. Возможность

Что с этим можно сделать. Одна-две гипотезы на шаг, не больше. Если на боль нет идеи — это нормально, оставьте пусто. Лучше честное пустое поле, чем «улучшить UX».

Всё. Никаких «mindset», «touchpoints», «backstage actors» и прочего из учебников. Их можно добавить потом, если правда понадобятся — обычно не понадобятся.

## Рабочий процесс: как уложиться в 30 минут

Тридцать минут — это не метафора. Это жёсткое ограничение, которое заставляет резать лишнее. Разбейте время грубо так:

• 5 минут — договориться о scope. Один сценарий, один сегмент, один контекст. Пишете на доске одной строкой: «новый пользователь оформляет первый заказ с мобайла».
• 10 минут — накидать шаги. Стикеры, маркер, без обсуждений. Пока не закончили шаги — не лезем в боли.
• 10 минут — заполнить боли и наблюдения. Здесь нужны данные: цитаты из интервью, скрины из аналитики, тикеты поддержки. Без них честно пишем «гипотеза».
• 5 минут — пометить, что забираем в работу. Не «обсудим позже», а конкретные строки → конкретные задачи с владельцами.

Если в команде больше трёх человек — выбирайте одного, кто держит маркер и темп. Иначе через 40 минут вы всё ещё спорите про название первого этапа.

### Что взять с собой на сессию

• Один-два сырых транскрипта интервью или хотя бы цитаты
• Скриншоты ключевых экранов сценария
• Воронка из аналитики по этому флоу
• Список последних жалоб из поддержки по теме

Без этого CJM превращается в коллективную фантазию. С этим — в инструмент.

## Диагностика: на что смотреть в готовой карте

Карта готова. Не вешайте её на стену — сначала прогоните по диагностическим вопросам.

### Вопросы для ревью

• На каком шаге боли в три раза гуще, чем на остальных? Это узкое место — туда и идём.
• Есть ли шаг без боли? Проверьте дважды: либо там действительно всё хорошо, либо вы там ничего не знаете.
• Есть ли боль без шага? Часто всплывает «ожидание между двумя действиями» — отдельный невидимый этап, который мы пропустили.
• Можно ли каждую боль переписать как задачу в бэклог? Если нет — формулировка слишком общая.
• Видно ли, где пользователь переключает канал (приложение → почта → звонок)? Стыки каналов — самые недоказанные части любого продукта.

### Признаки, что карта получилась

• На каждом шаге видна конкретная цель пользователя, а не «получить опыт»
• В колонке боли есть хотя бы одна цитата или цифра, а не только интерпретации
• Из карты родилось 2–5 задач, у каждой есть владелец
• Команда спорит не «правда ли это», а «что с этим делать»

## Типичные ошибки и анти-паттерны

Карта как пересказ интерфейса. Шаги слово в слово повторяют экраны продукта. Тогда CJM не добавляет ничего — у вас уже есть флоу в Figma. Карта должна показывать не что есть, а где рвётся.

Боли уровня «пользователь раздражён». Эмоция — не диагноз. Дальше неё надо копать: чем именно раздражён, в какой момент, что именно увидел. Иначе задача будет такая же размытая — «улучшить опыт».

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

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

Дизайнер делает CJM в одиночку. Можно, но это уже не CJM, а аналитическая записка. Сила карты — в том, что разные роли видят одну картину одновременно. Без продакта, поддержки и аналитика вы соберёте только свою половину правды.

## Как переложить карту в макет и продукт

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

### От шага к экрану

Возьмите шаг с самой плотной болью и откройте в Figma тот экран, который ему соответствует. Положите рядом. Дальше для каждой боли — одно из трёх решений:

• Меняем экран. Боль решается интерфейсом: добавить подсказку, переписать кнопку, убрать поле. Это прямой путь в макет.
• Меняем флоу. Боль не на экране, а в порядке шагов. Тогда правим не пиксели, а структуру: переносим шаг, объединяем, убираем.
• Меняем не продукт. Боль вне дизайна: письмо от маркетинга, скрипт поддержки, политика возвратов. Это задача не вам, но владелец боли всё равно нужен.

### Чеклист перед тем, как идти в макет

• Я понимаю, какую конкретную боль решает это изменение
• Я знаю, как пойму, что стало лучше (метрика, фидбэк, тест)
• Изменение не ломает соседний шаг сценария
• Если боль была гипотезой — есть способ её проверить до большой переделки

### Когда карта врёт

Через две-три недели после внедрения изменений возвращайтесь к карте и сверяйтесь. Если воронка не сдвинулась там, где ждали — карта в этом месте ошибалась. Это не провал, это нормальный цикл. Хуже — когда карту никто не открывает повторно и она остаётся памятником одной сессии.

## Короткий итог сегмента

CJM за 30 минут работает не потому, что быстрая, а потому что встроена в спринт: узкий scope, живые данные, явный владелец, выход в задачи. Всё, что мешает этому циклу — лишние столбцы, красивые рамки, отсутствие гипотез — превращает карту обратно в артефакт. Дальше разберём, как делать такие карты в команде на удалёнке и как уживаются CJM, Service Blueprint и user flow.

## CJM в распределённой команде

Удалёнка ломает у CJM главное — общее время у одной доски. На созвоне труднее ловить полутона, легче пропустить молчащего аналитика, а боль из чата поддержки превращается в скриншот без контекста. Поэтому формат меняется не «доска в Miro вместо стикеров», а целиком.

### Что работает на распределёнке

• Асинхронный сбор данных до созвона. За день до сессии каждый накидывает в общий документ то, что видит со своей стороны: продакт — гипотезы, поддержка — топ обращений, аналитик — провалы в воронке. На созвон приходят с фактами, а не с воспоминаниями.
• Один владелец курсора. На звонке двигает стикеры один человек, остальные комментируют. Иначе карта расползается в шесть направлений и никто не помнит, кто что переставил.
• Таймбокс на каждый блок. 5 минут на шаги, 7 на боли, 5 на гипотезы. Без жёсткого таймера созвон уезжает в обсуждение одного экрана на полчаса.
• Запись и расшифровка. Не для отчётности, а для того, чтобы вернуться к спорному месту через неделю и не пересобирать контекст с нуля.

### Анти-паттерн распределённой карты

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

## CJM, Service Blueprint и user flow: кто за что отвечает

Эти три артефакта постоянно путают, особенно в командах, где их рисует один и тот же дизайнер.

• User flow — что происходит в интерфейсе. Экраны, кнопки, ветвления. Отвечает на вопрос «как устроен путь внутри продукта».
• CJM — что происходит с пользователем. Цели, действия, эмоции, каналы. Отвечает на вопрос «где ему плохо и почему».
• Service Blueprint — что происходит за кулисами. Бэкстейдж-процессы, системы, роли сотрудников. Отвечает на вопрос «почему продукт ведёт себя именно так».

Практическое правило: если боль на CJM упирается в «здесь долго грузится» или «менеджер перезванивает через два дня» — пора рисовать кусок Blueprint. Если упирается в «непонятно, куда нажать» — открываем user flow и макет.

## AI и CJM: где помогает, где врёт

Соблазн скормить LLM выгрузку из поддержки и получить готовую карту — большой. На практике AI закрывает узкие задачи, но не заменяет сессию.

### Где LLM реально ускоряет

• Кластеризация обращений. Тысяча тикетов превращается в 15 тем за минуты. Дальше темы вешаются на шаги карты руками.
• Черновик шагов сценария. По описанию продукта и роли пользователя модель даёт скелет из 7–10 шагов. Это стартовая точка, а не финальная карта.
• Переформулировка болей в задачи. «Раздражает форма» → «сократить форму до 3 полей, добавить автозаполнение по ИНН». Хорошо работает как ассистент на ревью.
• MCP-доступ к Figma и трекеру. Если настроен — можно за один проход проверить, какие шаги карты уже покрыты макетами и какие задачи висят в бэклоге без владельца.

### Где AI стабильно врёт

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

Рабочее правило: AI готовит черновик и сводки, человек принимает решения. Любую боль, которую вынесла модель, проверяем по источнику — цитате, тикету, записи интервью. Нет источника — переносим в гипотезы.

## Как объяснить карту команде и стейкхолдерам

CJM часто проваливается не на сборке, а на презентации. Карту показывают как картинку, и руководитель видит «дизайнер нарисовал ещё одну схему».

### Структура разговора на 10 минут

1. Сценарий и сегмент в одной фразе. «Новый b2b-клиент впервые подключает интеграцию». Без этого слушатель додумывает свой контекст.
2. Две-три точки боли с источником. Не вся карта подряд, а самое плотное. К каждой — цитата или цифра.
3. Что предлагаем сделать. Список задач с владельцами и ожидаемым эффектом.
4. Что не делаем и почему. Это снимает половину возражений: видно, что вы взвешивали, а не хватались за первое.

### Вопросы, на которых карта проверяется

• Какое решение мы примем по-другому, посмотрев на эту карту?
• Что в карте — факт, что — гипотеза, что — догадка?
• Какие шаги мы не видим, потому что у нас нет данных?
• Кто владелец каждой задачи на следующей неделе?

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

## Короткий итог сегмента

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

## Мини-CJM в спринте: как карта не умирает после первой презентации

Главная причина, по которой CJM перестают использовать, — её рисуют один раз и кладут в Confluence. Через месяц данные устарели, через два — никто не помнит, кто её собирал. Чтобы карта жила, она должна обновляться кусками, а не целиком.

### Ритм, который реально приживается

• Раз в спринт — один срез. Берём один сценарий или один сегмент и проверяем 3–4 шага: что изменилось в данных, что закрыли макетами, какие боли всплыли в поддержке.
• Раз в квартал — пересборка фокуса. Меняется ли главный сценарий? Появился ли новый сегмент? Уехал ли старый из приоритетов?
• Точечно — под фичу. Перед крупной задачей рисуем мини-CJM на 5–7 шагов вокруг неё. Это дешевле, чем поднимать большую карту.

Хорошо работает правило «карта живёт там, где её видно ежедневно»: Figma-файл рядом с макетами, ссылка в шапке проекта, скрин на дашборде. В архивной папке она умирает за неделю.

## Финальный чеклист: карта готова к работе

• У карты один сценарий и один сегмент, оба сформулированы в одной фразе
• Каждый шаг описан глаголом действия пользователя, а не названием экрана
• Боли отделены от гипотез: рядом с каждой болью — источник или пометка «гипотеза»
• Эмоции стоят только там, где есть подтверждение, остальное оставлено нейтральным
• У каждой выделенной возможности есть владелец и понятный следующий шаг
• Указана дата сборки и автор, чтобы через месяц было ясно, насколько данные свежие
• Есть пометка, что из карты — факт, что — гипотеза, что — догадка
• Карту видно из рабочего файла команды, а не только по прямой ссылке

Если хотя бы три пункта проваливаются — карту рано показывать стейкхолдерам, она ещё черновик.

## Анти-паттерны, на которые регулярно натыкаются

### Карта-памятник

Огромная простыня на 40 шагов, 6 каналов, 12 сегментов в одной таблице. Выглядит впечатляюще, использовать невозможно. Лечится разбиением на отдельные карты по сценариям.

### Карта без боли

Аккуратно нарисованные шаги, ровные эмоции, всё хорошо. Обычно значит, что данные не смотрели, а рисовали по ощущениям. Если на карте нет ни одной острой формулировки — это маркетинговый слайд, а не CJM.

### Карта-обвинение

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

### Карта без следующего шага

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

### Карта по интервью одного человека

Один разговор с одним клиентом превращается в карту, которую выдают за «путь сегмента». Минимум — три источника разной природы: интервью, данные, поддержка.

## Вопросы для ревью карты

Эти вопросы стоит задавать себе перед тем, как нести карту команде, и команде — перед тем, как принимать карту в работу.

• Какое решение мы примем по-другому, посмотрев на эту карту?
• На каком шаге боль самая дорогая для бизнеса, а на каком — для пользователя? Это один и тот же шаг?
• Что в карте устареет первым и как мы это заметим?
• Какие шаги мы нарисовали по ощущениям, а не по данным?
• Что мы сознательно не делаем по итогам карты и почему?
• Кто отвечает за то, что через месяц карта всё ещё актуальна?

Если на половину вопросов нет ответа — это нормально, но эти места нужно подсветить прямо на карте, а не делать вид, что их нет.

## Практический итог

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