Илона Саркисова написала первую статью из серии о Customer journey map.

— В 1998 году в IDEO по заказу Amtrak пытались понять, как повысить привлекательность поездок по железным дорогам. Возможно, это первое использование термина;
— CJM рассматривает человека как клиента компании и показывает, как тот узнаёт о сервисе, решает им воспользоваться, пользуется, а затем остаётся лояльным (жизненный цикл взаимодействия). Изучение пользовательского интерфейса здесь отходит на второй план;
— Подходит для анализа существующего сервиса и планирования нового;
— Нет смысла строить CJM, если а) человек ничего не покупает и нет взаимодействия по оказанию услуги, б) вы хотите проиллюстрировать только работу пользователя с интерфейсом;
— При построении CJM сначала надо понять, какие у сервиса есть (или должны быть) клиенты и описать персоны. Если их несколько, будет несколько CJM;
— Далее надо выписать точки взаимодействия и проблемы в каждой точке. В CJM можно включать любые элементы, которые помогут в проектировании сервиса;
— Например, можно выделить моменты истины — взаимодействия, в ходе которых клиенты решают, воспользуются они сервисом или нет;
— Также можно зафиксировать поставщиков услуг (кто оказывает сервис и несёт ответственность), эмоции (что клиенты чувствуют в каждой из точек взаимодействия), возможности (как можно улучшить взаимодействие) и так далее;
— CJM помогает увидеть сервис с высоты птичьего полёта, найти способы улучшить обслуживание и придумать новые услуги. Это инструмент на грани продуктового Customer Experience и маркетинга.

#cjm

Илона Саркисова написала, как применять Customer journey map для проектирования нового сервиса.

— Здесь обычный процесс (анализ клиента → анализ существующего пути → поиск проблем → улучшение) не работает, но можно создать идеальный путь с нуля;
— Начать надо с изучения предметной области: почитать о подобных сервисах в открытых источниках, посмотреть конкурентов и отзывы на них, выписать, что людям нравится и не нравится;
— Кроме интерфейса смотрите на сервис в целом;
— Затем надо выявить потребности бизнеса, технические и другие ограничения, как заказчик представляет работу сервиса. Это можно сделать на встрече с заказчиком;
— Следующий шаг — создание протоперсоны, описания целевой аудитории, основанного на предположениях команды. Так можно сэкономить на исследованиях, но создавать её надо именно командой;
— Валидировать её исследованиями можно на любом последующем этапе;
— Затем надо провести командный CJM-воркшоп, желательно с привлечением представителей целевой аудитории и тех, кто будет отвечать за сервис на разных этапах (от маркетинга до поддержки). Лучше всего работают группы от 5 до 12 человек;
— Задачи воркшопа: а) Спроектировать клиентский путь; б) Найти возможные проблемы и перспективы для развития; в) Придумать, как улучшить взаимодействие;
— Важно разделять, какие элементы CJM основываются на фактах, а какие — на фантазиях, а в конце воркшопа — валидировать CJM по персоне.

Заметка о трёх типах персон. #cjm

Андрей Шапиро написал о схематизации опыта с помощью CJM, Service Blueprint и собственной гибридной нотации.

— Строгой нотации CJM нет. Из-за этого её труднее использовать для синхронизации работы людей с разным уровнем подготовки. Зато инструмент пластичен: карту можно организовать так, как того требует ситуация;
— CJM рассматривает точки контакта (взаимодействия) человека и проектируемой или анализируемой системы;
— Важно различать точки контакта и каналы. Каналы — средства, через которые происходит взаимодействие. Например, «Подтверждение брони» (точка контакта) может происходить в интерфейсе приложения и в электронной почте. Каналы стоит отражать в CJM только если одно и то же взаимодействие возможно в нескольких каналах;
— Информационные слои CJM могут быть любыми. Чаще всего Андрей анализирует в точках контакта действия, возникающие артефакты, барьеры, инсайты действующего лица;
— В табличных CJM каждая строка — информационный слой. Такие CJM можно вести хоть в Гугл Таблицах, за счёт чёткой структуры их легко заполнять на воркшопах, но в них сложно показывать нелинейные сценарии;
— В проволочных CJM точки контакта соединены линиями, удобно показывать ветвления сценария взаимодействия, а информационные слои размещены в виде текстовых блоков рядом с точками контакта;
— С помощью Service Blueprint показывают взаимодействие нескольких действующих лиц и участвующих сервисов;
— На одном уровне показывают видимые клиенту взаимодействия (например: заказ, выдача товара), на другой — скрытые, но участвующие в оказании услуги (комплектация заказа). Дополнительные уровни: артефакты, действия клиента, вспомогательные процессы;
— CJM и SB делят действия одного или нескольких лиц на шаги и привязывают к этим шагам какие-то наборы данных. В CJM шаги отражают путь конкретного героя (клиента). SB охватывает весь процесс формирования ценности для клиента.

