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

Карта пути — не выдуманная история о чувствах «типичного клиента». GOV.UK рассматривает карту опыта (experience map) как визуализацию результатов исследований и рекомендует понимать всю задачу пользователя от начала до конца, а не только собственный сервис.［1］［2］ ИИ может ускорить синтез, но не может заменить доказательства. Для начала полезны общее руководство по работе с ИИ и материал о том, как безопасно проводить исследования с ИИ.

Ключевые выводы

Описывайте определенный текущий путь, а не воображаемого универсального клиента.

Регистрируйте источник, дату, группу и ограничения до синтеза.

Разделяйте наблюдения, цитаты, интерпретации и неизвестное.

Просите у ИИ черновую организацию материала, но никогда — выдуманные цитаты или эмоции.

Сохраняйте ответвления и противоречивые свидетельства.

Назначьте владельца версии, дату проверки и условия обновления.

Шаг 1: Ограничьте путь и группу пользователей

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

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

Запишите и исключения. Карта может не включать привлечение клиента до создания учетной записи, но эта граница должна быть видна. Здесь полезен подход GOV.UK к задаче пользователя целиком: интерфейс вашей организации может быть лишь небольшой частью реальной задачи пользователя.［2］ Если карта не может охватить всю задачу, отметьте внешние зависимости до и после вашего участка, которые все равно влияют на опыт.

Шаг 2: Создайте реестр доказательств до запроса к ИИ

Создайте реестр, который делает каждый входной материал прослеживаемым:

ID	Источник и локатор	Дата	Группа	Наблюдение или цитата	Тип	Ограничение	Разрешено для ИИ
E-001	Интервью 07, 18:30	2026-07-10	Новый покупатель	`[проверенный текст]`	Исследование	Один участник	Да, обезличено

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

GOV.UK советует анализировать сессию вскоре после её проведения и вовлекать команду.［3］ Не передавайте модели архив неразмеченных расшифровок и не считайте ее сводку записью исследования. Сначала решите, какие доказательства входят в охват, кто может их использовать и давали ли участники согласие на соответствующую обработку.

Шаг 3: Проведите контролируемое кодирование

Попросите ИИ кодировать только предоставленные ID доказательств. Задайте небольшой словарь: кандидат этапа, действие, точка контакта, цель, потребность, затруднение, обходной путь, результат, ветка, противоречие и неизвестное. Требуйте результат в виде таблицы с ID доказательств и кратким обоснованием.

Безопасный запрос:

Используя только приложенный реестр доказательств, предложи коды для каждого ID доказательства. Сохраняй прямые цитаты в точности. Не делай выводов об эмоциях, мотивации, демографии или событиях. Неподтвержденные толкования помещай в таблицу неизвестного. Верни ID доказательства, предложенный код, обоснование и уверенность для проверки человеком.

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

Шаг 4: Выделите этапы и точки контакта по данным, чтобы создать карту пути клиента с помощью ИИ

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

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

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

Шаг 5: Добавьте потребности, затруднения, ветки и неизвестное

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

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

Создайте отдельный реестр неизвестного:

ID неизвестного	Недостающие или противоречивые данные	Почему это важно	Следующее исследование	Владелец	Срок
U-01	Нет данных после неудачной проверки личности	Восстановление может быть отдельной веткой	Наблюдать пять сеансов восстановления	Руководитель исследования	`[дата]`

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

Шаг 6: Проверьте карту с исследователями и владельцами сервиса

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

Пригласите людей, которые разбираются в качестве исследований, операциях, политике, доступности и границах соответствующего сервиса. Их роли различаются: исследователь подтверждает толкование; операционный владелец проверяет, существует ли процесс; специалист по доступности указывает на недостающие маршруты; владелец решения утверждает назначение карты. Утверждение не делает слабые доказательства сильными, поэтому сохраняйте поля уверенности и ограничений.

Профиль NIST по генеративному ИИ подчеркивает риски, включая конфабуляции, приватность, целостность информации и человеческий надзор.［4］ Применяйте эти меры: сохраняйте версии запросов и результатов, ограничивайте данные, ведите журнал существенных правок и назовите человека, ответственного за итоговую карту.

Шаг 7: Публикуйте карту вместе с доказательствами

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

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

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

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

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

Шаг 8: Определите обновления и владельца версии

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

Журнал изменений хранит версию, дату, затронутые ID карты, новые и выведенные данные, причину, проверяющего и утверждение. Не генерируйте всю карту заново из нового набора материалов, теряя историю изменений. Процесс ИИ с человеческим утверждением делает границу проверки явной.

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

Часто задаваемые вопросы (FAQ)

Может ли ИИ построить карту по расшифровкам интервью?

Он может предложить коды и структуру из разрешённых обезличенных материалов, но исследователь обязан сверить цитаты, интерпретации и пропущенные пути.

Сколько исследований нужно до построения карты?

Универсального числа нет. Показывайте лишь то, что подтверждают данные, описывайте ограничения, а остальное храните как неизвестное.

Нужно ли добавлять эмоции?

Только когда участники сообщили о них прямо или метод исследования надёжно их зафиксировал. Не выводите эмоции из кликов или пауз.

Можно ли объединить аналитику, интервью и обращения?

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

Чем текущая карта отличается от будущей?

Текущая описывает подтверждённый опыт сейчас. Будущая показывает предложение и маркирует предположения, зависимости и проверки.

Что делать с противоречивыми результатами?

Сохранить обе версии вместе с группами, датами и контекстом, создав ветку или исследовательский вопрос, а не поручая ИИ выбрать одну.

Кто утверждает итоговую карту?

Как минимум владелец исследования и ответственный за решение; при необходимости добавляются владельцы операций, политики, доступности или права.

Как часто должна обновляться карта клиентского пути?

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

Источники

GOV.UK Service Manual, Creating an experience map — https://www.gov.uk/service-manual/user-research/creating-an-experience-map
GOV.UK Service Manual, Map a user’s whole problem — https://www.gov.uk/service-manual/design/map-a-users-whole-problem
GOV.UK Service Manual, Analyse a research session — https://www.gov.uk/service-manual/user-research/analyse-a-research-session
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

Sources checked 30 августа 2026 г.

Как создать карту пути клиента с помощью ИИ