Влад Шиляев написал о синхронизации команды с помощью CJM.

— CJM может быть любой, её структура зависит от того, какую задачу вы решаете;
— Проблема постоянно развивающегося большого (когда разные команды дорабатывают разные части) продукта в том, что у отдельных специалистов (особенно тех, кто не связан с разработкой) нет полного понимания пользовательского пути;
— Иногда нельзя просто взять и пройти путь пользователя, чтобы это понимание получить (а если можно, это требует времени): ограничения разных типов клиентов могут влиять на флоу, не все сценарии могут быть доступны сразу, в них могут быть развилки, в которые за один подход не попасть;
— Стейдж — среда тестирования, которая точно повторяет прод и позволяет создавать тестовых пользователей. В идеале проходить сценарии на реальных устройствах, а не в Xcode или Android Studio;
— Описание всего пути от начала до выполнения поставленной цели позволяет увидеть общую картину и конкретные интерфейсы, найти слабые места и ошибки флоу, сгенерировать новые идеи;
— Структура: цели, шаги и действия пользователя, мобильный флоу (скриншоты интерфейса, по сути Screen flow), десктопный флоу, боли и барьеры, позитивные моменты, идеи по улучшению, отслеживаемые метрики;
— Дополнительно такая карта сокращает обращения к дизайнерам за нужными флоу (можно добавить ссылки на макеты), помогает найти нестыковки между макетами и продом и запланировать их исправление, а также адаптировать новых сотрудников;
— Стоит добавить оглавление с типами пользователей, рассмотренными сценариями, ответственными (к кому обращаться с вопросами и проблемами), а также логи обновлений, чтобы была ясна актуальность карты;
— Так как за стрелками следить сложно (и иногда их бывает слишком много), удобно вставлять блоки с развилками — описанием путей, по которым может пойти сценарий и якорными ссылками на соответствующие участки карты;
— Карта быстро устаревает, если её не обновлять. Обновление карты надо делать частью процесса разработки, выделять на это время в спринте.

#cjm