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

Так было и у нас, пока мы не решили попробовать собрать Customer Journey Map (CJM). Мы поделимся опытом построения нашей карты, расскажем о трудностях, с которыми столкнулись, о том, каким был отзыв от команды (спойлер – он положительный), и как CJM помогает нам в работе над продуктом.

Что такое CJM? 

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

Внутри нашей команды мы сформулировали такое определение:

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

Что же даёт CJM?

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

2. Выявить барьеры и боли Это могут быть барьеры, вызванные сложным процессом (например, длительные процедуры регистрации и оформления), проблемами коммуникации (не информативные экраны, непонятно, что делать дальше), техническими стопорами (много экранов загрузок, открытие экранов через web view). Когда боли конкретизированы и отслежены, можно начать генерировать гипотезы и искать решения для их устранения.

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

4. Сгенерировать новые идеи Намного проще генерировать идеи, когда продукт визуально представлен. CJM позволяет команде видеть все этапы и точки взаимодействия пользователя с продуктом, что стимулирует креативность и помогает искать новые возможности для улучшения.

5. Увидеть общую картину продукта Развитие и поддержка продукта – это работа, в которой принимает участие большое количество различных специалистов, начиная от СРО и продактов и заканчивая юристами и специалистами по клиентской поддержке. В этом контексте CJM играет важную роль, помогая всем членам команды взглянуть на продукт глазами пользователя и понять, как их работа влияет на пользовательский опыт. Это способствует росту вовлеченности и интереса к продукту, над которым они трудятся.

А как должна выглядеть CJM?

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

Это, наверно, самый популярный вид карты:

А вот большой и подробный пример CJM, которую сделали ребята из торговой сети «Ашан» (про него можно прочитать тут). Интересно, что на их карте можно отследить взаимодействие с продуктом даже до того, как происходит непосредственный контакт с ним. 

И ещё пример от «Лего». Их подход выглядит необычно, не правда ли? Здесь показан путь клиента (хоть и в контексте полета на самолете, а не взаимодействия с основным продуктом бренда). Они назвали это «experience wheel» (колесо опыта), но, по сути, это тоже CJM, в которой задокументированы все шаги пользователя.

И это только пара примеров. Проанализировав существующие CJM разных команд и компаний, мы пришли к следующему важному выводу.

Не существует идеального шаблона CJM. Можно добавлять любые поля и состояния, придумывать любые правила заполнения, которые нужны для конкретного продукта. Это абсолютно настраиваемый инструмент, и только сам дизайнер может понять, где и в каком виде ему нужна эта карта.

Как мы строили первую версию

Основной продукт, над которым мы работаем в команде Ozon Банка, — «Ozon Рассрочка». Как и весь банк, этот продукт стремительно растет. В команде появляется всё больше и больше людей, и, чтобы контролировать весь продукт и понимать, как происходит взаимодействие наших клиентов с ним, мы приняли решение создать собственную CJM.

Шаг первый. Определить пользователей

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

А теперь представьте, что на эту типологию накладывается ещё и классификация клиентов в контексте именно кредитных продуктов.

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

Шаг второй. Выявить основные сценарии

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

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

Теперь настало время придумать, как нам воспроизвести все эти флоу.

Шаг третий. Собрать сценарии в карту

К сожалению, работа в банке накладывает определённые ограничения. Например, в банках нельзя делать тестовых пользователей — мы можем взаимодействовать с приложением, которое скачали, только как реальные пользователи. Но невозможно открыть несколько банковских аккаунтов или оформить несколько лимитов рассрочки. В этом случае на помощь приходят стейджи (Stage – это среда для тестирования, которая в точности повторяет продакшн-окружение. Грубо говоря, это эмуляция вашего приложения).

В нашем арсенале были стейджи, которые используются разработкой и QA, а именно:

• Android Studio – эмуляция Android

• xCode – эмуляция iOS

• Web стейдж – соответственно, веб-формат
  Ну и, конечно, очень круто, если у вас есть возможность использовать прод. Это дает самую реальную картину и настоящее погружение в пользовательский опыт — по сути, вы становитесь пользователем. Мы взяли в рассрочку стиральный порошок и сразу погасили долг. В итоге сделали два полезных дела сразу: собрали флоу и постирали вещи ?

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

