Если трудно оценить этапы проекта, в бэклоге появляются пробелы, срывается запланированный релиз, а команда не может договориться, кто больше всех вкладывает в продукт, то пора освоить новый инструмент: карту пользовательских историй User Story Mapping.
Благодаря этой технике у команды складывается наглядное понимание цельной картины проекта, разделенной на спринты: от идеи до реализации. Визуальное оформление помогает увидеть взаимосвязь между отдельными этапами, правильно расставить приоритеты и не пропустить важные задачи.
Из статьи узнаете, как подготовиться к сессии по User Story Mapping, кого позвать на встречу, и как сопровождать процесс, чтобы достичь хорошего результата.
Что такое User Story Mapping
Технология создания карт — прекрасный способ собрать всех заинтересованных в проекте лиц, поставить задачи визуально отобразить как выглядит путешествие пользователя по продукту. Список требований (бэклог) формируют и оформляют общими усилиями стейкхолдеров, это квинтэссенция всего, что вы знаете о пользователях: где они чувствуют себя уверенно в продукте, а где — нет, какие задачи и действия приоритетнее.
В основе пользовательской карты лежат три инструмента: User Persona, User Story и User Journey:
- User Persona — это описание конкретного пользователя, с целями и проблемами, которые герой надеется решить при помощи продукта. Возможных пользователей можно рассматривать индивидуально по персонам или по группам: casual user, business user, powerful user.

- User Story — это 1-2 предложения о том, чего хочет достичь человек, используя ваш продукт, что пользователь может делать в системе. Обычно истории создают по следующему шаблону: «Как кто-то (роль) я хочу (цель/желание), чтобы (выгода)».
Например, хочу нажать на кнопку, чтобы оставить свои данные и получить бесплатную книгу. Другой, технический формат создания истории, нацелен на то, как упростить клиенту выполнение часто используемых действий, предоставить нужный результат в «два клика».

- User Journey — описание задач и действий клиента, его опыта, эмоций, мыслей на всех этапах взаимодействия с продуктом. Шаги пользователя продумывают, а потом фиксируют в удобном для команды варианте: на бумаге, в формате Trello-доски или визуализации в MIRO. Шаги User Journey будут нужны для создания скелета-основы User Story Mapping.

Создают User Journey люди, которые непосредственно работают с пользователями: UI и UX специалисты, маркетинговая или продуктовая команда, аналитики, user research специалисты, проектные менеджеры.
Чем полезна карта пользовательских историй:
- сохраняет фокус на клиенте и его продвижении по продукту;
- визуализирует шаги пользователя (User journey);
- наглядно показывает связь действий клиента с User story;
- дает увидеть дополнительные возможности, что приводит к появлению хороших идей;
- формирует общее понимание у всех стейкхолдеров.
После сессии по User Story Mapping все заинтересованные лица выйдут из комнаты с одинаковым сформированным пониманием: что мы делаем, для кого конкретно, как выглядят шаги создания нужной реальности и зачем это пользователю.
User Journey: практический пример

