Как User Story Mapping помогает проектировать успешные продукты
30 мая 2024
Что отличает успешные цифровые продукты? Прежде всего — детальное понимание того, что нужно пользователям. Один из лучших инструментов для достижения этой цели — User Story Mapping (USM, карта пользовательских историй). Он помогает быстро адаптироваться к изменениям, сократить сроки разработки и сфокусироваться на реальных потребностях аудитории.
В этой статье мы подробно расскажем, почему USM — это новая «таблетка от головной боли» для команд и как он влияет на показатели эффективности, помогая в рекордные сроки достигать бизнес-целей.
В этой статье мы подробно расскажем, почему USM — это новая «таблетка от головной боли» для команд и как он влияет на показатели эффективности, помогая в рекордные сроки достигать бизнес-целей.
Раз, два, три: что такое User Story Mapping
User Story Mapping — это метод разработки, в основе которого лежат короткие описания функций продукта с точки зрения пользователей. С ним можно визуализировать потребности аудитории, разбивать их на конкретные задачи и расставлять приоритеты.
01
Это база
Метод User Story Mapping был разработан в начале 2000-х годов Джеффом Паттоном — опытным консультантом в области разработки программного обеспечения. В своей книге «User Story Mapping: Discover the Whole Story, Build the Right Product» он подробно описал принципы и техники USM, которые помогли создать продукты-лидеры на IT-рынке.
Через визуальное отображение команды рассказывают историю пути клиента, разбивая ее на логические части. Это помогает создавать функционал продукта, который учитывает не только на технические требования, но и важный для клиента результат. Например, для мобильного приложения банка история может звучать так: «Как пользователь, я хочу просматривать баланс своего счета в режиме реального времени, чтобы контролировать свои финансы.»
02
Важно, чтобы проектирование каждой истории могло быть завершено в течение одного короткого временного интервала (или по-другому — спринта).
03
Какие существуют альтернативы
Сколько продуктов, столько и возможных вариантов разработки. Наиболее распространенные — это традиционные технические задания (ТЗ), сценарии использования и UML-диаграммы.
Технические задания (ТЗ) — детальные документы, описывающие все аспекты проекта. Они помогают зафиксировать необходимые требования, но часто превращаются в громоздкие и сложные для восприятия манускрипты.
Сценарии использования подробно показывают шаги, которые пользователь выполняет для достижения конкретной цели. Однако когда проект начинает расти, количество таких сценариев может значительно возрасти, что делает их управление и поддержку затруднительными.
UML-диаграммы предоставляют визуальные модели систем и процессов. Они помогают разработчикам систематизировать информацию. Но за счет своей специфики подобный инструмент может быть слишком сложными для восприятия, особенно если вы не обладаете техническими знаниями.
По сравнению с методами выше User Story Mapping имеет несколько определяющих преимуществ: простота и наглядность, адаптивность и фокус на аудитории, а не на технических аспектах. Однако и у этого инструмента есть свои серые зоны, на которые следует обратить внимание.
Технические задания (ТЗ) — детальные документы, описывающие все аспекты проекта. Они помогают зафиксировать необходимые требования, но часто превращаются в громоздкие и сложные для восприятия манускрипты.
Сценарии использования подробно показывают шаги, которые пользователь выполняет для достижения конкретной цели. Однако когда проект начинает расти, количество таких сценариев может значительно возрасти, что делает их управление и поддержку затруднительными.
UML-диаграммы предоставляют визуальные модели систем и процессов. Они помогают разработчикам систематизировать информацию. Но за счет своей специфики подобный инструмент может быть слишком сложными для восприятия, особенно если вы не обладаете техническими знаниями.
По сравнению с методами выше User Story Mapping имеет несколько определяющих преимуществ: простота и наглядность, адаптивность и фокус на аудитории, а не на технических аспектах. Однако и у этого инструмента есть свои серые зоны, на которые следует обратить внимание.
Плюсы и минусы
Начинаем с хорошего — с преимуществ.
•
Формирование ценности: User Story Mapping помогает командам увидеть свой продукт так, как его видят потенциальные пользователи. Это помогает улучшить процесс разработки и конечный результат.
•
Расстановка четких приоритетов: разделение работы на этапы и планирование позволяют внедрять новые функции последовательно и быстро получать обратную связь от пользователей.
•
Связь с картой пути пользователя: часто карта историй — это упрощенный вариант Customer Journey Map (CJM, карта пути клиента), но даже такая версия дает больше контекста и помогает команде совершенствовать продукт на каждом этапе.
•
Минимизация рисков: благодаря визуализации можно заметить потенциальные проблемы или недостатки в продукте, которые нужно исправить или предотвратить в дальнейшем.
•
Синхронизация команд: процесс создания User Story Mapping происходит при участии многих членов команды. Это облегчает обсуждение наполнения продукта или услуги с самого начала и дает общее представление об опыте потенциальных клиентов.
Четыре красных флага, или в каких ситуациях лучше не применять USM.
Нет четкого представления о клиенте. Если вы не знаете, кто будет использовать ваш продукт, — вы не сможете предугадать, как его воспринят. Понимание аудитории — ключ к составлению карт историй.
01
Нет сформулированной проблемы. Создание карт, направленных на решение неверной задачи, может привести к очевидной трате времени и ресурсов.
02
03
Нет достаточного количества данных. Неполная или некорректная информация привести к созданию карт, которые не отражают реальные потребности пользователей.
Нет гибкости. В отличие от виртуального пространства, если ваша карта составлена только в физическом формате (на доске или стикерах) — может возникнуть проблема с обновлением и актуализацией информации.
04
Тем не менее User Story Mapping остается мощным инструментом для организации и планирования разработки продукта, особенно при правильном применении и учете возможных ограничений.
Отличие от Customer Journey Map
Выше мы упомянули, что User Story Mapping и Customer Journey Map — части одной системы. И это действительно так: оба инструмента могут использоваться совместно при создании продуктов, так как влияют на успешность пользовательского опыта. Рассмотрим основные отличия в таблице ниже.
Таким образом, основное различие между User Story Mapping и Customer Journey Map заключается в их фокусе и целевой аудитории. У USM — это функциональные аспекты продукта, у CJM — эмоциональные и поведенческие. Благодаря чему команды понимают, как клиенты взаимодействуют с продуктом на всех этапах, от начала до конца.
Основные элементы User Story Mapping
Карта состоит из нескольких составляющих и расположена в двух измерениях: вертикальное обозначает приоритет, а горизонтальное — шаги, которые пользователь предпринимает при взаимодействии с продуктом или услугой.
Рассмотрим на примере кейса с Ceramic Pro — интернет-магазина для B2B и B2C клиентов с детальной системой учета товаров и аналитикой покупателей.
Рассмотрим на примере кейса с Ceramic Pro — интернет-магазина для B2B и B2C клиентов с детальной системой учета товаров и аналитикой покупателей.
Скелет (Backbone)
Основа карты, которая служит для построения иерархии пользовательских историй.
В нашем случае с позиции покупателя каркасом для интернет-магазина включает основные активности, такие как «Поиск товаров», «Проверка заказа», «Настройка профиля» и «Оформление заявки».
В нашем случае с позиции покупателя каркасом для интернет-магазина включает основные активности, такие как «Поиск товаров», «Проверка заказа», «Настройка профиля» и «Оформление заявки».
Минимально жизнеспособный продукт (MVP)
Самая простая версия продукта с основными функциями, которые необходимо реализовать для запуска. Это базовый набор пользовательских историй, который позволяет пользователю выполнять необходимые ключевые действия.
Пользовательские истории (User Stories)
Краткие описания функционала или задач с точки зрения пользователя.
Они формируются по единой схеме: Как [тип пользователя] я хочу [действовать], чтобы [получить выгоду].
Как покупатель, я хочу иметь возможность фильтровать товары, чтобы быстрее находить те позиции, которые соответствуют моему бюджету и запросу.
Они формируются по единой схеме: Как [тип пользователя] я хочу [действовать], чтобы [получить выгоду].
Как покупатель, я хочу иметь возможность фильтровать товары, чтобы быстрее находить те позиции, которые соответствуют моему бюджету и запросу.
Эпики (Epics)
Высокоуровневые пользовательские истории, которые можно разбить на более мелкие.
В рамках интернет-магазина крупную историю «Получить необходимые документы и материалы» можно разделить на "Распечатать и загрузить документ с заказом", «Скачать паспорт безопасности продукции» и "Скачать инвойс на оплату" и так далее.
В рамках интернет-магазина крупную историю «Получить необходимые документы и материалы» можно разделить на "Распечатать и загрузить документ с заказом", «Скачать паспорт безопасности продукции» и "Скачать инвойс на оплату" и так далее.
Темы (Themes)
Группы связанных пользовательских историй, объединенные общей целью или функциональностью.
Например, тема «Роли» распределяется на «Обычный пользователь», «Агент», «Аппликатор», «Дистрибьютор», «Ceramic Pro/ Администратор».
Например, тема «Роли» распределяется на «Обычный пользователь», «Агент», «Аппликатор», «Дистрибьютор», «Ceramic Pro/ Администратор».
Действия пользователя (User Activities)
Крупные задачи, которые пользователь выполняет при взаимодействии с продуктом. Или, по-другому, уровни, на которые разделяются на пользовательские задачи.
Возьмем самую простую задачу — заказ продукции. Здесь она будет разделяться на «Выбрать продукцию», «Добавить в корзину», «Выбрать способ доставки», «Выбрать способ оплаты», «Получить подтверждение оформления заказа».
Возьмем самую простую задачу — заказ продукции. Здесь она будет разделяться на «Выбрать продукцию», «Добавить в корзину», «Выбрать способ доставки», «Выбрать способ оплаты», «Получить подтверждение оформления заказа».
Шаги (Tasks)
Конкретные действия, которые пользователи выполняют для завершения активности. Это мелкие, конкретные задачи, которые включаются в пользовательские истории.
«Добавление товара в корзину» — шаг в рамках активности «Покупка товаров».
«Добавление товара в корзину» — шаг в рамках активности «Покупка товаров».
Релизы (Releases)
Наборы пользовательских историй, сгруппированных и спланированных для выпуска в определенные сроки. Это этапы, на которых определенный функционал, от необходимого до второстепенного, внедряются в продукт.
Например, в первый релиз войдут функции «Поиск товаров» или «Оставить заявку на услугу», в последующие — «История заказов» или «Настройка профиля».
Все эти элементы User Story Mapping помогают командам разработки структурировать и управлять задачами, обеспечивая ясное видение проекта и сосредоточенность на наиболее ценных функциях для пользователя.
Например, в первый релиз войдут функции «Поиск товаров» или «Оставить заявку на услугу», в последующие — «История заказов» или «Настройка профиля».
Все эти элементы User Story Mapping помогают командам разработки структурировать и управлять задачами, обеспечивая ясное видение проекта и сосредоточенность на наиболее ценных функциях для пользователя.
Как построить карту
Шаг 1. Подготовка
Прежде чем начать, определите людей, с которыми вы собираетесь строить карту. Составление историй проводится в форме семинара, в котором участвуют ключевые и активные сотрудники из разных отделов. Это могут быть владелец бизнеса, менеджер проекта, UX-дизайнер, маркетинг или бизнес-аналитик. Лучше, если общее количество будет не более 10 человек.
Результат: четкий список участников.
Результат: четкий список участников.
Полезный совет: задавайте вопросы
- Зачем нам нужна эта история?
- Кто будет использовать этот функционал?
- Какие шаги необходимо выполнить для реализации этой истории?
- Как эта история вписывается в общий пользовательский путь?
- Каков приоритет этой истории?
- Какие риски связаны с этой историей?
- Какие метрики мы будем использовать для оценки успеха этой истории?
- Есть ли зависимости между этой историей и другими задачами?
- Как эта история повлияет на общую архитектуру продукта?
Шаг 2. Мозговой штурм
На этом этапе команда собирается для генерации идей и наброска пользовательских историй. Используйте техники, такие как «Что, если», карты эмпатии, или построение сценариев использования. И задействуйте всех участников, чтобы получить широкий пул идей и обозначить горизонт перспектив.
Результат: набор первичных пользовательских историй.
Результат: набор первичных пользовательских историй.
Шаг 3. Группировка действий
После мозгового штурма сгруппируйте пользовательские истории по темам или активностям. Это поможет организовать логическую последовательность. Начните с определения ключевых действий пользователей и расположите их по горизонтальной оси.
Результат: общая структура всей карты.
Результат: общая структура всей карты.
Шаг 4. Заполнение пробелов
Проверьте, что каждая история логически следует одна за другой и покрывает все возможные сценарии использования продукта или услуги. Обратите внимание на мелкие детали и возможные исключения. Определите, насколько подробно вы готовы расписывать истории и давать им дополнительного контекста.
Результат: полная и логически построенная карта с учетом ее масштаба и формата.
Результат: полная и логически построенная карта с учетом ее масштаба и формата.
Шаг 5. Расстановка приоритетов
Расположите наиболее важные истории выше на карте. Используйте критерии, такие как влияние на пользователя, сложность реализации и срочность.
На этом этапе расстановки приоритетов намечаются истории, которые войдут в MVP. Отдельно разработайте отдельный документ с выходами всех релизов. В нем будут определяться сроки выхода каждой версии продукта без детализации технических деталей.
Результат: карта пользовательских историй с расстановкой приоритетов, а также с акцентом на наиболее важные и ценные функции.
На этом этапе расстановки приоритетов намечаются истории, которые войдут в MVP. Отдельно разработайте отдельный документ с выходами всех релизов. В нем будут определяться сроки выхода каждой версии продукта без детализации технических деталей.
Результат: карта пользовательских историй с расстановкой приоритетов, а также с акцентом на наиболее важные и ценные функции.
Шаг 6. Проверка
Заново изучите каждую историю и убедитесь, что карта актуальна и в ней учтены все ключевые аспекты. Не забывайте вовлекать пользователей для получения обратной связи и внесите необходимые корректировки.
Результат: готовая к использованию карта.
Результат: готовая к использованию карта.
Лайфхаки от экспертов
Помните, что User Story Mapping — это не статичный инструмент. Со временем она будет меняться и подстраиваться под новый вид продукта или услуги.
Чтобы она оставалась актуальной, используйте маркеры статуса:
Чтобы она оставалась актуальной, используйте маркеры статуса:
•
сделать (to do),
•
готово (done),
•
в процессе тестирования (test),
•
ревью (review),
•
удалить (remove).
Они дают понять, что происходит с продуктом и какая часть работы уже выполнена.
Также учитывайте возможные риски в формате коротких примечаний или комментариев на карте. Почему стоит это делать? При разработке продукта мы основываемся на предположении, что каждая функция нужна пользователю. Но при разработке могут возникнуть такие риски как интеграция со сторонним решением или зависимость от нестабильного сервиса. Поэтому размещение таких заметок на карте помогает держать информацию в поле зрения всей команды и, возможно, сэкономит ее бюджет.
Также учитывайте возможные риски в формате коротких примечаний или комментариев на карте. Почему стоит это делать? При разработке продукта мы основываемся на предположении, что каждая функция нужна пользователю. Но при разработке могут возникнуть такие риски как интеграция со сторонним решением или зависимость от нестабильного сервиса. Поэтому размещение таких заметок на карте помогает держать информацию в поле зрения всей команды и, возможно, сэкономит ее бюджет.
Все обо всем: короткое саммари
User Story Mapping (USM): метод визуализации пользовательских историй в разработке продуктов, который помогает командам лучше понять и сфокусироваться на потребностях аудитории.
01
Альтернативы USM: традиционные ТЗ, сценарии использования и UML-диаграммы предоставляют информацию, но они не такие простые и гибкие, как USM.
02
Преимущества USM: помогает формировать ценность для пользователя, расставлять приоритеты, улучшать пользовательский опыт, выявлять риски и синхронизировать команду.
03
Риски USM: недостаточное представление о клиенте, несформулированная проблема, отсутствие данных и возможные ограничения в визуализации.
04
Основное отличие от Customer Journey Map (CJM): USM сосредотачивается на функциональных аспектах продукта, в то время как CJM — на эмоциональных и поведенческих аспектах пользовательского опыта.
05
Комментарии к статье
Комментарии: 0