JTBD и journey map: из интервью, тикетов, аналитики и кода

Формулировка работы по Strategyn: глагол + объект + уточнение контекста, без слов-решений. Тест Калбаха простой: «сказали бы так пятьдесят лет назад?». Желаемый результат записывается как направление + метрика + объект + уточнение, например «минимизировать время на поиск нужной песни». У результата пять тестов: измерим, зависит от дизайна, предсказывает успех, не зависит от решения, стабилен.

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

Job story от Intercom звучит так: «Когда [ситуация], я хочу [мотивация], чтобы [результат]». Четыре силы Моэсты: толчок ситуации, притяжение нового, тревога перед новым, привычка к старому. Переключение происходит, когда толчок с притяжением сильнее тревоги с привычкой.

Таймлайн переключения: первая мысль → пассивный поиск → активный поиск → решение → онбординг. Спрос рождается в «моменте борьбы». В switch-интервью спрашивают хронологию, а не силы напрямую.

Из интервью модель выделяет формулировку работы, 5–15 желаемых результатов с цитатами, job stories по ситуациям и таблицу четырёх сил по каждому участнику. Всё, что выведено без цитаты, помечается ВЫВЕДЕНО и идёт в список на проверку.

Из тикетов и отзывов можно получить формулировки потребностей. Тимошенко, Мао и Хаузер показали, что дообученные модели формулируют потребности клиентов не хуже профессиональных аналитиков и без выдумок, а базовые модели без дообучения заметно хуже. Для дизайнера это значит, что черновик из чата нужно править.

Важность и удовлетворённость по каждой потребности — основа метода ODI. Из текстов их не вытащить; для них нужен опрос. Связь с темой «Рисерч по открытым источникам» такая: классификация отзывов там, формулировка потребностей здесь.

Элементы карты: действующее лицо; сценарий и ожидания; фазы; действия, мысли и эмоции — «в идеале дословные цитаты из исследования»; возможности с владельцем и метрикой. Service blueprint — «вторая часть» карты: действия клиента, видимая сцена, закулисье, процессы, линии взаимодействия, видимости и внутреннего взаимодействия.

Метод собран из трёх проверенных кусков. Ник Тьюн давал Claude Code читать OpenAPI, методы сущностей и события между репозиториями. На выходе он получал папку на каждый поток с README и Mermaid-диаграммой, где каждый поток начинается с действия в интерфейсе и его URL. Скилл code-to-prd инвентаризирует маршруты, guards, вызовы API и мок-данные, всё неясное помечает [TBC] и запрещает «придумывать бизнес-смысл». Аналитика даёт третий кусок. GA4 Path exploration строит пути из событий от стартовой точки, Mixpanel Flows даёт топ-пути и отвал по шагам. Amplitude Journeys сравнивает задуманную воронку с реальными путями.

Итог такой: колонки «фазы» и «действия» заполняются с источником, то есть с файлом или строкой аналитики, а колонки «мысли» и «эмоции» остаются пустыми с пометкой «нужен рисерч». Отвал в 40% — это число из аналитики; что при этом чувствовал пользователь, из него не следует. Воронку по шагам удобно отдать на график тем же кодом, что в теме «Рисерч по открытым источникам»: Apache ECharts умеет рисовать воронки, Chart.js — столбцы по шагам.

«Сплит» — вымышленное приложение из темы «Процесс с ИИ: Double Diamond и Design Sprint». Из шести интервью темы «Синтез интервью и качественных данных» первый промпт ниже вернул формулировку работы: «рассчитаться с друзьями за общие траты после поездки». Слов-решений нет, и так могли бы сказать и пятьдесят лет назад. Желаемые результаты: «минимизировать время на внесение одной траты» [P1, 44], «минимизировать число споров о том, кто за что платил» [P3, 12], «минимизировать неловкость при напоминании о долге» [P5, 83]. Таблица сил для P3 (пример условный):

Для as-is journey третий промпт прошёл по репозиторию «Сплита» и CSV из аналитики за 30 дней:

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