Рассмотрим ситуацию, когда человек приобретает онлайн-билет в кино, а затем обменивает электронную версию на реальный билет в кассе кинотеатра. Какие действия по-порядку должен совершить пользователь?
Список шагов (User Journey) может выглядеть следующим образом:
Зайти на сайт → авторизоваться → выбрать фильм → выбрать дату и время → подобрать места → указать число билетов → оплатить → добраться до кинотеатра → постоять в очереди на обмен → войти в зал → найти место → посмотреть фильм.
Этот перечень должен включать все шаги для достижения нужного результата, причем посмотреть фильм — это не обязательно конечная цель. Возможно, пользователь хочет купить билет онлайн, чтобы:
- получить бумажный билет и подарить кому-то;
- обменять на бумажный вариант и прийти посмотреть фильм через неделю;
- отправить на email другу — это может быть вашей crazy idea, которая позже станет дополнительной фичей.
Самый первый пункт, который вы записали в User Journey, может быть точкой входа пользователя: как в сам продукт, так и в одну из его фич. Например, всем пользователям нужно открыть приложение или сайт, но способов зайти на экран с выбором билетов может быть несколько.
Как готовиться к User Story Mapping
Чтобы встреча получилась продуктивной, заранее предусмотрите несколько вещей: достаточное количество времени, список участников, место для проведения.
Кого приглашать на встречу
На первую сессию собирайте стейкхолдеров, которые смотрят на продукт с разных позиций:
- Представителей пользователей: тех, кто составлял User Journey либо людей с опытом пользователя, специалистов поддержки, которые помогают клиентам проходить все этапы.
- Если в компании есть relationship менеджеры, user researchers, обязательно пригласите их, потому что они знают, что пользователи уже умеют делать, а где пока чувствуют сложности.
- Представителей команд разработки, которые смогут донести результаты сессии до остальных сотрудников.
- Product owner-ов, представителей бизнеса, заинтересованных в получении выгоды из того, что вы делаете, и принимающих решения о релизах.
- Специалистов UI и UX;
- Архитекторов, чтобы подсказали стейкхолдерам очередность изменений.
Подготовьте базовую схему

Постройте скелет-основу — User Journey, набор всех шагов, которые пользователь сделает по продукту плюс действия в каждом шаге:
- Верхняя горизонтальная линия, «позвоночник» — это User Journey, шаги клиента, записанные в том порядке, в котором человек их выполняет.
- Вертикальные линии, «ребра» — детали-действия для каждого шага, выстроенные по приоритетности сверху вниз.
Организуйте рабочее пространство
Для сессии понадобится онлайн или офлайн доска и разноцветные стикеры для обозначения разных задач или активностей.
Например: пользовательский путь — зеленые стикеры, то, что будет в User Story — желтым, возможные сложности — красным, все пожелания бизнеса о приоритетах или релизах — небольшие яркие наклейки размером с четверть стикера.
Когда стейкхолдеры зайдут в комнату, там должно быть подготовлено все нужное для процесса:
- Образец-легенда: размещенные на отдельном месте примеры стикеров с надписью на каждом, что он значит, чтобы люди понимали какой цвет для чего использовать.
- Парковочное место — пространство для вопросов и записи потенциально возможных сложностей.
- Территория для самой карты: в офлайне это может быть специальная доска, стена или даже окно.
- Место для crazy ideas справа от карты. Там записывают идеи, которые возникли в процессе обсуждения и возможно, их получится внедрить в будущем.
- Уголок данных — data corner. Здесь будет информация о user persona. Когда дополняют какую-то фичу, то данные для нее тоже помещают в data corner. В примере с покупкой билета в кино, это может быть аналитика: какой процент пользователей покупает билеты не для себя, что люди делают с билетом после оплаты.
Для построения карты удаленно используйте диджитал-инструменты: Cardboardit.com; Storiesonboard.com; Featuremap.co; Craft.io; MIRO.
Как проводить User Story Mapping

Предварительная подготовка проведена: прописан пошаговый путь пользователя, собрана информация о клиенте, составлены портреты персон. Пространство для проведения организовано надлежащим образом. Осталось позвать стейкхолдеров и начать сессию.
Визуально карта историй на всех трех этапах выглядит как горизонтальная линия «позвоночника» и вертикальные «ребра», но цели для каждой стадии построения будут разными.
1.Создание деталей
User Journey подготавливают заранее и размещают шаги в порядке выполнения: на рисунке это горизонтальная линия с красными квадратами. Зеленые стикеры — действия, — создаются непосредственно на встрече вместе с участниками. Длительность такой сессии — около 4 часов.
Цель: Создать детали, которые пользователь пройдет на каждом шаге.

