Customer Journey Map — часть 3
В прошлых статьях серии мы выяснили, что при помощи CJM можно описать впечатления, эмоции и процесс взаимодействия покупателя с существующим сервисом.
Также мы разобрали как использовать CJM для сервиса, который еще не существует и направить проект на путь и̶с̶т̶и̶н̶н̶ы̶й̶, где покупателя ждет кайф и желание вернуться.
Это — заключительная статья, в которой я расскажу что делать, если ваш пользователь не является покупателем и какие есть альтернативы CJM.
Больше о проектировании интерфейсов и мемы по средам — в моем телеграм-канале Поясни за UX
Мы уже знаем, что Customer Journey Map описывает путь ̶п̶о̶л̶ь̶з̶о̶в̶а̶т̶е̶л̶е̶й̶ покупателей (слово “customer” в названии как бы намекает). Это, как правило, истории про e-commerce и прочий B2C (business to client), где пользователем является человек, готовый платить деньги за услуги.
Но что же про другие виды пользователей, например сотрудников организации? Они ничего не покупают, им не нужно узнавать о сервисе, ведь его использование “навязано” работодателем.
Здесь я хочу сделать важное отступление.
💡 Те, кто воспринимает Customer Journey Map как самостоятельный фреймворк для работы, попадают в ловушку туннельного зрения.
По сути, техника CJM является лишь одним из представителей большого вида активностей под названием Mapping — создание карт.
Карты служат единственной цели — помочь команде понять опыт пользователя.
Чтобы понять опыт нужно создать модель, визуализирующую его под правильным углом.
И если CJM хорошо визуализирует опыт покупателя, то для сотрудников организации в ее “классическом” представлении она не подходит.
Опыт сотрудников
Поразительно как мало некоторые компании знают о людях, которые пользуются их интерфейсами. И если в сфере B2C над этим хотя бы задумываются, то в B2B царит проектирование “изнутри наружу”.
Вы наверняка сталкивались с таким явлением и сами, если работали над дизайном для внутреннего инструмента компании. Заказчик наверняка детально рассказывал вам, что должно быть в интерфейсе и как он должен выглядеть, аргументируя это тем, что он является представителем пользователей. Это особенно часто случается при создании интерфейсов для подчиненных заказчика или тех, с чьими задачами он знаком.
Проектированиие “изнутри наружу” провоцирует создание интерфейсов, сценарий работы в котором не совпадает с тем, который ожидает пользователь. Такой интерфейс часто не помогает, а иногда даже мешает выполнять рабочие задачи.
💡 Создание карт позволяет “перенастроить” мышление заказчика и команды из “изнутри наружу” в “снаружи внутрь” благодаря активации эмпатии. При чем эмпатию вызывают не столько сами карты, сколько процесс их создания, во время которого возникает диалог.
Вернемся к CJM. Если это не единственный вид карт, который нам доступен, то что еще мы можем создать?
Секрет тут очень простой — мы можем создать что угодно. Можем сделать любую карту, наполнив ее информацией, важной для визуализации опыта конкретных пользователей.
Далее я опишу общий процесс создания карт и приведу несколько самых популярных видов, помимо CJM.
Как составлять карты
Если вы решили, что вашему проекту требуется карта, следует начать с формулировки того, для чего она и что она будет иллюстрировать.
Необходимо ответить на 3 вопроса
- Кто: чей опыт мы будем наносить на карту?
- Когда: когда начинается и заканчивается этот опыт?
- Что: какая информация важна и что стоит отобразить?
Кто
В случае B2C чаще всего очевидно, чей опыт необходимо визуализировать. Например, при проектировании музыкального сервиса с подпиской, понятно, что нужно визуализировать опыт человека, который хочет слушать любимую музыку.
Но, когда мы говорим про B2B, нередко возникает вопрос: на ком фокусироваться? Ведь в процесс может быть вовлечена куча ролей, действия и решения которых взаимозависимы. Вы можете выбрать одного или нескольких персонажей для визуализации их взаимодействий.
💡 Совет: помните, что чем больше персонажей, тем сложнее будет карта и тем меньше у вас возможностей отобразить на ней важные детали.
Когда
У любого процесса есть начало и конец. Но порой их действительно сложно определить.
Например, процесс катания на американских горках: где он начинается — с момента, когда вы сели в кабинку? Или когда покупали билеты? А когда он заканчивается — после катания? Или дома, когда вы выкладываете фотки в соцсети? И надо ли прибавить к этому обсуждения с друзьями спустя месяц?
Именно вы, как создатель карты, должны определить ее этапы. Здесь нет правильного ответа: все зависит от нужд проекта.
💡 Совет: найдите самую очевидную точку во времени и сделайте от нее шаг назад, чтобы проверить, нет ли там важных шагов. Проверните аналогичную манипуляцию с финальной точкой — определите очевидную и сделайте еще шаг вперед для проверки.
Что
Представьте себе CJM. На нем обязательно есть горизонтальные “слои” информации: точки соприкосновения, моменты истины, эмоции…
Опять же, именно вы, исходя из целей проекта, должны определить, какие слои необходимо вынести на карту для визуализации и понимания опыта вашего пользователя.
Вот несколько типичных слоев для описания пользователя:
- поведение (действия, задачи, шаги)
- контекст (условия, среда, место)
- потребности (цели, желания)
- события (моменты истины, точки контакта, внешние действия)
- физические средства (девайсы, инструменты, артефакты, другие сервисы)
- культура (ценности, философия, убеждения)
- мысли (мнения, точки зрения)
- эмоции (чувства, настроение)
- проблемы (ограничения, страхи, боли)
Если вы захотите включить в карту описание организации, то вот типовые слои для этого:
- предложения (продукты, услуги, сервисы)
- процессы (внутренняя деятельность, рабочие потоки)
- вызовы (проблемы, разногласия, ошибки)
- структура (роли, отделы)
- показатели (финансы, статистика)
- цели (доходы, сбережения, репутация)
- стратегия (политика, принципы)
💡 Совет: не пытайтесь ввернуть в карту все слои. Выберите релевантные вашей цели.
Хорошая аналогия: географическая карта или карта метро. Они всегда содержат упущения (на карте мира могут быть отображены только страны и столицы) или искажения (на карте метро линии нарисованы прямо, хотя в реальности они не такие). Именно эти упущения и искажения помогают сфокусироваться на главном.
К примеру, CJM фокусируется на описании опыта покупателя, поэтому описания организации в ней нет. А вот Service Blueprint уделяет больше внимания тому, как функционирует сервис “изнутри”, при этом не углубляясь в опыт покупателя.
Организация работы
Цель и содержимое карты определили — переходим к процессу составления. Он состоит из четырех этапов:
- Инициирование
- Исследование
- Визуализация
- Синхронизация
Инициирование
Главное — это не столько законченная карта, сколько процесс ее создания.
Джим Калбах, автор книги Mapping Experience, пишет:
Процесс создания карт несколько сместился от создания документа отчетности к созданию практического инструмента. Главным стал не итог, а путь к нему. Авторы карты превращаются в своего рода координаторов, а карта — в трамплин для коллективного осмысления пользовательского опыта.
Именно поэтому вам нужно правильно инициировать создание карты. Запереться в темной комнате на 2 недели, а после выйти с готовой картой не пойдет.
Нужно определить тех, кто будет строить карту вместе с вами. Это могут быть заказчики и владельцы продукта, лидеры групп или подразделений, лица принимающие решения, аналитики и дизайнеры, эксперты в предметной области, руководители разработки и даже сами пользователи.
А еще вам нужно “продать” заказчику и всем участникам эту активность. Люди обычно понимают ценность карт лишь после их создания (и только если они в это вовлечены). Постарайтесь донести ценность при помощи презентации, аргументов и примеров.
Спланируйте работу до, во время и после воркшопа. Воркшоп — это не презентация и не выступление. Это коллективная работа, в которой вы выступаете модератором.
Исследование
Без них любые ваши карты останутся личной или коллективной фантазией.
Если нужно, изучите имеющиеся источники, понаблюдайте за ЦА, проведите опросы или интервью, протестируйте текущий сервис. Соберите инсайты, будьте готовы представить их команде и использовать во время воркшопа.
Визуализация
Отображение большого объема информации так, чтобы его было легко понять и сделать выводы — это большая наука и даже искусство.
На этом этапе ваша задача — создать заготовку карты для командной работы. Изучите разные виды визуализации карт (некоторые рассмотрим ниже), подумайте о вашей цели, модернизируйте визуализацию в соответствии с ней.
Не сковывайте себя типовыми шаблонами, если нужно — смело меняйте и добавляйте. Ваша цель — создание инструмента для ведения диалога, после которого у команды появится единое представление об опыте пользователя.
Несколько базовых принципов:
- упрощайте — избегайте больших текстов, бессмысленного декора и визуального шума
- усиливайте — подчеркивайте то, что важно
- уточняйте — не оставляйте места двусмысленности в карте
- объединяйте — группируйте все, что связано по какому-либо критерию
Синхронизация
Пришло время коллективной работы над картой — проводим воркшоп. Синхронизация — ключевой этап, я назвала его так потому, что именно в этот момент команда синхронизирует свое представление о пользователе.
Соберите всех в одной комнате, виртуально или физически. Выделите достаточно времени для того, чтобы команда могла и поговорить и создать карту (обычно это полтора-три часа). Объясните цель мероприятия и ожидаемые итоги.
🎯Активация эмпатии — команда вспоминает, что она знает пользователе из исследований и наблюдений. Того, что вы лично сопереживаете пользователю, недостаточно. Важно, чтобы такие же чувства возникли у всех участников воркшопа.
🎯🎯 Представление вашей заготовки и объяснение хода работы. После этого начинается самая хаотичная и продуктивная фаза — заполнение карты. Ваша задача — контролировать и модерировать ход работы.
🎯🎯🎯 Обсуждение — проговорите вопросы, расставьте приоритеты, спланируйте дальнейшую работу.
🎯🎯🎯🎯 Пост-активности — соберите обратную связь от участников, приведите карту в порядок, разместите ее так, чтобы у всех к ней был доступ, пришлите письмо участникам с дальнейшими шагами.
Виды карт
Теперь, когда мы понимаем общий процесс подготовки и создания карт, самое время изучить некоторые их виды (помимо CJM). Этот список не претендует на звание исчерпывающего. И помните, что любую карту вы можете модифицировать в зависимости от потребностей проекта.
Service Blueprint
Этот вид карт является краеугольным камнем модного сегодня сервис-дизайна. Это, пожалуй, самый древний представитель карт опыта. Один из первых примеров встречается еще в статье Designing Services That Deliver (1984 г. sic!)
Что иллюстрирует
Связь действий “на сцене”, которые производит пользователь и “за сценой”, которые производит тот, кто предоставляет сервис.
Когда применять
Для диагностики и улучшения процессов предоставления сервиса пользователю/покупателю.
Основные элементы
- физические средства (девайсы, инструменты, артефакты, другие сервисы)
- поведение (действия, задачи, шаги)
- точки взаимодействия
- на сцене — действия со стороны сервиса, заметные пользователю
- за сценой — внутренние механизмы, незаметные пользователю, но влияющие на его опыт
- линия видимости — отделяет точки взаимодействия на сцене от тех, что за сценой
- вспомогательные процессы — дополнительные вещи, например действия партнеров сервиса, сторонних помощников
Плюсы
- простая карта с четкой структурой
- не требует сложных исследований, только наблюдения
- подходит для совместной работы
Минусы
- не учитывает влияние внешней среды и контекста на опыт пользователя
- не отражает эмоциональную и когнитивную составляющую опыта пользователей и сотрудников (но кто вам мешает их добавить, верно? 🙂)
Примеры
User Experience/Journey* Map
*практика показывает, что User Experience и User Journey Map можно считать синонимами. Для простоты я буду использовать название User Experience Map.
Если посмотреть на User Experience Map, так сразу и не поймешь, что это не CJM. Они очень похожи: та же структура, логика, визуализация. Именно поэтому их часто путают (если загуглить User Experience Map, в выдаче будет в основном CJM).
Но, в отличие от CJM, где этапы общеприняты и ведут к совершению покупки, User Experience Map — более гибкая. Она позволяет увидеть широкий контекст человеческой деятельности независимо от какого-то продукта или сервиса, и показать путь к любой цели пользователя, будь то выполнение рабочей задачи, прохождение какого-то жизненного процесса, например трудоустройства или ремонта квартиры.
Решение о покупке, вокруг которого строится CJM, не является ключевой частью User Experience Map, хоть и может на ней присутствовать.
Что иллюстрирует
Целостный процесс в рамках глобальной цели пользователя, выходящий за рамки решения о покупке. Может иллюстрировать карту опыта одного или нескольких пользователей.
Когда применять
Для анализа действий, мыслей и чувств пользователя в рамках любой цели (не только покупки, как в CJM).
Основные элементы
- этапы
- поведение (действия, задачи, шаги)
- мысли (мнения, точки зрения)
- эмоции (чувства, настроение)
- проблемы (ограничения, страхи, боли)
- физические средства (девайсы, инструменты, артефакты, другие сервисы)
Плюсы
- не ограничивается покупкой услуги, использованием сервиса
- очень гибкая: в зависимости от задачи можно отходить от структуры, менять элементы
- позволяет вызвать эмпатию и проектировать “снаружи внутрь”
- подходит для совместной работы
Минусы
- может оказаться слишком абстрактной для некоторых заказчиков и членов команды
- легко перегрузить и слишком сильно детализовать
Примеры
User Stories Map
User Stories Map — особенная в нашем списке. Особенность ее в том, что она не имеет такого прямого отношения к проектированию UX, как User Experience Map или Service Blueprint, но тоже может быть полезна проектировщику интерфейсов. Создавая и поддерживая User Stories Map, вы помогаете всей проектной команде удерживать полную картину продукта.
Большинство команд сегодня работают по Agile. Этот подход стремится разбить продукт на небольшие части (User Story) и “создавать слона по кусочкам”. Так проект может быстро реагировать на изменения требований и рынка, адаптировать решение и снижать риски.
User Stories пишутся в стандартном формате (это помогает команде быстро их читать и понимать):
Я, как <пользователь>, хочу <цель>, чтобы <польза>
💡 Обратите внимание: в формулировку истории не заложено решение, только потребность. Придумать решение должна команда.
С одной стороны, User Stories делают процесс разработки более управляемым за счет концентрации на небольшом куске системы. Но с другой, это вызывает “туннельное зрение” и команда нередко теряет из виду общую картину того, что она создает.
Именно это помогает излечить User Stories Map.
Кто пишет пользовательские истории
Отдельный вопрос — откуда берутся истории для маппинга. Эта тема заслуживает целой статьи, поэтому мы не будем углубляться. Скажу лишь, что дизайнеры тоже могут участвовать в процессе написания сторей, основываясь на исследованиях пользователей.
Что иллюстрирует
Как индивидуальные User Stories, сформулированные командой на основе известных задач и потребностей пользователей, связаны друг с другом в рамках продукта и глобальных целей пользователя.
Когда применять
Когда команда закапывается в деталях, теряя из вида общую картину решения, “зачем и почему”.
Когда необходимо отойти от формулировки списка еденичных “фич”, и увидеть как они связаны в единое решение.
Когда нужно приоретизировать и спланировать работу команды.
Основные элементы
- Epics (большой кусок работы, который имеет общую цель. Могут быть организованы по времени, аналогично этапам на CJM или логически)
- User Stories (меньшие куски работы, которые нужно выполнить чтобы закрыть Epic. Формулируются по специальному шаблону и фокусируются на потребности конкретной роли)
- Релизы (этапы во времени разработки, по которым разбиваются User Stories)
Плюсы
- синхронизирует процессы планирования и разработки с опытом пользователей
- позволяет сформировать общее видение продукта у команды, общий путь пользователя и то, в каком порядке команда будет разрабатывать его поэтапно
- легко читать и понимать
- подходит для совместной работы
Минусы
- необходимо поддерживать, обновлять и дополнять
- риск наплодить много сторей, в которых можно запутаться
- частично зависит от менеджером проекта/скрам-мастера
Примеры
Empathy Map
Empathy Map не похожа на карты, которые были представлены выше: она нелинейная, в ней отсутствует таймлайн.
Empathy Map это, скорее, “слепок” пользователя, агрегирующий информацию из пользовательских исследований.
💡 Empathy Map является основой для Персоны, но не всегда может полноценно ее заменить, так как не содержит “человеческих” характеристик, важных для активации эмпатии, таких как характер, возраст, пол и пр.
Что иллюстрирует
Знания продуктовой команды о пользователе, полученные из исследований. Может описывать одного или нескольких пользователей.
Когда применять
Когда необходимо создать артефакт, вызывающий эмпатию у команды и описывающий наши знания о пользователе, его потребности и желания.
Основные элементы
Типичная карта эмпатии включает в себя четыре квадранта:
- Says (что пользователь говорит вслух во время исследований. В идеале это реальные цитаты, записанные во время интервью или сессий тестирования)
- Thinks (что думает пользователь, взаимодействуя с продуктом. что для него важно. Во время исследования обратите внимание на то, что пользователи, возможно, не хотят озвучивать. Попытайтесь понять, почему они не хотят делиться — они застенчивы, вежливы или боятся? Это сложно вычленить и есть риск начать фантазировать. Иногда блоки Says и Thinks совпадают)
- Does (какие физические действия предпринимает пользователь)
- Feels (что чувствует пользователь, какие эмоции он испытывает)
Дейв Грей, автор книги Gamestorming в 2017 году предложил расширенный вариант Empathy Map, в которой:
- объединяются Thinks & Feels, Says & Does
- добавляются Hears (что слышит пользователь от окружающих, конкурентов), Pains (страхи, боли, причины фрустрации) и Gains (представление об успехе, желаемые достижения)
Плюсы
- позволяет вызвать эмпатию и проектировать “снаружи внутрь”
- аггрегирует наши знания о ЦА в удобном формате
- подходит для совместной работы
- помогают увидеть несоответствия в словах и мыслях пользователя или в словах и поведении. Это позволяет создать продукт, который основан не только на том, что мы слышим от пользователя, но и на глубинных наблюдениях за его поведением и мотивами.
Минусы
- требует глубоких качественных исследований (интервью, наблюдения, тестирования)
- можно утонуть, пытаясь провести линию различий между похожими блоками (например, think и feel) или начать придумывать от себя
Примеры
Заключение
Помните, что создание карт — это процесс. Это диалог и совместная работа проектировщика, заказчика, стейкхолдеров, пользователей, которая помогает исправить стратегическую близорукость и раскрывает более широкую картину нужд пользователей, чем мы себе представляем.
Убедитесь, что создание карт опыта — действительно тот инструмент, который соответствует вашей цели и, если да, найдите верные ответы на 3 основных вопроса: кто, когда, что. Основываясь на этом выберите или создайте нужный вам вид карты, спланируйте и проведите необходимые предварительные исследования, подумайте как вы организуете совместную работу и проведите воркшоп с нужными участниками проекта.
Маппинг — большая и увлекательная задача, для которой нужны опыт и знания. Но всегда можно начать с малого, например с чтения этой статьи. С первым шагом вы справились — поздравляю! Самое время применить маппинг в своем проекте 😊
Если статья показалась интересной — дайте знать аплодисментами 👏
