Схематизация опыта с CJM и Service Blueprint. Практика гибридной нотации

Продолжим разбирать инструменты проектирования цифровых сервисов. Начали мы с написания пользовательских историй и выстраивания их в карту USM. Это уровень детализированных требований к продукту. Глубже по детализации только подробные сценарии использования — формат проектной документации, в котором участники команды утрясают самые мелкие детали реализации. Мы же перейдём к более широкой картине, которую дают методы схематизации опыта. Речь пойдёт о схемах типа Customer Journey Map (CJM) и Service Blueprint, но в большей степени об авторском опыте схематизации опыта.

Одним из переводов Customer Journey Map может быть такой — карта путешествия потребителя. Схема используется, когда важно

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

Такая карта-схема всегда ориентирована по горизонтали слева направо во времени: от более ранних событий к более поздним. То есть, по форме является временной развёрткой (timeline) с важными отметками о человеческом опыте. Строится для конкретного человека, описывающего свои переживания, либо для группы людей, отобранных по определённому критерию, например, функциональной роли. По вертикали располагают слои информации, которые планируют соотнести с каждым из ключевых моментов в карте. Из-за разных целей построения карты состав слоёв сильно варьируется, и мы об этом поговорим подробнее ниже.

Строгой стандартизированной нотации CJM не существует. Поискав «CJM examples» в Гугль-картинках, найдёте обилие примеров, отличающихся по форме и структуре. В этом и боль, и прелесть подхода. Боль в том, что, чем вольнее ваша нотация, тем труднее будет использовать карту как boundary object — средство для синхронизации работы групп людей с разным уровнем подготовки. Отсутствие контроля над структурой схемы, такие, например, ошибки как путание точек контакта и каналов, бессистемный подход к выбору степени детализации — всё это способно превратить карту из чёткой схемы в неразбериху. Прелесть же в том, что отсутствие жёсткой нотации даёт пластичный инструмент. С таким крайне легко «метафорически прыгать» с одного уровня абстракции на другой. Вы вольны организовать карту как вам покажется подходящим для ситуации, а значит обнаружите некоторую подвижность ума при работе с ней.

Что будет общего для любой карты CJM:

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

Понятие точки контакта или точки соприкосновения произошло из маркетинга услуг. В классике — это места, где компания входит в контакт c потребителем. Примерами классических точек контакта в маркетинге будут визитная карточка, презентация, посадочная страница веб-сайта компании, секретарь, здание и офис, звонок в службу поддержки.

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

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

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

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

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

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

Точки контакта легко спутать с каналами. Например, получение электронного письма с подтверждением регистрации — это точка контакта или канал электронной почты в точке «Вы зарегистрированы!»? Чтобы меньше путаться, вводите разные каналы только тогда, когда одно и то же сценарное взаимодействие может произойти в нескольких каналах.

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

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

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

Ниже приведён перечень слоёв с данным, которые были наиболее полезны в опыте картирования автора. К более обширному перечню данных можно обратить в работа Джеймса Калбаха (2016, С. 24).

Преимущества табличного формата таковы. Обилие слоёв для анализа, под которые сразу отведено место, чёткая структура. Таблицу легко организовать практически в любом электронном инструменте. В прямоугольную матрицу легко ориентировать стикеры, что и делают часто на очных воркшопах по CJM.

Очевидным минусом карты является сам же формат. Таблица — жёсткая структура, и в ней трудно организовать ветвление, без которого сложные взаимодействия трудно раскрыть в полной детализации.

В «проволочном» формате карта состоит буквально из точек, соединенных ломанной линией. Здесь точки контакта отображены как точки с подписями их названий. По форме карта может быть как длинной вытянутой «гусеницей» — абсолютно прямая история без развилок и сходов с дистанции. А может быть и разветвлённой сетью дорожек даже в случае, когда описывается опыт единственного человека. На такой карте легко применять стрелки для показа переходов из одних точек контакта в другие, что решает вопрос с ветвлениями.

Информационные слои размещаются текстовыми блоками под точками контакта. При этом приводятся не все-все слои, а только те, данные в которых важны и представлены.

Автор особенно любит «проволочный» формат за его гибкость и пластичность. Его легко рисовать как на бумаге или доске, так и в программах для схем. Во второй части статьи приведены примеры таких схем и авторская нотация.

Буквальный перевод названия — «чертёж сервиса». В схемах этого типа разворачивается не только опыт одного действующего лица, но и действия других лиц, а также службы, этот опыт обеспечивающие и создающие. Так что схема действительно становится конструкционным чертёжом имеющегося или будущего сервиса.

Проектирование услуги и термин «сервис-дизайн» вводит в 1982 Линн Шостак, она же предлагает первый вариант схемы Service Blueprint. В ней на двух этажах или «плавательных дорожках», одна над другой, размещаются все действия потребителя и взаимодействия между потребителем и тем, кто оказывает услугу. Верхний этаж содержит действия, которые потребитель видит, нижний — то, что от него скрыто, но участвует в оказании услуги.

Битнер, Остром и Морган (2008) расширяют схему и вводят, кроме этих двух уровней повествования, дополнительные три: вещественные артефакты, действия потребителя и вспомогательные процессы, разделяя не только сцену и закулисье, но и то, что находится по обе стороны внешних и внутрених (по отношению к потребителю) взаимодействий.

Схему-пример для услуги паркинга с тремя стейколдерами: владельцами паркинга, оператора и автомобилистами приводят Врейнер и другие (2009).