⚡️ Первая версия CJM

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

Cтруктура

Так как мы — дизайнеры, а наш основной инструмент работы — это Figma (? запомним этот момент на будущее), мы собирали CJM в ней же. Это удобная для нас среда, где мы можем более гибко собирать и отображать карту, чем если бы мы делали это в Miro или Google Таблицах.

Разберём подробнее каждый блок карты.

• Цель и идеи по улучшению флоу 

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

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

• Мобильный флоу

Блок, который, по сути, представляет Screen Flow внутри CJM, — это прямое отображение вашего интерфейса и того, как его видит пользователь в конкретный момент. Именно для этого мы и использовали стейджи.

• Веб-флоу 

Соответственно, здесь мы отображаем интерфейс с веба.

• Шаги пользователя 

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

• Боли и приятности

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

• Аналитика

Хотя приоритетом для нас всегда являются пользователи, мы всё же работаем над продуктом, и команде важно понимать, какие ключевые метрики мы отслеживаем и как на них влияем.

Итоги

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

Что же у нас получилось?

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

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

2. Найти несостыковки между продом и макетами

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

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

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

4. Помочь в адаптации новых сотрудников

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

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

На этом всё, всем спасибо!… Так мы могли закончить нашу статью, но нет, ведь после четырех месяцев с момента запуска CJM пришли они – комменты в Figma.

Для нас это стало тревожным звоночком. Мы, дизайн-команда, совместно с менеджерами сели анализировать, что же произошло после, казалось бы, такого успешного запуска CJM.

Проблемы первой версии

1. Крупные запуски и мелкие правки в экранах не успевают отображаться на карте
   Создание CJM было полностью инициативой дизайнеров и продактов. И у тех, и у других есть первостепенные задачи, и CJM строилась в свободное от основных задач время. Отсюда возникла проблема: незначительные изменения в экранах (например, формулировка в плейсхолдере) или последовательные крупные проекты не успевали попадать на карту. В результате карта быстро устаревала и теряла свою актуальность.

2. Сложная навигация
   Помните, мы просили запомнить тот факт, что мы выбрали Figma как инструмент для построения CJM? Так вот, если дизайнер работает в ней 80% своего времени, фронтенд-разработчик и продукт-менеджер — 30%, то юристы, биздевы и специалисты клиентской поддержки – ровно 0%. Сколько бы вы ни говорили им про величие и технологичность Figma, для них самым удобным инструментом остаётся Excel. Им просто непонятно, как управляться с Figma и находить там нужный сценарий.

3. Непрозрачность различий между типами пользователей
   Сложная навигация усугублялась следующей проблемой: если команды, отвечающие непосредственно за разработку, знают классификацию пользователей продукта, то для остальных команд типология создавала путаницу при просмотре карты. В Figma категории пользователей обозначались просто как «Новички» или «Одобренные», без пояснений, кто это и в чем их особенность при использовании продукта.

4. Непонимание, к кому обращаться по вопросам флоу
   Если раньше к дизайнеру обращались с вопросами о расположении флоу, то после предоставления свободного доступа к CJM возникли новые вопросы. Кто за какой кусок ответственен? К какому менеджеру или дизайнеру идти с вопросом? Раньше дизайнер, который искал флоу, мог подсказать ответственного, а теперь коллегам приходилось выяснять это самим.

Что решили делать дальше?

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

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

2. Актуализировать все сценарии
   Пройтись по всем сценариям и обновить CJM, чтобы карта отражала текущую реальность продукта и включала все изменения, которые произошли с момента создания первой версии. А еще — подумать над тем, как нам чаще обновлять карту.

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

⚡️ Вторая версия CJM

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

Новая навигация

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

Добавили в карту так называемую «Шапку» флоу. В ней описано, какой сценарий открыт перед человеком, к какому типу пользователей он относится, к какому стриму принадлежит, кто ответственный менеджер и дизайнер, а также, если есть, указана ссылка на макеты в Figma.

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

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