В примере с кинотеатром, горизонтальная красная линия — это последовательность всех шагов человека при оплате и получении билета.
Теперь нужно проработать вертикальные «ребра» к каждому шагу.
Какие примеры пользовательских историй можно придумать для этапа, когда пользователь выбирает место на сайте или в приложении?
Например:
- «Я хочу увидеть свободные места, чтобы иметь возможность выбрать самое близкое к выходу, самое комфортное».
- «Я хочу увидеть схему зала, чтобы выбрать удобные места для большой компании».
Продумывая примеры, учитывайте два сценария для каждого действия: у пользователя все получилось или ничего не получилось.
На этом этапе в data corner может появиться дополнительная информация:
- бизнес-цели или болевые точки;
- типы пользователей, использующих эту систему;
- цели или боли пользователя.
Фиксируйте все идеи, даже самые невероятные в уголке для crazy ideas: например, возможность для зарегистрированных пользователей видеть в первую очередь свои любимые места или видеть, куда взяли билеты друзья, если они дали на это согласие. Эти фичи не будут первоочередными, но через какое-то время их можно внедрить в продукт. Поэтому такие идеи тоже визуализируют, чтобы не потерять в процессе обсуждения.
2.Уточнение подготовленной карты: refinement
После того, как прописали все действия, озвучили сложности, зафиксировали идеи, самое время оценить и приоритизировать решения. Для этого снова соберите группу, немного изменив круг участников. Правильно расставить приоритеты помогут представители от трех направлений: бизнеса, пользователей, разработки. Выделите отдельным цветом то, что войдет в первый релиз, и линиями отделите релизы один от другого.
По времени второй этап занимает около 2 часов.
Цель: Выделить более и менее важные действия для вашего бизнеса и провести «красную линию»: что войдет в первый, второй релиз или итерацию.

3.Проработка технической составляющей
На этом этапе команда разработчиков прописывает функциональные детали, которые понадобятся пользователю при каждом действии: фронтенд, бэкенд и другие.
Действия системы создают для каждой из персон-актеров. В примере с кинотеатром актерами могут быть покупатель билета, друг, которому дарят билет, кассир, владелец кинотеатра. У каждого актера есть своя цель и своя ценность в пользовании продуктом.
В то же время в команде разработки тоже есть разделение на актеров по функционалу: фронтенд, бэкенд, тестирование, дизайн. Над реализацией каждой из фич обычно работают сразу несколько специалистов с разным объемом работы над фичей.

Правильно детализировать и оценить написанное помогут разработчик, тестировщик и ответственный за опыт пользователей.
Цель: Определить какие функции нужны для минимально жизнеспособного продукта, коротко сформулировать намерения: что система должна делать для пользователя.
После прохождения трех этапов вы получаете готовую картину действий для всех команд. Начинайте воплощать то, что запланировали. Обращайтесь к карте на протяжении всего проекта: добавляйте новые детали, обновляйте приоритеты, отмечайте выполненные задачи.
Чек-лист по User Story Mapping
- Разместите шаги пользователя (User Journey) горизонтально, чтобы получился ответ на вопрос: «Что люди делают с этой системой?»
- Переставьте шаги в том порядке, в котором пользователь «путешествует по продукту».
- Под клиентским шагом-действием или несколькими действиями распишите User Story, которые можно в случае необходимости разделить на мелкие задачи.
- Ищите действия, которые кажутся похожими, выполняются схожими людьми для достижения подобных целей. Используйте разные цвета для обозначения приоритетности.
- Определите, что войдет в первый релиз: список основных действий, которые поддерживает приложение. Это может быть более доработанный релиз или модель, которую называют «ходячий скелет» — программное обеспечение, поддерживающее наименьшее количество необходимых задач все время взаимодействия с пользователем.
- После каждого релиза вносите изменения в общую картину и заново приоритезируйте задачи.
User Story Mapping помогает гибко управлять проектами и работать с требованиями заказчика, представляя их наглядно. Построение пользовательских карт позволяет правильно ставить и планировать задачи, учитывать изменения и, в конечном итоге, увеличивать прибыль компании.