UXPressia собирает карту по описанию кейса и может опираться на загруженные транскрипты с трассировкой к документу. Smaply пишет, что «ИИ-подсказки — отправная точка, не готовый продукт». FigJam AI сортирует и суммирует стикеры.

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

ИИ вредит в четырёх случаях. Формулировка работы содержит решение («сканировать чек»). Важность и удовлетворённость результатов выведены из текстов отзывов, а не из опроса. Эмоции в journey map дорисованы из цифр отвала. Карта от генератора принята как находка.

Шаг с самым большим отвалом — это то, что в теме «UX-аудит продукта по ссылке или репозиторию» пойдёт на аудит первым.

Из этих расшифровок switch-интервью (P1…PN, строки пронумерованы) извлеки: 1. Основную работу в формате "глагол + объект + уточнение контекста", без слов-решений; проверь тестом "сказали бы так 50 лет назад?". 2. От 5 до 15 желаемых результатов в формате "направление + метрика + объект + уточнение" (например "минимизировать время на…"), каждый с [P#, строка]. 3. Job stories "Когда [ситуация], я хочу [мотивация], чтобы [результат]" — по одной на каждую найденную ситуацию. 4. Таблицу сил по каждому участнику: толчок / притяжение / тревога / привычка, в каждой ячейке дословная цитата или "не упомянуто". 5. Таймлайн: первая мысль → пассивный поиск → активный поиск → решение → онбординг, с датами или триггерами из цитат. Всё, что вывел без цитаты, помечай ВЫВЕДЕНО

Вход: CSV с колонками id, дата, текст, раздел продукта. Шаг 1: пометь каждую строку как пригодную для выявления потребностей или нет (баг, похвала, спам). Шаг 2: для пригодных строк напиши по одной формулировке потребности на каждую отдельную потребность: "направление + метрика + объект + уточнение", без решений. Шаг 3: сгруппируй потребности; для каждой группы — число строк, три id с дословными фрагментами, шаг карты работы (определить / найти / подготовить / подтвердить / выполнить / отслеживать / скорректировать / завершить). Шаг 4: перечисли потребности, которые ты ожидал в этой категории, но НЕ нашёл, с пометкой "нет в данных". Важность и удовлетворённость не оценивай — для этого нужен опрос

У тебя доступ к репозиторию и CSV из аналитики за 30 дней: название события, уникальные пользователи, медианное время до следующего события, доля отвала. 1. Инвентаризируй точки входа: маршруты и экраны (путь к файлу + URL), действие пользователя, которое их запускает, и событие аналитики из кода (точное имя). Маршруты без события помечай БЕЗ ИНСТРУМЕНТИРОВАНИЯ. 2. Собери as-is journey для сценария [X]: фазы → действия. Строка действия: экран | маршрут | событие | пользователи дошли | отвал до следующего шага | источник (путь к файлу или строка аналитики). 3. Там, где аналитика показывает пути, не задуманные кодом (петли, возвраты, брошенные ветки), перечисли их как "наблюдаемые отклонения". 4. Строки "Мысли" и "Эмоции" оставь пустыми с пометкой "нужен рисерч". Чувства из цифр отвала не выводи. 5. Нарисуй воронку по шагам кодом на Apache ECharts или Chart.js в отдельном HTML-файле, с подписью источника данных. Всё, что не привязано к файлу или строке аналитики, помечай [TBC]. Код проекта не меняй

Проверь эту journey map. Для каждой ячейки в строках "Действия", "Мысли", "Эмоции" и "Возможности" определи тип доказательства: ЦИТАТА (с id участника), АНАЛИТИКА (событие + число), НАБЛЮДЕНИЕ (заметка с юзабилити-теста) или НЕТ. Выдай: а) таблицу покрытия доказательствами по фазам; б) список ячеек НЕТ, к каждой — самый дешёвый способ заполнить: запрос в аналитику, три интервью, одно задание в тесте, дневниковая запись; в) точки кривой эмоций, под которыми нет цитаты или наблюдения; г) возможности, чья боль нигде выше не доказана. Карту не переписывай