User story mapping на практике
Вы уверены, что общая картина проекта одна из самых ценных задач для UX? И думаете, что она не появится без совместного участия команды разработки и команды продукта со стороны бизнеса?
Тогда вам, скорее всего, знаком метод создания карты пользовательских историй (User story mapping). Поделюсь опытом, как мы используем его при разработке продуктов в студии Molinos.
Для тех, кто считает, что время на разговоры тратятся впустую предлагаю выполнить короткое упражнение: попросите группу людей нарисовать на бумаге дом за одну минуту. На выходе у каждого будет свой рисунок с домом.
Взгляните, каких только домов вы не встретите: большие окна в пол, изогнутые стены, цветы на крыше и с гаражом сразу на три машины. Часто у нас у всех уникальное представление чего-либо. Это классно, но в разработке нужно уметь работать с этим на пользу проекту.
А еще, жизненно необходимо, чтобы все в команде разработки понимали, над чем и как мы работаем, а также как именно наши задачи вписываются в общую картину проекта.
И чтобы эта картина появилась, нужно выделять время на ее формирование и на то, чтобы все участники одинаково ее понимали.
Три важных преимущества юзер стори мэппинга, помимо простоты техники, отчуждаемости результата и эффективности самого процесса:
- Пользовательские цели
Можно сфокусироваться и взглянуть на них глазами тех, кто будет пользоваться продуктом. Если игнорировать это и обсуждать только функционал, то появится пропасть между разработчиками и ценностью будущего продукта для конечных потребителей. - Последовательная история
Без общей картины продукта пользовательский флоу получится фрагментарным и можно упустить какие-нибудь важные шаги. Последовательная история на карте убережет от этого. - Визуализация
Дискуссия между командой продукта и разработки бесценна, она и есть ключ к единому пониманию. На выходе вы получите визуализированный результат, учитывающий разные точки зрения и уникальные взгляды на решения задач, который можно повесить на стену рядом со всей командой или выгрузить в онлайн для распределенных команд.
Из чего состоит карта?
Визуально простая структура с которой удобно считывать информацию:
- В самом верху роли пользователей,
- Под ними цели, которые пользователи преследуют при взаимодействии с продуктом,
- Ниже конкретные действия, что обеспечивают достижение целей,
- Далее действия декомпозируются на шаги, которые необходимо реализовать, чтобы указанные действия можно было совершить.
Горизонтальная ось отвечает за логическую последовательность повествования. Например, чтобы написать комментарий, пользователю нужно зарегистрироваться. Вертикальная ось для приоритизации, чем выше, тем важнее для бизнес-целей продукта.
Помимо обязательных составляющих, карта может содержать дополнительную информацию по продукту: тезисы из результатов исследований ЦА, технические вопросы, эскизы пользовательского интерфейса и т.д. Например, мы используем Realtimeboard за удобную систему комментариев и стикеров.
Цели и действия это верхнеуровневые сущности, они образуют сам продукт. У нас в студии, действия по уровню декомпозиции равны эпикам, а шаги пользовательским историям, которые разработчик может раскладывать на задачи и брать в работу.
Шаг может быть задачей технического плана, когда система совершает какое-то действие. Но не стоит углубляться на карте в технические детали, расписывая пошагово интеграцию с каким-нибудь сервисом. Если что-то вызывает много обсуждений, скорее всего, оно требует дополнительной декомпозиции. Еще бывает, что-то отмечается, как шаг, но позже оказывается самостоятельным действием пользователя со своими шагами.
Очень важна взаимосвязь и последовательность всех сущностей на карте. Они должны образовывать единое повествование. Если нет, значит у продукта есть пробелы, которые в будущем приведут к плохому пользовательскому опыту.
Как построить?
1. Подготовка
- Определитесь с тем, где будете строить карту: онлайн сервис или обычные клеящиеся стикеры и стена.
- Хотите единого понимания? Соберите представителей бизнеса и разработки: менеджер продукта, менеджер проекта со стороны разработки, аналитик, технический и дизайн лиды, возможно кто-то из разработчиков и т.д.
- Заранее тяжело зафиксировать длительность воркшопа, но если на составление первой версии карты вам требуется больше двух рабочих дней, то это признак того, что концептуальный уровень продукта плохо проработан на стороне бизнеса.
- Подготовьтесь к фасилитации воркшопа, чтобы остальным участникам было проще фокусироваться на работе.
2. В начале воркшопа
- Предложите менеджеру продукта поделиться пониманием, как бизнес представляет будущий продукт, еще раз пройдитесь по бизнес-целям, существующим ограничениям в реализации и т.д.
- Если у UX специалистов уже есть инсайты ЦА на основе результатов аналитики, пусть они поделятся ими.
3. Мозговой штурм
Начинайте с вопроса: Что бы пользователь сделал с продуктом? Выделите время, чтобы каждый самостоятельно ответил и записал результат.
- Подумайте о действиях, которые пользователь может совершать в продукте (в идеале, это действия, которые можно совершать без переключения).
- Старайтесь использовать глаголы при описании этих действий.
- Подумайте, как изменится флоу использования продукта для пользователей с другими ролями (например, администрация).
Спустя минут 10 начните совместное обсуждение результатов. Необходимо прийти к единому флоу, действия которого понятны всем участникам.
4. Придумайте цели и задачи, соотнесите их друг с другом
Будет классно, если на этом шаге будет как можно больше обсуждений, чтобы все не только пришли к единому флоу, но и прониклись им, разделяли его.
- Первым делом, скомпонуйте похожие заметки. Какие-то из них потребуется переформулировать,
- Сгруппируйте их так, чтобы действия соответствовали конкретным ролям пользователей,
- Каждое полученное действие должно преследовать конкретную цель. Расположите цели над действиями,
- Полученные цели и действия есть наш вероятный флоу продукта. Проверьте, чтобы расположение действий соответствовало логической последовательности использования продукта,
- При чтении слева-направо, у вас должна получится единая история использования. Расскажите её вслух, чтобы понять, не упустили ли вы чего.
Иногда, действия могут приводить сразу к нескольким целям. Это нормально, размещайте их в той группе, где у них наибольшее влияние.
5. Декомпозируйте на шаги
Самая длительная часть. Каждое действие нужно декомпозировать до шагов, которые вместе приведут пользователя к выполнению желаемой активности.
Прежде, чем обсуждать каждое действие совместно, выделите время для самостоятельной проработки. Этот процесс может занять много времени, поэтому контролируйте тайминг. Именно декомпозиция действий способствует генерированию идей по возможностям достижения целей и помогает всем прийти к единому видению.
Как записывать шаги на карту? Готово шаблона нет.
- Использование глаголов при написании помогает концентрироваться на пользовательском действии (а не на конкретных функциях, что исключает возможность поиска лучших решений).
- Уровень декомпозиции примерно, что и у пользовательской истории, которую можно разработать в течении 1 спринта (если длина спринта не менее 2 календарных недель).
На этом этапе карта становится все больше и больше, причем иногда в неожиданной для вас части. Это не значит, что растут размеры самого продукта, растет ваше понимание его.
6. Приоритезируйте
Кажется, что сделать это просто, но обычно эта часть вызывает множество споров :) Расставьте стикеры с шагами по вертикальной оси в порядке приоритета для бизнес-целей.
7. Задавайте этапность
Теперь на карте есть цели, действия, шаги и приоритетность. Определите этапность реализации, что попадет в первый релиз, будет ли у вас MVP и т.д. Важно, чтобы каждый релиз помогал достигать определенных бизнес-целей.
Используйте горизонтальную линию, чтобы отделять релизы. Над линией, что сделаете в этом релизе. Под, что пойдет в следующий.
Скорее всего, к этому моменту команда будет утомлена, подбодрите всех участников и объективно взгляните на полученный результат. Например, проверьте все действия на соответствие поставленным перед продуктом бизнес-целям и вообще на реализуемость (в разумных пределах, поскольку это не полноценный технический анализ).
8. Проведите ревью
Вместе еще раз проверьте весь флоу: каждый шаг соотнесен с действием, которое соответствует конкретной пользовательской цели. Все это имеет последовательное повествование.
9. Используйте карту
В идеале, распечатать карту и повесить на стене, чтобы команда всегда могла увидеть результат совместного обсуждения. Есть классный Agile термин — «информационный излучатель» (придуманный Alistair Cockburn). Так вот карта как раз им и является, распределяет знания, укрепляя общее понимание продукта командой.
Если есть идеи, как можно использовать User story mapping продуктивнее — смело пишите. Реально интересен сторонний опыт, так как в рунете практической информации маловато.
