User Story Mapping - это способ перестать управлять списком задач и начать управлять пользовательской ценностью.
Обычный бэклог - это набор разрозненных фич: «добавить СБП», «сделать поиск», «улучшить сортировку».
Но без понимания пользовательского пути сложно ответить на главный вопрос: что реально важно сейчас?
User Story Mapping помогает:
- увидеть продукт целиком через путь пользователя
- собрать действительно Minimum Viable Product (MVP)
- осознанно формировать релизы
- снизить хаос и споры о приоритетах
Это инструмент, который переводит разговор с «какую фичу делаем?» на «какую ценность даём пользователю?».
Разберём, как провести воркшоп по созданию User Story Map.
1. Подготовка к воркшопу
Участники
Нужны все кто участвует в создании ценности, т.к. каждый их них даёт ценные инсайты для декомпозиции Пользовательских историй.
На практике обычно участниками являются:
- Product Owner / Product Manager
- Разработчики
- Аналитики
- Дизайнеры
- QA-инженеры
- Фасилитатор, если команда ещё не научилась сама проводить такой воркшоп
Оптимально: 5–8 человек. Если у вас больше участников можно параллелить процесс
Рассмотрим User Story Mapping на примере личного кабинета клиента мобильного оператора
2. Определяем цели пользователя (верхний уровень)
Начинаем не с фич, а с целей клиента.
В нашем примере это:
- Пополнить баланс
- Сменить тариф
Это два разных пользовательских сценария. Их нужно разместить в верхней части карты.
3. Строим Backbone (позвоночник): шаги пользователя
Теперь под каждой целью описываем шаги пользователя в хронологическом порядке.
Пример: Пополнить баланс
- Выбрать номер для пополнения
- Ввести сумму
- Оплатить
Пример: Сменить тариф
- Выбрать тариф
- Узнать условия тарифа
- Вернуться к выбору
- Сменить тариф
Важно:
- Формулируем шаги как действия пользователя.
- Не уходим в реализацию.
- Держим логику слева направо.
4. Формируем Walking Skeleton / MVP
Теперь самый важный момент.
Какая самая минимальная и простая реализация каждого шага позволит пользователю пройти путь от начала до результата?
Нормально, если можно даже некоторые шаги пропустить.
Это так называем ходячий скелет - т.е. не полноценный продукт, но ходить уже может. Например покрывает Success Path для 80% пользователей
MVP должен:
- позволять пройти весь путь
- быть рабочим сквозным сценарием
- не быть идеальным
5. Добавляем мяса мышцы
Теперь смотрим ниже MVP и задаём вопросы:
- Как мы можем сделать удобнее для пользователя
- Что увеличивает конверсию и другие метрики?
Принципы:
- одна карточка - одна способность системы
- без технических деталей
- фокус на ценности
Пример: «Выбрать номер»
- Ручной ввод номера
- Валидация номера по маске
- Проверка существования номера в базе
- Выбор номера из списка клиента
Пример: «Оплатить»
- Оплата по реквизитам карты
- СБП
- ЮMoney
- VK Pay
- Обещанный платёж
На этом этапе вы получаете полную карту продукта, но ещё не MVP.
6. Формируем релизы
После MVP вы делаете следующие горизонтальные срезы - релизы.
По большому счёту упражнение похоже на формирование MVP, вы просто смотрите какие следующий наиболее ценные Пользовательские Истории можно и нужно поставить клиентам.
Каждый релиз - это рабочая версия продукта, а не набор технических задач.
Как фасилитировать воркшоп
Правила
- Не обсуждаем техническую реализацию.
- Не спорим про приоритеты до построения полной карты
Типичные ошибки
❌ Начинают с API и баз данных
❌ Путают шаги пользователя и системные операции
❌ Сразу спорят, что важнее
❌ Делают MVP как «кусок одного шага»
Как понять, что карта сделана правильно
Проверьте три вещи:
- Пользователь может пройти сценарий слева направо
- MVP - это рабочий сквозной путь
- Каждый следующий релиз улучшает опыт, а не чинит базу
Итог
User Story Mapping (USM) - это способ проектировать продукт через поведение пользователя, а не через список требований.
USM повышает прозрачность для всей команды и всех заинтересованных лиц.