Юрий Веденин, UXPressia: «Большая часть людей понимает под CJM любые карты пользовательского опыта»

9 минут

30.03.2021

Юрий Веденин, UXPressia: «Большая часть людей понимает под CJM любые карты пользовательского опыта»

Для книги о продуктовых исследованиях наш контент-маркетолог Света Гусева поговорила с Юрой Ведениным, основателем сервиса UXPressia.

Юра — эксперт в области бизнес-анализа, юзабилити и аналитики пользовательского опыта. UXPressia — инструмент для создания CJM и других experience-карт, которые помогают бизнесу улучшить свой продукт.

Обсудили с Юрой:

почему все путаются в терминологии CJM и как этого избежать;
чем для компаний полезны карты пользовательского опыта;
что такое Service Blueprint и как он может помочь в организации процессов компании;
опыт UXPressia с составлением experience-карт для собственного продукта.

— CJM, UJM, LXM. Кажется, что список можно продолжать бесконечно. Почему в мире карт пользовательского опыта так много названий, зачем они нужны?

— Всё дело в целях. Деление карт на виды и типы зависит от того, кто и с какой целью их строит. Чтобы понять, какая именно карта вам необходима, нужно задать вопрос: «А для какой цели она мне нужна? Что я потом буду с ней делать?»

Первое, на что стоит обратить внимание, — это деление карт на «as is» и «to be», то есть — «как есть» и «как должно быть». Это различие влияет на то, что именно мы отражаем внутри карты.

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

Карту «to be» строят на гипотезах. Такие карты необходимы, когда цель — создание нового опыта пользователя при разработке нового продукта.

— Какой детализации должны быть карты?

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

Карта — это элемент коммуникации. Это сторителлинговая техника. Она помогает доносить такую информацию, которую без визуализации трудно воспринимать.

— Когда я говорила о разных CJM, я имела в виду именно customer journey map. Помимо этого, есть life experience map, user journey map. Эти карты — внутри CJM?

— Все эти аббревиатуры — понятие техники. Существует техника, которая исторически называлась customer journey map, но потом, когда её начали использовать не только для моделирования пути покупателя, начали появляться и другие.

99% людей взаимозаменяют эти названия просто потому, что им всё равно. Они не чувствуют разницы, и это нормально.

Если говорить о том, в чём заключается отличие UJM от CJM, то 1% людей, которые разбираются в понятиях, скажут, что user journey map — карта опыта только внутри продукта, карта пользователя.

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

— А есть другая разница, принципиальная?

— Нет. Большинство людей, которые используют эту технику, просто скажут «Я строю customer journey map». Даже если карта построена не для клиента, а для кого угодно: пациента или студента, например.

— Как в эту систему встраивается Service Blueprint?

— Service blueprint — это модное название для описания бизнес-процессов. Термины «бизнес-процессы» и «карта бизнес-процессов» означают то же самое. Те люди, которые верят в то, что человек — на первом месте, должны сначала строить CJM. Если при построении CJM вы понимаете, что есть процессы, которые можно улучшить, то стоит построить Service Blueprint.

Почему я описываю это сверху вниз: потому что считается, что CJM находится сверху и отражает взаимодействие клиента с компанией. Service Blueprint — это про то, что происходит внутри компании, как бы на бэкенде.

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

Service Blueprint показывает, из-за чего могут отваливаться люди на некоторых этапах CJM.

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

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

Проблемы в этом примере: приложение не работало, и поддержка не отработала таким образом, чтобы я остался доволен. Service Blueprint помог бы увидеть эту проблему.

— Скажи, когда компании нужно задуматься над тем, что возможно ей стоит построить Service Blueprint?

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

Приведу простой пример. У клиентов компании возникает очень много вопросов в customer support. В качестве решения этой проблемы было принято решение начать проводить онбординг-сессию. Из этого решения вытекает вопрос: кто будет делать этот онбординг? Отдел продаж? Будущий аккаунт-менеджер? Кто-то из поддержки? А каким образом нужно проводить этот онбординг?

На этом моменте менеджмент компании может сказать «Слушайте, кажется, ещё не время. Нужно создавать институт аккаунт-менеджмента, а у нас нет на это ресурсов».

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

Стоит отметить, что не всем компаниям нужна полноценная карта Service Blueprint, иногда достаточно добавить в CJM пару секций и назвать их «Отдел, который отвечает за этот этап». У CJM нет жёсткой структуры, как в физике или математике, например. Туда можно добавить всё то, что может решить вашу проблему, в том числе и элементы, присущие Service Blueprint.

— А что насчет персонажей для построения карт? Карты можно строить, опираясь на buyer-персон или user-персон, поведенческие паттерны. В каком случае мы должны строить от ролей, а в каком — исходя из пользовательских сценариев?

— Для начала можно объединить три понятия: user-персона, buyer-персона и сценарии использования. Сама техника персоны подразумевает, что мы делим нашу целевую аудиторию по поведенческим характеристикам, которые как-то совпадают. Люди ведут себя похоже, поэтому мы относим их в одну группу. Это и есть типовые сценарии.

User-персоны типовым образом используют продукт. Их следует использовать в том случае, если цель — улучшить опыт использования продукта.

Buyer-персоны типовым образом покупают продукт. Нужно использовать buyer-персоны, если цель компании — улучшить маркетинг и продажи.

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

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

— Насколько важно делить персон на роли?

— Роли — это попытка разделить целевую аудиторию на части. В компании ролями будут должности — маркетологи, продакты и так далее. Мы можем предполагать, что если человек называется продакт-маркетологом, то он выполняет одни функции, а если он называется СЕО компании, то другие. Это не всегда так.

Деление персон на роли лишь помогает упорядочить бизнес-мир, помогает нам договариваться.

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

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

— Я знаю от Ника Ефимова (примечание редакции: Ник Ефимов — Chief Product Officer в UXPressia Academy и Product Advisor в UXPressia), что вы строите карты, опираясь на разные типы мышления. Как это?

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

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

Мы выделили три майндсета:

Первый — UX/Service Design. Эти люди думают в терминах work flow, процессов и их изменений. Они смотрят на проблемы глазами кастомера, говорят их словами и строят карты, опираясь на их категории.

Второй — это CX/маркетинговый. Такие люди думают в терминах маркетинга и их карты фокусируются вокруг маркетинговой стратегии или стратегии продаж. Маркетинговые кампании, каналы, KPI — это к ним.

Третий — IT-майндсет. Сразу замечу: это сугубо внутреннее название, которое никакого отношения не имеет к общепринятому пониманию IT-сферы. Люди с айтишным майндсетом думают в разрезе систем и сервисов, технических специфик. У них, скорее всего, технический бэкграунд.

— Как вы определили эти три категории?

— Это был непростой процесс. Мы провели примерно 40 глубинных интервью, сотни опросов, посмотрели какое-то количество карт. В какой-то момент мы решили проводить входной опрос, который помогал людям самоидентифицироваться. На него мы получили почти 10 тысяч ответов, которые начали валидировать.

— Вы берёте в приоритет все три майндсета?

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

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

— Юра, скажи напоследок, о чём стоит подумать людям, которые только начинают строить карты? Как понять, какую именно карту им необходимо построить?

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