Что такое карта пользовательских историй и как её построить

Вместе со старшим спикером курса «Дизайнер интерфейсов» Александром Кирилловым пошагово рассказываем и показываем, как составить карту пользовательских историй.

User Story Mapping — это способ упорядочивания и визуализации пользовательских историй и их наложения на путь пользователя с целью улучшения существующего продукта и приоритизации накопившихся задач. При этом в фокусе — именно польза для пользователей.

Например, оптимизация структуры базы данных или рефакторинг кода не касаются клиента и не приносят ему очевидной пользы — в отличие от замены иконок на более очевидные или добавления фильтра по скидке в онлайн-магазине. Юзер-стори в этом случае может быть сформулирована так: «Как пользователь я хочу иметь возможность отфильтровать товары по размеру скидки».

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

Например, для онлайн-магазина мэппинг будет заключаться в том, что команда пропишет, какие этапы пользователи проходят, начиная с регистрации и заканчивая оплатой покупки, продумает факторы полезности и рассортирует порядок их реализации с учётом приоритетов, технических ограничений и возможностей.
Условно говоря, на этапе регистрации можно добавить возможность регистрации по Сбер ID или Яндекс Паспорту, в поиск добавить фильтр по скидке, а в способы оплаты — возможность оплатить по QR-коду.

Умение составлять и использовать User Story Map продукта помогает интернет-маркетологам находить драйверы и барьеры на пути пользователя, эффективно преодолевать последние и выстраивать маркетинговую воронку. Освоить этот и другие навыки можно на курсе «Интернет-маркетолог» — первые уроки доступны бесплатно.

✅ Простой и понятный способ разложить продукт визуально и увидеть целостную картину. Это способствует лучшему пониманию целей и взаимодействию между командами.

✅ Держит фокус на пользе для пользователей и их потребностях, не позволяя отвлекаться на лишние украшательства и ненужные опции.

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

✅ Упрощает долгосрочное планирование благодаря расстановке приоритетов разных уровней.

✅ Помогает команде быть более гибкой, быстрее адаптироваться к изменениям и оперативно реагировать на меняющуюся картину мира и нужды клиентов.

Рассмотрим подробно этапы создания User Story Map на нашем примере с онлайн-магазином.

Этап 1. Подготовка к созданию карты. Собираем команду и определяемся, в каком виде и с помощью каких инструментов будем создавать User Story Map. Многие команды используют Miro и Figma.

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

Сразу же сортируем их по этапам и процессам: возможность залогиниться через Яндекс относится в процессу регистрации, а оплатить QR-кодом — к оплате товара. Иногда подобные теги позже переносятся в таск-трекер, чтобы команда сразу видела, что к какому этапу относится.

Этап 3. Заполнение пробелов. Критическая оценка запланированных улучшений и заполнение пробелов в них. Если мы делаем регистрацию через Яндекс, почему бы сразу не добавить возможность залогиниться через другие популярные сервисы, например через «Т-Банк» и «Сбер».

Бирюзовые карточки добавлены на этапе заполнения пробелов. Источник: архив эксперта

Этап 4. Определение очерёдности релизов. Очевидно, что одновременно реализовать все запланированные улучшения команда не сможет. Поэтому необходимо определить очерёдность релизов и решить, в каком порядке будем выполнять задачи.

Условно говоря, чтобы добавить оплату в рассрочку, придётся договариваться с банками, это будет долго — пока отложим подальше. Видео в карточках товара тоже пока не сможем сделать: не готов сервер, поэтому чуть отодвинем. А, например, регистрацию через Яндекс и другие сервисы и оплату по QR-коду можем быстро реализовать, к тому же пользователи несколько раз писали, что им не хватает этих опций, поэтому отправляем задачи в первый релиз.

Естественно, чем дальше релиз, тем позже мы делаем эту задачу. Источник: архив эксперта

Этап 5. Приоритизация. Теперь расставляем приоритеты по задачам внутри ближайшего релиза или спринта.

Например, первым делом сделаем новый фильтр, так как в этой задаче мы не привязаны к внешним исполнителям и можем быстро решить её. Затем сделаем оплату по QR-коду, а после займёмся логинами. Это и будет первый релиз.

Как правило, в ближайший релиз ставят наиболее подробно описанные и понятные задачи. Не критично, если в последующих релизах задачи описаны менее чётко: по мере их приближения мы сможем внести ясность. Главное сейчас — распланировать ближайшие задачи.

Получившийся приоритизированный бэклог в идеале и есть результат процесса User Story Mapping. Источник: архив эксперта

Этап 6. Синхронизация с таск-трекером. Такую структуру будет удобно перенести в таск-трекер команды и выполнять задачи в определённом порядке.