Раньше мы использовали стрелки, чтобы показывать разветвления, но со временем они начинали пересекаться и больше путали, чем помогали. Интерактивные элементы упростили взаимодействие: теперь нужно только нажать на «кнопку», чтобы перейти к нужному участку.

И последнее наше нововведение – «Логи обновлений». Чтобы было понятно, насколько карта актуальна и когда были сделаны последние изменения, мы решили добавлять стикеры с датой и описанием изменений

Сборка сценариев (снова)

В этот раз мы пересмотрели и подход к прохождению сценариев. Если раньше мы собирали абсолютно всё благодаря стейджам, то теперь захотели ещё больше погрузиться в пользовательский опыт. Так как более 85% наших пользователей используют мобильное приложение, мы решили отказаться от стейджей и проходить сценарии на мобильных устройствах.

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

Что получилось

После переработки навигации, актуализации сценариев, обновления внешнего вида и самого подхода к прохождению наших сценариев, мы собрали нашу вторую (и на момент написания статьи актуальную) версию CJM.

Давайте поближе посмотрим на новую структуру:

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

   

2. Mobile FlowКак и в предыдущем варианте карты, этот блок представляет собой Screen Flow, но, как упоминалось ранее, в этот раз каждый такой флоу был сделан с помощью тестового телефона, а не стейджа.

   

3. Desktop FlowАналогично первой карте это просто флоу, собранное с веб-стейджа

   

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

   

5. «Аналитика»Тут все осталось без изменений – выписываем, какие метрики мы можем отследить и на какие повлиять в данный момент на данном участке флоу.

   

Итоги

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

Вот что у нас получилось:

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

2. Расширили и конкретизировали карту Добавили больше блоков, классифицировали флоу, дали контакты, к кому обращаться по вопросам на разных этапах. Все это позволило ещё сильнее погрузиться в продукт и детальнее его рассмотреть.

3. Получили позитивный фидбек от команды ❤️ Мы очень рады, что вторая версия оправдала ожидания и теперь ею свободно пользуется вся команда. Команда все больше вовлекается в продукт, над которым работает, а нам это даёт заряд сил, чтобы и дальше развивать инструмент.

4. Наметили план по обновлению

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

   Также мы планируем развить нашу CJM до полноценного Blueprint, где мы будем отслеживать не только взаимодействие пользователя с продуктом, но и все процессы, которые происходят под капотом. Для этого мы уже работаем над добавлением нового блока с событиями backend, хотим добавить маркетинговые коммуникации и многое другое.

Выводы

А вот ценные выводы, которые мы сделали в первую очередь для себя, после опыта построения двух CJM.

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

2. CJM может выглядит как угодно, главное, чтобы она была полезена
   Будете вы добавлять Screen Flow или нет, будете собирать карту в Figma или Miro, а может рисовать ее на доске маркером – это всё не важно. Главное, чтобы CJM решала ту задачу, которую поставила перед собой команда.

3. На CJM нужно выделять время, как на полноценные задачи
   Это очень важно донести до команды и менеджеров. Если вы решили, что вам нужна CJM, следует понимать, что это займет время: придумать, как вы будете собирать карту, какая должна быть структура, как она будет выглядеть и многое другое. Поверьте, на проработку уйдет немало времени. Мы стали выделять полноценное время в спринте для обновления карты.

4. Это длительное и утомительное занятие, но оно того стоит
   Не будем скрывать: сборка CJM — это не самая простая и романтичная работа. Нужно помнить все сценарии, не упустить корнер-кейсы, документировать огромный поток информации и не забывать обновлять карту время от времени. Но поверьте, итог стоит вложенных сил. Ни один инструмент не обеспечивает такого уровня погружения и детального анализа потребностей и проблем ваших пользователей, как CJM. Бонусом является синхронизация всей вашей команды, где каждый участник сможет увидеть результат своей работы

Заключение

Спасибо, что дочитали до конца. Надеюсь, что вам было интересно и полезно почитать про наш опыт по построению CJM. Будем рады, если он вам пригодится (даже если, прочитав, вы решили не строить CJM ?).