Недавно я наткнулся на одну мелкую и ядовитую историю, которая сподвигла меня встать на фоне заката, запустить руку в бороду и рассказать вам про CJM - Customer Journey Map. Если вы знаете про CJM, мотайте ленту вниз - в следующем посте я как раз исхожу злобой по поводу этой истории, - а тут я хочу разъяснить азы советской власти.
CJM, вообще говоря, предназначен для решения следующей проблемы: у нас есть пользователь со своими задачами и болью, у нас есть разрабатываемый продукт со всеми функциональными пирогами, так как же они будут взазимодействовать между собой, спрашивается? Как же нам избежать известной жопы, когда вроде и продукт ок, и пользователь ок, а между собой они не дружат? Как заставить агнца возлечь возле льва?
Про CJM принято думать, что это что-то АДСКИ СЛОЖНОЕ и вообще МАТАН, в доказательство чего все тыкают в статьи разных экспертов с дубовыми схемами, формулами и грандиозными диаграммами.
А я вам говорю, что никакого матана в CJM нет. Щас расскажу. Берем и делаем вот что:
1. Садимся, берем реального и гипотетического пользователя, понимаем, какую задачу он хочет решить (или какой цели достичь), в каком контексте и с какими дополнительными обстоятельствами. Этот пункт удобно проворачивать при помощи метода персонажей, но я про него в другой раз расскажу.
2. Расписываем квадратиками в ряд: для достижения своей цели пользователь делает вот это, потом вот это, потом вон то - а потом вон то.
3. Смотрим внимательно на квадратики и думаем: а чем наш продукт сможет помочь пользователю на каждом шаге? И пишем чуть ниже напротив каждого квадратика: вот здесь продукт будет делать все за пользователя, вот тут пользователю будет предложен выбор, здесь ему будет приходить пуш-уведомление - и так далее.
4. Любуемся теперь уже двумя наборами квадратиков, идущих рядом - и вслед за этим начинаем думать: а какие терки могут возникать между пользователем и продуктом на каждом шаге? Например, вот здесь пользователь должен будет выбрать из 20 очень похожих вариантов; это нехорошо. Здесь пользователь должен будет не пропустить пуш-уведомление, иначе он ничего не сможет сделать дальше; это тоже не очень гут. Аккуратно расписываем все эти терки напротив каждого квадрата.
И… всё. Не, серьезно, всё. У вас уже готов минималистичный CJM, который позволяет понять, как действует пользователь, как ему помогает продукт - и какие помехи и проблемы возникают в процессе.
Конечно, есть еще тонна нюансов, но их можно постигать в процессе. Например, CJM нужно составлять не только для того отрезка времени, пока пользователь контактирует с продуктом, а смотреть еще, что пользователь делал до и после. При составлении CJM важно по максимуму использовать реальные данные, а если фантазировать - то отмечать это как свою собственную гипотезу.
Еще - по ситуации - можно расписывать CJM более глубоко и подробно, например:
- Для каждого шага описывать мысли и эмоции пользователя;
- Для каждого шага описывать, с какими интерфейсными блоками, страницами или экранами пользователь будет взаимодействовать
- Расписывать, какие интеграции с внешними системами нам понадобятся для осуществления каждого шага;
- Указывать взаимосвязь с бизнес-процессами, завязанными на пользовательский сценарий (например, пользователь покупает товар - а вот тут мы активируем бизнес-процесс заказа внутри организации);
- Раскидывать CJM на несколько каналов (соцсети, приложение и т.п.) и смотреть, как пользователь переходит из одного места в другое;
- На основе CJM рисовать конверсионную воронку - то есть указывать для каждого этапа метрики и KPI, которыми мы будем мерять эффективность прохождения пользователем сценария.
Ну и ооочень много чего еще, что вы обычно видите в статьях и материалах от CJM-гуру. CJM - охрененно гибкий формат, на который вы можете накрутить все, что хотите, но начать можете с совсем малого и простого, и уже будет очень много пользы.
Так что не бойтесь и пробуйте.
#вашидокументы
CJM, вообще говоря, предназначен для решения следующей проблемы: у нас есть пользователь со своими задачами и болью, у нас есть разрабатываемый продукт со всеми функциональными пирогами, так как же они будут взазимодействовать между собой, спрашивается? Как же нам избежать известной жопы, когда вроде и продукт ок, и пользователь ок, а между собой они не дружат? Как заставить агнца возлечь возле льва?
Про CJM принято думать, что это что-то АДСКИ СЛОЖНОЕ и вообще МАТАН, в доказательство чего все тыкают в статьи разных экспертов с дубовыми схемами, формулами и грандиозными диаграммами.
А я вам говорю, что никакого матана в CJM нет. Щас расскажу. Берем и делаем вот что:
1. Садимся, берем реального и гипотетического пользователя, понимаем, какую задачу он хочет решить (или какой цели достичь), в каком контексте и с какими дополнительными обстоятельствами. Этот пункт удобно проворачивать при помощи метода персонажей, но я про него в другой раз расскажу.
2. Расписываем квадратиками в ряд: для достижения своей цели пользователь делает вот это, потом вот это, потом вон то - а потом вон то.
3. Смотрим внимательно на квадратики и думаем: а чем наш продукт сможет помочь пользователю на каждом шаге? И пишем чуть ниже напротив каждого квадратика: вот здесь продукт будет делать все за пользователя, вот тут пользователю будет предложен выбор, здесь ему будет приходить пуш-уведомление - и так далее.
4. Любуемся теперь уже двумя наборами квадратиков, идущих рядом - и вслед за этим начинаем думать: а какие терки могут возникать между пользователем и продуктом на каждом шаге? Например, вот здесь пользователь должен будет выбрать из 20 очень похожих вариантов; это нехорошо. Здесь пользователь должен будет не пропустить пуш-уведомление, иначе он ничего не сможет сделать дальше; это тоже не очень гут. Аккуратно расписываем все эти терки напротив каждого квадрата.
И… всё. Не, серьезно, всё. У вас уже готов минималистичный CJM, который позволяет понять, как действует пользователь, как ему помогает продукт - и какие помехи и проблемы возникают в процессе.
Конечно, есть еще тонна нюансов, но их можно постигать в процессе. Например, CJM нужно составлять не только для того отрезка времени, пока пользователь контактирует с продуктом, а смотреть еще, что пользователь делал до и после. При составлении CJM важно по максимуму использовать реальные данные, а если фантазировать - то отмечать это как свою собственную гипотезу.
Еще - по ситуации - можно расписывать CJM более глубоко и подробно, например:
- Для каждого шага описывать мысли и эмоции пользователя;
- Для каждого шага описывать, с какими интерфейсными блоками, страницами или экранами пользователь будет взаимодействовать
- Расписывать, какие интеграции с внешними системами нам понадобятся для осуществления каждого шага;
- Указывать взаимосвязь с бизнес-процессами, завязанными на пользовательский сценарий (например, пользователь покупает товар - а вот тут мы активируем бизнес-процесс заказа внутри организации);
- Раскидывать CJM на несколько каналов (соцсети, приложение и т.п.) и смотреть, как пользователь переходит из одного места в другое;
- На основе CJM рисовать конверсионную воронку - то есть указывать для каждого этапа метрики и KPI, которыми мы будем мерять эффективность прохождения пользователем сценария.
Ну и ооочень много чего еще, что вы обычно видите в статьях и материалах от CJM-гуру. CJM - охрененно гибкий формат, на который вы можете накрутить все, что хотите, но начать можете с совсем малого и простого, и уже будет очень много пользы.
Так что не бойтесь и пробуйте.
#вашидокументы