Интересно, что в варианте схемы выше применена 24-часовая перспектива развёртки сервиса. Для примера взяты несколько водителей с разными вариантами сценариев. Например, есть сценарий неуплаты. Это решает проблему с отсутствием ветвлений в схемах табличного/матричного типа, указанную выше.

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

Вариативность исполнения схем CJM огромна при сохранении общих принципов. Общие принципы при этом, на взгляд автора, таковы:

Различие форматов Customer Journey и Service Blueprint в акцентах и методе разворачивания построения. В первом есть главный путь героя, герой один, и карта строится вдоль линии движения его внимания. В Service Blueprint чаще всего схема строится вдоль линии создания и поставки ценности к конечному потребителю, и деятели подключаются по необходимости в порядке этого движения.

Мнение о том, что для описаний требований к техническим системам лучше подходит формализированный язык, выглядит устойчивым паттерном. Так, Коберн (2000) и Ковчий (2018) пришли к той же мысли, что и автор: специализированный, более строгий, язык лучше подходит к описания систем, чем естественный.

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

Хотя автор предпочитает большую строгость в нотации, важно провести разграничение между тем, в чём следует соблюдать строгость, а в чём нет. Так как CJM — это схема, то есть знаковое пространство для размышлений, важно придерживаться условности, сохраняющих её структуру. Например, ошибкой будет назначать точками контакта то действия, то места, где эти действия происходят. Ошибкой будет спутать плавательную дорожку, где находится точка контакта, или путать каналы и точки контакта. Под ошибкой имеется в виду неточность, неминуемо приводящую к ошибкам в размышлении над поведением при анализе карты. При подобных неточностях схема всё меньше будет отражать реальность, а значит будет терять точность как модель. При этом, если вам захочется приписать что-то в любом месте карты, создать стрелочками дополнительные поясняющие подробности — всё это поощряется, лишь бы все в команде понимали, что означает тот или иной способ обозначения — а это, при отсутствии строгости нотации, достигается лишь практикой совместной работы над схемой, что может быть непозволительной роскошью.

Мы в Byndyusoft выработали постепенно собственную нотацию. Наш стиль карты можно считать гибридным между классическим CJM и Service Blueprint с редкими вкраплениями элементов BPMN. Нотация довольно проста, вот бегло основные элементы.

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

Горизонтальные сплошные линия соединяют точки контакта в единое путешествие.

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

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

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

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

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

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

Примеры хорошо названных точек контакта:

Хорошо выявленная точка контакта легко может стать мульти-канальной. Например, действия в точке «Регистрация права собственности» могут происходить и в физическом пространстве МФЦ, и в виртуальном: информация о результате может быть отправлена в СМС и по электронной почте.

Вот менее удачно выявленные точки контакта:

Опыт показывает, что полезна нумерация рядом с именами точек контакта. Это становится бесценным в больших системах и долгих проектах. Вместо произнесения долгих названий удобно оперировать номерами. Номер записывается в конце текста наименования точки, чтобы не мешать чтению. Удобно вести двузначную нумерацию: 5.11 — означает 11-ю точку на 5-м этапе.

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

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

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

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

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

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

Порой у вас ещё нет никаких информации о поведении пользователей будущей системы. Как и нет самой системы — перед вами только её схема в перспективе «как будет». Здесь размышление над возможными будущими барьерами приобретает форму мысленного эксперимента. Во время рассматривания точки вы выдвигаете и фиксируете гипотезы о возможных затруднениях. Здесь важно не растерять время в бесполезных фантазиях, ограничившись выявлением наиболее вероятных проблемных мест. В этом помогут методы управления рисками из книги «Вальсируя с медведями» (2005).

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

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

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

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

Принцип «фрактальности». Почти каждая точка контакта может быть детализирована как более подробный CJM. Веб-сайт может быть всего лишь точкой контакта, а может быть отдельной картой CJM, если вы углубитесь, как бы «нырнув» в эту точку. В примере ниже расписана точка контакта «Авторизация». Это целый детальный CJM. Однако при изучении системы в другом контексте вам могут не понадобиться эти подробности, и вся эта часть карты может быть легко схлопнута в одну точку.

Ветвление через шлюзы BPMN. Если вам нужна развилка на карте, то полезно использовать шлюз «ИЛИ» (выбор одного варианта из двух альтернатив) и параллельный шлюз (расщепление потока на несколько дорожек одновременно) из нотации BPMN. Ниже показан пример использования шлюза «ИЛИ» для организации разветвления на карте. Около значка шлюза (ромбик с крестиком означает шлюз «ИЛИ») пишут ключевой вопрос, отписывающий развилку, на выходящих ветвей пишут — условия выхода.

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

Итак, мы поговорили о ключевых форматах схематизации опыта и формате-гибриде. Рассмотрели кусочки схем на примерах. Обратите внимание, большинство приведенных выше схем взяты из реальных продуктов, поэтому именно в изучении деталей этих схем прячутся самые интересных находки.

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

Буду рад вашим вопросам и предложениям по развитию метода, пишите, и хорошей вам практики.

Автор благодарен за вклад в общее исследование всем, кто работает с ним бок о бок над созданием опыта в Byndyusoft. Отдельное спасибо Иделю Гизатуллину — за интервью и рукописи процесса аналитики в процессе его собственного изучения вопроса, Владимиру Аршукову — за рвение делать ошибки, Антону Григорьеву — за помощь в редактуре и комментарии.