August 2, 2021

Как UX-дизайнеру НЕ рисовать CJM

Привет-привет! В вакансиях продуктовых дизайнеров часто есть требование "уметь рисовать CJM". Соответственно, меня часто просят научить его рисовать :)

Как показывает практика, для UX/UI-дизайна CJM скорее поглотитель времени, чем хороший инструмент. Да, для маркетинга, для управления продуктом он отлично работает. Для UX/UI-дизайна — не очень.

В этой статье разберемся, почему так, а в следующей — поймем как получить "CJM здорового человека"

Чем не хорош классический CJM

Да всем хорош:) В тех задачах, для которых он предназначен

Для чего нужен классический CJM?

  • Сделать карту всего бизнеса, найти больные места и определиться, что с ними делать. На CJM можно опираться, когда планируешь этапы работы над бизнесом, распределяешь эту работу, думаешь о найме команды на участки воронки и пр.
  • Докрутить маркетинг. Эмоции, барьеры, тачпоинты — все это полезно когда коммуникацонные стратегии, прорабатываешь креативы для разных каналов и пр.
  • Чтобы управлять продуктом. Готовить родмап и пр.

И вот тут возникают вопросы:

  • Насколько это близко к обычной работе дизайнера, который не дизайн-директор, не продакт и не со/основатель?
  • Работает ли такой CJM, если его строить из головы?
Итого — дизайнеру-то CJM зачем?

Классический CJM — обжора

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

  1. Actions — поговорить с кем-то, кто хорошо знает продукт. Скорее всего — собрать количественные данные, чтобы померить, что пользователи делают, а что нет
  2. Moods — скорее всего, много интервью, и с пользователями, и с саппортом/сейлзами, и пр.
  3. Touchpoints — для первого приближения достаточно просто поговорить с тем, кто хорошо знает продукт. Для глубокого понимания (звонят по телефону — а сколько раз? Как дозваниваются? И пр.) — снова много говорить с людьми и собирать данные
  4. Pain points — количественные данные (где пользователи отваливаются и бросают наш продукт, где совершают ошибки), возможно юзтесты (почему это происходит, что конкретно неудобно и непонятно пользователям), возможно интервью (что это значит для жизни пользователя)

Серьезно? Мне дали нарисовать фичу и я пойду все это собирать?

Итого — CJM редко подходит и реально помогает в быстрой работе уровня "запилить фичу". Только если у вас уже есть все необходимые данные о пользовательском опыте. То есть были исследования, по ним были заботливо собраны инсайты, и все это под рукой

Да, исключения бывают

Вот хороший кейс от Risiandi Jiang (из которого я как раз взял скриншот CJM) http://workonux.com/project/perx-loyalty-reward-app

Там применяется как раз классический CJM и ребята сделали хорошую работу. Но на один такой хороший случай я знаю очень много плохих, где классический CJM просто запутал дизайнера и команду:)

Зачем тогда CJM пишут в вакансиях?

Чаще всего я видел вот такие причины:

  1. Просто копипаста, "все пишут и мы напишем".
  2. Хотят, чтобы дизайнер понимал бизнес, мог как-то изобразить жизненный цикл пользователя и его проблемные места. И считают, что CJM — показатель наличия этого скилла.
  3. CJM действительно "умеют готовить" и работа над ним правда встроена в процесс (редкий случай)

Что с этим делать? Для первого случая достаточно рисовать CJM из головы (то есть не проводя исследований), но точно по шаблону. Скорее всего, использовать его по-настоящему не потребуется.

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

  • вместо "каких придется шагов" можно использовать AARRR-воронку или что-то подобное
  • вместо слоев с настроением и эмоциями пользователя, барьерами (которые не так просто выяснить) и пр — поставить например бизнес-задачи и сценарии/экраны/фичи. Будет намного проще и полезней

А в третьем случае можно вообще не уметь работать с CJM. Для данного работодателя это может быть даже плюс:) (иногда легче научить с нуля, чем переучивать)

И что мне с этим делать?

Допустим, мы договорились, что рисовать барьеры-эмоции-пейнпоинты в CJM из головы — зло. Но делать-то с этим что? Как учиться CJM? Какие схемы и когда предлагать вместо CJM?

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

  1. Если хочется просто соответствовать копипаста-вакансиям (не вижу в этом ничего плохого кстати) — гуглим CJM в яндекс-картинках и рисуем по найденным шаблонам для первых попавшихся 10-15 продуктов. Ты на "стороне зла, но зато есть галочка в резюме"
  2. Если хочется по-честному в CJM — сначала выполняем п. 1, потом учимся UX Research, и собираем нужные данные. Плюс беремся за задачи, в которым мы хотим по настоящему что-то улучшить в бизнесе, дать ему и пользователям ценность. 2-3 проваленных задачи, 1-2 успешных — и ты уже выше "копипаста-вакансий"
  3. Если нужно больше показать продукт, чем пользовательский опыт — учимся рисовать Service Blueprint, он подойдет больше, чем CJM
  4. Если речь не о целом продукте, а об отдельных фичах — учимся рисовать userflow/taskflow/screenflow
  5. Если речь о сложном взаимодействии пользователя с какой-то системой, где много развесистых сценариев — диаграмма юзкейсов и описание этих самых юзкейсов (про написание юзкейсов есть хорошая книга, А.Коберн "Современные методы описания функциональных требований к системам")
  6. Если нужно показать разработчикам, что есть в системе — screenflow плюс карта сущностей. Юзкейсам они тоже будут рады
  7. Если надо самому разобраться в сложной предметной области и другим объяснить — concept map

Хочется освоить схемы?

Я веду индивидуальный менторинг, партнерюсь с интересными продуктами, и с удовольствием отвечаю на вопросы.

Мой телеграм (написать в личку)

И мой телеграм-канал

И Youtube