#cjm #sb

Влад Шиляев написал о синхронизации команды с помощью CJM.

— CJM может быть любой, её структура зависит от того, какую задачу вы решаете;
— Проблема постоянно развивающегося большого (когда разные команды дорабатывают разные части) продукта в том, что у отдельных специалистов (особенно тех, кто не связан с разработкой) нет полного понимания пользовательского пути;
— Иногда нельзя просто взять и пройти путь пользователя, чтобы это понимание получить (а если можно, это требует времени): ограничения разных типов клиентов могут влиять на флоу, не все сценарии могут быть доступны сразу, в них могут быть развилки, в которые за один подход не попасть;
— Стейдж — среда тестирования, которая точно повторяет прод и позволяет создавать тестовых пользователей. В идеале проходить сценарии на реальных устройствах, а не в Xcode или Android Studio;
— Описание всего пути от начала до выполнения поставленной цели позволяет увидеть общую картину и конкретные интерфейсы, найти слабые места и ошибки флоу, сгенерировать новые идеи;
— Структура: цели, шаги и действия пользователя, мобильный флоу (скриншоты интерфейса, по сути Screen flow), десктопный флоу, боли и барьеры, позитивные моменты, идеи по улучшению, отслеживаемые метрики;
— Дополнительно такая карта сокращает обращения к дизайнерам за нужными флоу (можно добавить ссылки на макеты), помогает найти нестыковки между макетами и продом и запланировать их исправление, а также адаптировать новых сотрудников;
— Стоит добавить оглавление с типами пользователей, рассмотренными сценариями, ответственными (к кому обращаться с вопросами и проблемами), а также логи обновлений, чтобы была ясна актуальность карты;
— Так как за стрелками следить сложно (и иногда их бывает слишком много), удобно вставлять блоки с развилками — описанием путей, по которым может пойти сценарий и якорными ссылками на соответствующие участки карты;
— Карта быстро устаревает, если её не обновлять. Обновление карты надо делать частью процесса разработки, выделять на это время в спринте.

#cjm

Вадим Митякин и Андрей Шапиро обсудили CJM и Карту процесса-опыта.

— В CJM представляют линейный путь пользователя, который решает какую-то задачу, разложенный на ключевые точки, где с потребителем происходит что-то важное;
— Даже если в этих точках мы, как создатели продукта, во взаимодействии не участвуем;
— Цель — понять, как создать для пользователя ценность, помочь ему с решением задачи на том или ином шаге с помощью функций нашей системы;
— Функции CJM: фиксация, формирование единого понимания участниками процесса, включение новых участников, управление процессом изменения;
— Нет какой-то единой или классической нотации CJM;
— Нотация BPMN фиксирует процессы. Люди там тоже есть, но они на периферии;
— CJM нужен, чтобы попасть в шкуру пользователя, что-то понять и перейти к созданию какого-то конкретного решения для определённой ключевой точки. Поэтому CJM часто остаются пылиться после создания;
— Карта процесса-опыта — результат эволюции гибридной нотации CJM и Service blueprint;
— Она позволяет соединить опыт потребителя (или других участников взаимодействия) с обеспечивающими этот опыт процессами;
— В отличие от CJM у неё есть конкретная нотация. В отличие от BPMN, нотация простая, с минимумом элементов, не требующая специальных знаний, чтобы её читать;
— Также в отличие от BPMN она учитывает, что это не программы, а живые люди, которые не всегда обязаны двигаться по процессу. Потребитель может просто уйти;
— Но если вы пришли на проект, где все говорят на языке BPMN, возможно, не стоит этого менять и лучше подстроиться;
— Карта процесса-опыта соединяет машины и людей, показывает связь бизнес-модели и инструментов, задействованных в ней.

Копия видео в ВК. #cjm #sb