User Story Mapping
User Story Mapping – простой метод визуализации пользовательских историй и проектирования продукта. Составляя карту, мы как будто делаем раскадровку шагов или функций, которые выполняет пользователь.
User story mapping поможет выделить ценные функции с точки зрения пользователя и приоритизировать бэклог. Сначала user story mapping поможет с пониманием MVP, а потом можно прикручивать остальные фичи и улучшать сценарий пользователя хоть в режиме non-stop.
Как картировать опыт?
1) Выстройте шаги пользователя в вашем продукте в логическую последовательность. Используйте реальный сценарий. Например, найти товар>выбрать нужную категорию товаров>посмотреть товары со скидкой>ознакомиться с товаром>проверить срок годности>положить в корзину>оплатить.
3) Заполните пробелы в сценарии. Дополните каждый этап шагами или функциями, которых не хватает и хорошо бы добавить. Например, этап «Поиск товара» можно дополнить фильтрами или функцией «Добавить в избранное».
4) Приоритизируйте бэклог. Внутри каждого этапа выделите must have функции продукта и поместите их вверх. Вниз поместите приятные фичи, которые хорошо бы сделать, но пока продукт может обойтись и без них.
Где картировать опыт?
В Miro или на стене со стикерами.
Если ваши пользователи из нескольких сегментов, то сделайте USM под каждую группу пользователей. Удобно иметь карту под рукой и добавлять туда стикеры с идеями по доработке продукта. User Story Mapping – универсальный инструмент, который можно использовать вечно, если поддерживать актуальность карты.
User Story Mapping | Планирование релизов при помощи карты историй
Такая вещь как “бэклог” в Скраме — это список пользовательских историй, которые команде предстоит реализовать, расставленных по приоритету. Такая система отлично помогает организовать работу команды на ближайшую перспективу, к примеру, во время планирования спринта. На одной из встреч по Скраму в Орландо Джефф Паттон описал метод составления карты историй. Это способ организации историй, который дает более широкий контекст и помогает в планировании релизов.
Интересуетесь свежими статьями по дизайну? Вступайте в группу на Facebook.
Джефф не первый раз рассказывает о картах историй. Он уже писал об этом в 2005 и в 2008. Во время встречи по Скраму в Орландо, в ходе открытой сессии Джефф поделился своими свежими наработками по этому методы. Продуктовый бэклог — в сущности достаточно ограниченный инструмент. Пользовательские истории в нем расставлены по приоритету: высшего к низшему. А карта истории работает сразу в двух изменениях: показывает не только приоритет историй, но и то, как они связаны между собой и с более крупными задачами пользователей. Карта помогает команде понять, как можно скомпоновать истории, чтобы получить продукт, готовый к релизу.
Процесс начинается с того, что мы даем определение пользователям системы и перечисляем действия, которые они будут осуществлять. В своей статье 2005 года Джефф приводит пример софта для розничного магазина. Основные действия пользователей в этом примере следующие:
Майк Кон называет такой список действий “эпиками” (epics), а Джефф — хребтом карты историй. Эти действия описывают, не вдаваясь в подробности, всё, с чем система должна помочь пользователю. Записываем действия на карточках и выстраиваем слева направо в такой последовательности, как они обычно случаются в реальности. Джефф рекомендует расставлять действия в том порядке, в каком вы упоминаете их, когда рассказываете человеку со стороны про ваш бизнес.
Под каждым действием размещаем связанные с ним пользовательские истории — причем, чем важнее история, тем выше мы ее размещаем. Итак, на нашем хребте появились ребра. Каждая история ассоциируется с определенным действием пользователя и имеет приоритет. Чтобы визуально представить план релиза, нарисуем горизонтальную линию слева направо. Истории над линией войдут в релиз, а те, что ниже линии — нет. На самом деле, так можно планировать несколько релизов, разделяя карту на этакие “плавательные дорожки”.
А какие техники или инструменты используете вы, чтобы планировать релизы и при этом учитывать контекст, в котором существуют истории. Оставляйте комментарии и делитесь статьей.
Если вам понравилась статья и перевод, дайте нам знать — нажмите 👏 (можно “хлопать” несколько раз!)
А если у вас есть на примете какая-нибудь классная статья по UX и не только — скиньте нам ссылку, и мы будем рады над ней поработать.
Мобильное приложение «Заметки о психике» | Mental Notes
Подкидывает идеи как привлечь, удержать и направить внимание пользователя
Mental notes — это колода из 53 карточек с описанием психофизиологических моделей поведения людей, которые лежат в основе принципов веб-дизайна. Они помогают дизайнерам, проектировщикам лучше понять поведение пользователей и найти эффективные решения при создании дизайна интерфейсов.
Как построить карту историй (user story mapping), если проект уже в работе
(Мы продолжаем переводить цикл статей по продуктовому дизайну. Полную подборку можно найти в коллекции « Инструменты продакта»)
Если вы читали пост Дэвида про story mapping, то, скорее всего, загорелись идеей попробовать новый метод на практике. Обычно в этот момент начинают выползать самые разные страхи и сомнения.
Скорее всего вы думаете: “Проект уже запущен, неужели нужно все начинать сначала? И выбросить на ветер всю проделанную работу?” И вот вы все размышляете, как story mapping мог бы усилить ваш проект, и стоит ли оно того…
Что ж, ребята, хорошие новости! Даже если ваш проект уже в работе, вы все еще можете воспользоваться методом story mapping. Честно. Конечно, придется поработать, но оно того стоит.
Интересуетесь свежими статьями по дизайну? Вступайте в группу на Facebook.
Ищите системное погружение в тему? Загляните в блог для дизайнеров.
Шаг 1. Строим карту (story map)
Начните с того, что имеете
Для начала, соберите в кучу те пользовательские истории, которые у вас уже есть. Изучите истории, над которыми сейчас работают другие команды и поместите их на свою доску. Только пообещайте, что не будете воровать у них карточки: перепишите все по-честному на новые карточки. Если вы используете JIRA, VSTS/TFS или какой-то другой инструмент, просто распечатайте все свои тикеты. Да, даже закрытые (поймете, зачем они нужны, когда мы дойдем до шага “Заполнить пробелы”).
Далее, нужно рассортировать истории по группам, чтобы при необходимости вы быстро могли найти нужную. Не очень-то удобно перебирать стопку из 150 карточек в поисках той самой истории.
Сразу предупреждаю: пользовательские истории обычно бывают фичами/существительными, а нам для построения карты историй нужны глаголы/действия/шаги. Поэтому не стоит брать за основу существующий бэклог: лучше начать с создания простейшей карты пути пользователя.
Создайте карту пути пользователя (journey map)
Эта карта (journey map) будет скелетом карты историй (story map). Вам будет проще, если вы начнете работать с укрупненной картой пути пользователя, пока не вдаваясь в детали. Наша первая цель — наметить общий маршрут.
Возьмите пачку стикеров, маркер и изоленту и забейте кусок стены. Для начала спросите себя: какой путь проходит пользователь в продукте? С чего он начинает? Самый простой подход — взять за основу путь основного персонажа. Каждый шаг пути мы будем писать на отдельном стикере.
Используйте существующие тикеты
Если вам встретятся какие-то шаги, которые уже есть в карточках пользовательских историй, не дублируйте их на стикерах, а просто приклейте карточки на скотч. Возможно, большинство шагов у вас уже есть. Если так, круто.
Вот так будет выглядеть ваша карта. Белые карточки — это распечатанные пользовательские истории из физического бэклога или из JIRА. Цветные квадратики — это новые стикеры.
Заполните пробелы
Скорее всего вы обнаружите пробелы в вашей карте историй. Или может оказаться, что вы упустили некоторые важные действия, шаги или мелочи, которые любят всплывать перед самым релизом.
Тут-то и происходит все волшебство. Проблема бэклога на 150 тикетов в том, что все они разные по размеру и очередности. Здесь мы берем за основу 150 историй и равномерно распределяем по пути пользователя. С таким подходом легко обнаруживаются проблемные места. Вещи, которые мы считали никак не связанными, на самом деле оказываются взаимозависимыми. Мы обнаруживаем небольшие истории, которые можно объединить и легко закрыть в пределах одного спринта — и создать полезную фичу.
Как только соберете всю карту, начните искать темы, или, как мы называем их, “действия”. Это такие большие задачи, которые может осуществить пользователь и которые могут включать множество шагов. Сюда относятся такие крупные вещи, как “управлять письмом” или “обновить”.
Определите состав “релиза”
Да, релиз в кавычках. Все потому, что мы хотим разделить планирование и релизы. Слово “релиз” — это просто понятие, которое я использую чтобы разграничить интервалы планирования. Можете называть это “маркетинговыми релизами” или точками отсчета. Это не обязательно физические релизы. Вы можете постоянно совершенствовать продукт и копить “релизы”, а потом выпустить все большим блоком. Или вы можете потихонечку, без огласки выпускать мелкие улучшения и постепенно тестировать их на пользователях. Не важно какой вариант вы выберете, главное, чтобы он подходил вам и команде.
Итак, для начала убедимся, что этапы по каждому шагу расставлены по приоритету: маст-хэв опции должны быть сверху, а приятные мелочи — снизу. Затем возьмите изоленту и разметьте, какие этапы войдут в состав первого “релиза”.
Если вам кажется, что в таком виде ничего не понятно, можно провести изолентой прямую линию и разместить все, что не вошло в первый релиз, под линию. Примерно так:
Шаг 2. Упорядочиваем хаос
Очень важно правильно организовать карту, чтобы вы могли ее читать. Просто слова на стене выглядят слишком хаотично. Нужно, чтобы на основании карты вы могли рассказать простую историю, вдаваясь в детали только при необходимости, если это важно.
Эпик vs. История vs. Задача
Итак, действия в верхнем ряду считаются эпиками, “шаги” — историями, а то, что ниже — задачами? Или верхний ряд это что-то еще, а шаги — это эпики, а опции — истории? Короче, это не важно. Делайте так, как удобно вашей команде и как правильнее для вашего продукта. Если “шаги” можно завершить в рамках одного спринта, то они ближе к историям. А если они огромные и могут растянуться на 2–3 спринта — то это скорее эпики. Повторюсь, делайте так, как лучше вашей команде.
Цветовое кодирование персонажей
Цветовое кодирование пригодится, если вы разрабатываете продукт под разные сегменты пользователей или под разных персонажей. К примеру, вы создаете решения под веб, мобильные устройства и обращения по телефону. Цветные стикеры помогут внести ясность и сегментировать карту, как на рисунке ниже. На распечатанных тикетах можно ставить цветные точки. Не забудьте добавить легенду, чтобы ваша система кодирования была понятна всем и сразу.
Поддерживаем актуальность карты
Как и все в этом мире, карта со временем теряет актуальность. Нужно обновлять вашу карту историй на протяжении всего проекта. Когда вам в голову придут новые шаги и детали, добавляйте их на карту, обновляйте приоритеты, показывайте прогресс. Отличный способ продемонстрировать прогресс — отмечать сделанные карточки яркой галочкой.
Ну, вот и все. Несколько простых шагов — и вы превратили переполненный бэклог в живой ресурс, по которому ваша команда и все заинтересованные лица могут отслеживать развитие проекта. И все это мы сделали, когда проект был уже в работе! Надеюсь, это поможет вам и вашей команде создать более качественный продукт и реализовать правильные функции — на каком этапе работы вы бы ни находились.
Если вам понравилась статья и перевод, дайте нам знать — нажмите 👏 (можно “хлопать” несколько раз!)
А если у вас есть на примете какая-нибудь классная статья по UX и не только — скиньте нам ссылку, и мы будем рады над ней поработать.
Мобильное приложение «Заметки о психике» | Mental Notes
Подкидывает идеи, как привлечь, удержать и направить внимание пользователя.
Mental notes — это колода из 53 карточек с описанием психофизиологических моделей поведения людей, которые лежат в основе принципов веб-дизайна. Они помогают дизайнерам, проектировщикам лучше понять поведение пользователей и найти эффективные решения при создании дизайна интерфейсов.
Как устроена концепция “User Story Mapping” и как интегрировать карту историй с Канбан-доской программистов
Чтобы начать запускать проекты по системе Канбан, проектная команда должна переосмыслить привычных способ учета требований и шагнуть в сторону более структурированного подхода. Для начала крупномасштабные проекты нужно разложить на функции, с каждой из которых мы будем работать независимо.
Интересуетесь свежими статьями по дизайну? Вступайте в группу на Facebook.
Ищите системное погружение в тему? Загляните в блог для дизайнеров.
Во многих организациях требования к продукту изложены в виде формального документа. Обычно бывает так:
У нас был достаточно интересный опыт использования карт историй, чтобы помочь командам справиться с трудностями, которые они обычно возникают при работе со стандартным документом с требованиями. Мы интегрировали метод карты историй с Канбан, чтобы команды с первого дня использовали гибкий подход к работе.
1: Создание функций — это совместное упражнение, в ходе которого проектная команда и все заинтересованные лица составляют список функций и формируют последовательность событий, которые несут ценность с точки зрения пользователей.
2: Функции, соответствующие каждому действию, располагаются по приоритету.
После того, как мы расставили функции по приоритету, команда может приступить к созданию MMF-ов ( Minimum Marketable Feature ( MMF)— минимальный состав продукта, ценный для потребителей). Для этого “разрезаем” карту горизонтальными линиями.
3: Расставленные по приоритету функции и MMF-ы из карты историй можно использовать для наполнения Канбан-доски.
Процесс составления карты историй помогает команде увидеть всю картину и рамки проекта. В результате, эта техника помогает проектным командам комплексно планировать функции и релизы с учетом всего проекта целиком.
Если вам понравилась статья и перевод, дайте нам знать — нажмите 👏 (можно “хлопать” несколько раз!)
А если у вас есть на примете какая-нибудь классная статья по UX и не только — скиньте нам ссылку, и мы будем рады над ней поработать.
Мобильное приложение «Заметки о психике» | Mental Notes
Подкидывает идеи как привлечь, удержать и направить внимание пользователя
Mental notes — это колода из 53 карточек с описанием психофизиологических моделей поведения людей, которые лежат в основе принципов веб-дизайна. Они помогают дизайнерам, проектировщикам лучше понять поведение пользователей и найти эффективные решения при создании дизайна интерфейсов.
О важности User Stories
Здравствуйте, уважаемые читатели.
Сегодня мы хотели бы поговорить с вами о важном аспекте гибкого управления проектами, но не о чистом Agile, а о планировании проекта и итераций. Речь пойдет о жанре «Пользовательских историй», которым посвящена очень успешная на Западе книга Джеффа Паттона с предисловием Мартина Фаулера:
В статье, текст которой вас ждет под катом, мы перевели «User Story Mapping» как «визуализация функционала». Вариант взят из очень интересной книги Бориса Вольфсона «Гибкое управление проектами и продуктами», также выходившей в нашем издательстве.
Итак, автор статьи прочитал труд Паттона и решил, что так должен поступить каждый. Насколько убедительные примеры он привел — судить вам.
Одна из ключевых целей при планировании проекта – общими усилиями собрать требования. Но зачастую бывает сложно решить, с чего начать и на чем сосредоточиться. Визуализация функционала (story mapping) – увлекательная работа, где все члены команды участвуют в формировании списка требований (бэклога) – расклеивают карточки на стене, а не пишут скучную 100-страничную спецификацию.
Такой способ визуализации функционала изобрел Джефф Паттон, а мне об этом рассказал Шираг Доши. Я считаю, что это очень эффективный и полезный способ фиксации требований на этапе продумывания проекта.
Чертим карту функционала
Визуализация функционала — это нисходящий способ сбора требований, которые представляются в древовидной форме. Перед началом визуализации нужно обрисовать себе весь проект целиком. Для этого расставляются цели. Для достижения цели нужно выполнить те или иные действия. А для выполнения действия пользователь должен решить задачу. При разработке ПО конкретные задачи могут быть сформулированы в виде пользовательских историй.
Структура карты: Цели — Действия — Задачи — Истории
Рассмотрим для примера приложение для работы с интернет-магазином, в рамках обращения с которым выделим конкретную цель:‘найти товар’. Чтобы лучше понять весь процесс, визуализируем этот функционал на карте.
Достичь цель ‘найти товар’ можно несколькими способами, например, ‘просмотреть дерево с каталогом товаров’, ‘воспользоваться текстовым поиском’, ‘посмотреть промо-товары’. Остановимся на втором варианте – «просмотрим дерево с каталогом товаров» и визуализируем такой функционал. ‘
Далее, чтобы добраться до желаемого товара, пользователь должен выполнить определенные задачи,
А теперь эти задачи можно сформулировать в виде пользовательских историй и перейти к разработке программы.
Так и продолжаем подробно прорабатывать каждую ветку функционала, начиная с целей и достраивая целостную карту. По моему опыту, на полную визуализацию функционала может уходить от трех дней до двух недель в зависимости от размера и сложности проекта.
Для справки: вот «ветка» из одной визуализации функционала, взято из реального проекта,
А вот как выглядит вся карта после пяти дней работы:
Итак, разобравшись с визуализацией функционала, давайте обсудим, каковы достоинства такого подхода.
Преимущества визуализации функционала
Обогащаем получившуюся карту дополнительной информацией
Иногда требуется зафиксировать на карте проекта сравнительно много информации – например, пометить вопросы, возникшие в ходе работы, альтернативные подходы… все это также попадает в визуализацию. Вот несколько практических примеров:
На маленьких стикерах ставим пометки, записываем предположения, предварительные выводы или вопросы
Альтернативные способы визуализации функционала
При визуализации функционала важно сначала определиться со структурой, а затем дорабатывать ее по мере необходимости. Необходимо уже в самом начале работы представлять себе структуру проекта и отталкиваться от нее. Иногда целостная структура получается только спустя две-три итерации.
Один вариант альтернативной структуры называется‘пользовательские путешествия’. Такой подход помогает определиться с требованиями с точки зрения пользователя – например, покупателя, продавца, администратора, т.д. В таком случае визуализация приобретает вид Пользователь — Цели — Путешествия — Действия — Истории.
Другая альтернатива, особенно при разработке NFR (нефункциональных требований) может быть такой:
NFR — Требование — История.
Полная карта больших проектов может содержать до шести уровней. Однако в типичном проекте обычно достаточно 3 уровней.
Подготовка к визуализации функционала
Итак, вы твердо намерены начинать следующий проект с визуализации функционала. Вот что для этого потребуется:
Визуализация функционала – эффективный механизм продумывания требований к проекту, поскольку он очень нагляден. Такой подход помогает прийти к общему пониманию проблемы, выделить имеющиеся пробелы в бэклоге, уловить взаимозависимости, точнее оценить относительные размеры этапов проекта. В дальнейшем такая визуализация помогает правильно сегментировать проект и адекватно спланировать время на подготовку всех релизов.