Карты пользовательских историй помогают Agile-командам определять приоритетные элементы для разработки, а также визуально отображать, как отдельные составляющие продукта сочетаются друг с другом. Они направляют итеративный процесс разработки продукта и помогают учитывать интересы пользователей при обсуждении идей, а также расставлять характеристики продукта в приоритетном порядке.
В рамках традиционного процесса разработки Agile-команды (команды специалистов, работа которых ведется по принципам Agile) зачастую полагаются на длинные и чрезмерно подробные документы, которые содержат информацию о бенес-требованиях и функциональных дизайн-спецификациях . Эти документы используют в качестве основы для перехода от концепции цифрового продукта к конкретному пониманию того, что он должен в себя включать и как работать. Команды полагают, что вместо того, чтобы тратить время на обсуждение интересов и потребностей пользователей, можно просто использовать подобную документацию.
Однако такой подход чаще всего не слишком эффективен. Чтобы тщательно изучить документы, необходимо время, которого зачастую и так не хватает. Даже те члены команды, которые прочитали их от начала до конца, скорее всего, получат совершенно разное представление о том, что им следует разрабатывать. Вместо того, чтобы способствовать повышению продуктивности команды, сложная для восприятия документация изначально подавляет творчество, мешает коммуникации и взаимодействию, а также препятствует креативному мышлению. В таком случае более эффективной альтернативой являются карты пользовательских историй — это упрощенное представление цифрового продукта, созданием которого занимается Agile-команда.
1. Что такое карты пользовательских историй
Определение: Карты пользовательских историй (также известные как карты историй) — это метод бережливого UX для описания пути пользователя, популярный среди Agile-команд. Данный метод предполагает использование стикеров для обозначения ожидаемых взаимодействий пользователя с цифровым продуктом в процессе достижения его целей.
Данный метод получил свою известность благодаря Джеффу Паттону. Карты пользовательских историй способны заменить длительный процесс составления списка технических требований и этапов доработки продукта, требующих особого, характерных для каскадной модели разработки. Карты историй стимулируют взаимодействие между членами Agile-команды, а также позволяют им увидеть более полную картину того, как функционирует цифровой продукт в целом и как его элементы сочетаются друг с другом. Последнее особенно важно в Agile-проектах, поскольку потеря общего представления о продукте — распространенная проблема, возникающая в командах, которые работают со списком отдельных пользовательских историй.
Карта пользовательской истории отображает 3 типа действий разной степени детализации: действия (в общем смысле), шаги и детали (конкретные действия). Действия и шаги пользователя отображаются горизонтально в верхней части карты, а детали — вертикально, под соответствующими шагами в приоритетном порядке. Чтобы показать каждый уровень карты истории, мы будем использовать в качестве примера функцию депонирования чеков (внесение средств с чека на счет) в мобильном приложении.
- Действия представляют собой наиболее общие задачи, которые пользователь стремится выполнить в цифровом продукте, например, “Проверить баланс счета” или “Депонировать чек”. Количество таких действий будет различаться в зависимости от типа приложения или веб-сайта, который вы разрабатываете. При условии существования нескольких путей для различных типов пользователей они могут отражаться последовательно или параллельно. Поисковые исследования главных задач пользователей должны являться основой для создания этого уровня карты.
- Шаги — это конкретные подзадачи, выполняемые пользователями для завершения действия, указанного выше. Они являются следующим уровнем после действий и также отображаются последовательно. Например, для действия “Депонировать чек” можно выделить следующие шаги: “Ввести данные мобильного депозита”, “Подписать чек”, “Сфотографировать чек”, “Внести депозит” и “Подтвердить депозит”.
- Детали представляют собой третий уровень карты истории и описывают конкретные действия пользователей с наибольшей степенью детализации. Например, шаг “Войти в аккаунт” включает две отдельные детали: “Ввести имя пользователя” и “Ввести пароль”.
2. Почему карты пользовательских историй называются именно так
Пользовательские истории представляют собой сформулированные простым языком описания функций, элементов пользовательского интерфейса или задач. Это необходимо для того, чтобы члены команды могли обсудить друг с другом возможные решения, учитывая потребности конечных пользователей и выгоды, которые они могут получить. Подобные обсуждения помогают добиться общего понимания в команде намного быстрее, чем чтение документации, которая содержит требования к продукту. Пользовательские истории могут быть как общими (описывают продукт или какую-то функцию целиком), так и более конкретными (относятся к определенному элементу интерфейса). Например:
- Пользовательская история высокого уровня: “Как владелец банковского счета я хочу депонировать чек со своего мобильного устройства, чтобы мне не пришлось тратить время на походы в банк”.
- Пользовательская история низкого уровня: “Как владелец банковского счета я хочу сохранить свои учетные данные, чтобы мне не приходилось каждый раз при входе в систему вводить имя пользователя и пароль”.
Agile-команды обычно создают краткие, но ценные пользовательские истории и используют их, чтобы спланировать и определить приоритеты для работы в каждом спринте. В карте пользовательской истории действия, шаги и детали обозначаются с помощью коротких, точных глагольных словосочетаний. На их основе создается первая половина пользовательской истории, в которой описывается то, какие потребности есть у пользователя и что он хочет сделать. Затем история может быть расширена за счет добавления ключевых преимуществ, которые составляют вторую ее часть. Таким образом, данный инструмент получил название “карта пользовательских историй” за счет того, что он позволяет преобразовывать глагольные словосочетания, записанные на карте, в настоящие подробные пользовательские истории, которые могут стать предметом дальнейшего обсуждения. В конце концов они будут снабжены критериями приемки и добавлены в перечень работ по продукту для определения приоритетности и оценки важности.
3. Как и когда создаются карты пользовательских историй
Карты историй можно использовать на любом этапе процесса разработки продукта, чтобы стимулировать обсуждение и выработать у команды единое понимание. Можно создать карту истории сразу после проведения первичных исследований, чтобы отобразить опыт взаимодействия пользователя с новым продуктом, а если продукт уже существует, то необходимо проведение юзабилити-тестирования. В любом случае карта историй показывает решения проблем, выявленных в ходе исследований. После создания карты историй команды будут продолжать работу и обращаться к ней: добавлять в нее пункты, а также менять карту таким образом, чтобы она отражала текущее состояние продукта и позволяла определить, над чем работать и что выпускать в последующих спринтах.
Карты историй наиболее эффективно создавать небольшой командой, в которой представители продукта, UX-специалисты, разработчики и тестировщики работают вместе, сообща обсуждая и разрабатывая план продукта. Перед началом работы важно обсудить следующие моменты:
- Цели и потребности пользователей: Опишите нужды пользователей, почему продукт или функции, которые вы описываете, важны. Также необходимо указать, какие реальные проблемы вы решаете с помощью этих функций или продукта.
- Сфера применения карты историй: Укажите, будет ли ваша карта историй отображать: текущую или будущую итерацию продукта; весь продукт; лишь одну его функцию; или какую-то конкретную часть опыта взаимодействия. Нужно проявить особенную осторожность при создании карты для масштабного продукта: зачастую лучше разбить карту историй на небольшие сегменты или ограничить область ее применения, чтобы избежать разбора подобного продукта на одной карте. Предварительное определение сферы охвата карты историй помогает команде в дальнейшем не отвлекаться от темы и задач.
- Результаты: Обсудите, что именно ваши пользователи смогут делать в результате запуска продукта. Эта информация поможет команде сосредоточиться на результатах, а не увязнуть в работе над отдельными решениями. Такой подход также позволяет определить реалистичные начальные и конечные точки для карты.
При создании карты историй команды, работающие в одном помещении, используют стикеры и специальные доски. В то время как специалисты, работающие удаленно, могут воспользоваться видеосвязью, цифровыми таблицами с возможностью совместной работы, онлайн-презентациями или веб-приложениями. В работе над картой должен принимать участие каждый сотрудник.
Обозначьте каждый вид действий стикерами определенного цвета (реальными или виртуальными), чтобы карта историй выглядела организованно. Важно сформулировать действия, шаги и детали таким образом, чтобы они отражали то, чем занят пользователь в конкретный момент времени в ходе взаимодействия с продуктом. Например, если бы вы создавали цифровой продукт, использующий искусственный интеллект и машинное обучение, шаг в карте истории был бы обозначен как “Поделиться предпочтениями”, а не “Обучить искусственный интеллект”.
4. Карты пользовательских историй или карты пути клиента
Когда идет речь о картах пользовательских историй многие задаются вопросом, чем этот инструмент отличается от карты пути клиента. Ключевые различия заключаются в том, что при создании карт используются разные подходы, и каждая из них имеет свое назначение. Карта пути клиента определяет точку зрения пользователя, показывая шаги, которые он проходит для достижения цели, описывает его мысли, эмоции, каналы взаимодействия и устройства, которые он использует на этом пути.
Карта пользовательской истории подходит к вопросу с точки зрения продукта. Ее предназначение — направлять процесс планирования, внедрение характеристик и функций продукта для решения проблем пользователей. Проще говоря, карта пользовательской истории связывает те особенности, которые мы выявляем при составлении карты пути клиента, с теми решениями, которые мы собираемся реализовать в создаваемом продукте. Кроме того, она включает в себя общие идеи и возможности, возникающие в ходе работы над продуктом.
Если добавить в карту пути пользователя действия, шаги и детали, то она может легко превратиться в карту пользовательской истории. Точно так же карта пользовательской истории трансформируется в карту пути клиента, когда в нее добавлены контекст, мысли и чувства пользователей. Эти два типа карт могут эффективно применяться как вместе, так и по отдельности, ведь используемые для их создания методы исследования зачастую одинаковы.
5. Карты пользовательских историй в Agile
Карты пользовательских историй делают Agile-разработку более эффективной по нескольким причинам:
- Улучшенное взаимодействие в команде и общее понимание задач. Карты пользовательских историй упрощают вопросы относительно того, что нужно разрабатывать, почему и для кого. Они намного эффективнее, чем 500 страниц документации, а также помогают всем членам команды прийти к общему пониманию направления работы.
- Карты способствуют созданию и расширению бэклога (списка задач для работы над продуктом). Шаги второго уровня из нашей карты историй превращаются в эпики в бэклоге Agile-продукта. Эпик — это большая пользовательская история, которую необходимо разбить на несколько более мелких пользовательских историй и задач. Детали третьего уровня в карте историй будут выступать в качестве вводных данных для таких небольших историй и задач, однако потребуется дополнить их дополнительными деталями и критериями приемки, чтобы затем добавить в бэклог продукта.
- Выявление составляющих минимально жизнеспособного продукта и хорошо продуманная расстановка приоритетов. Карты историй помогают командам понять, какие элементы может или должен включать их минимально жизнеспособный продукт, а также, как и когда выпускать инкременты продукта (отдельные выполненные задачи) с учетом конкретных целей и результатов. Команды часто рисуют график выпуска прямо на карте историй, помещая детали, над графиком и оставляя их для следующего выпуска под ним. Последние вместе с новыми действиями, шагами и деталями, добавленными в карту, становятся кандидатами для будущих спринтов и выпусков. При этом окончательное решение будет зависеть от того, что команда узнает в дальнейшем и как она будет расставлять приоритеты.
- Карты обеспечивают выявление рискованных предположений. Иногда креативность может взять над нами верх: в процессе работы со стикерами и историями, мы можем добавлять на карту идеи, которые не подкреплены пользовательскими данными, технически нереализуемы или не вписываются в бюджет либо сроки нашего проекта. Карта историй помогает нам увидеть эти риски. Мы можем исключить подобные идеи из карты историй и заменить их менее рискованными, но имеющими такое же ценностное предложение. Таким образом, прежде чем продолжать инвестировать в сложный и трудоемкий дизайн и разработку, мы сможем изучить, какие результаты принесет альтернатива, требующая меньше затрат.
Заключение
Карты историй побуждают членов команды к продуктивным, ориентированным на интересы пользователей дискуссиям о создании продукта, делают идеи для бэклога более наглядными и позволяют командам увидеть общую картину. Если все сделано правильно, карты пользовательских историй помогают выявить логические и готовые к выпуску инкременты продукта (промежуточные результаты), которые соответствуют потребностям пользователей. Они также позволяют увидеть возможные последствия и области риска еще до начала разработки. Такой подход позволяет командам уже на ранних этапах иметь понимание того, что работает, а что нет. Опытные команды используют полученные знания, чтобы принимать решения о том, на каких задачах стоит сосредоточиться, чтобы максимально повысить удобство использования и ценность продукта.
И, наконец, самое главное: поскольку идея Agile заключается в том, чтобы принимать изменения и реагировать на них, а не следовать конкретному плану, карты историй способствуют более эффективной адаптации. Ведь намного проще заменить несколько стикеров, чем переписывать объемную документацию с требованиями к продукту и процессу его разработки.
