In traditional product-development processes, teams often rely on wasteful and lengthy business requirements documents and functional design specifications to move from avison for a digital product概述它应该包括什么以及它应该如何工作。Teams预计分布式文档以足够的，而不是正在进行关于用户，问题，想法和解决方案的持续对话。
但是，这些文件通常会失败;没有人有时间或注意阅读它们，甚至是那些人做阅读他们结束到底可能会消失的是对建立的言论的大大不同的解释。这些沉重的文件而不是推动生产力，从一开始就扼杀创造力，通信，协作和创新。作为备选，用户故事地图work much better as lightweight representations of the digital product that an Agile team intends to build.
User-Story Mapping Defined
定义：用户故事映射（也称为用户故事地图，故事地图和故事映射）是一个精益UX映射方法, often practiced by Agile teams, that uses sticky notes and sketches to outline the interactions that the team expects users to go through to complete their goals in a digital product.
A user-story map depicts 3 types of actions at different granularity: activities (the most general actions), steps, and details (the most specific actions). User activities and steps display horizontally across the top of the map, and the details stack vertically underneath their respective steps in priority order. To define each level of a story map, we’ll use a feature for depositing checks through a bank’s mobile application as an example:
- Activitiesrepresent thehigh-level tasksthat users aim to complete in the digital product — for example,Check account balance或者Deposit a check。Depending on the type of application or website you're creating, you may only have a few high-level activities. These can display in sequential order or in parallel if multiple paths for various user types exist. Exploratory research about顶级用户任务should inform this level of the map.
- 脚步sit directly underneath activities and also display in sequential order. They represent the specific subtasks that users will go through in the product to complete the activity above. For example, the activity,Deposit a check可以解构成步骤Enter mobile deposit details, Sign check, Photograph check, Submit deposit,和确认存款。
- 细节are the third level of the story map and describe the lowest-granularity interactions that the team anticipates users will experience to complete the step above. For example,Enter username or email和Enter密码看起来是两个单独的细节登录步。
Why It’s Called User-Story Mapping
- High-level user story:“As a checking account holder, I want todeposit a check from my mobile device, so that I不必浪费时间去银行。“
- Low-level user story:“As a checking account holder, I want to保存我的凭据, so that I每次登录时都不要输入我的用户名和密码。
敏捷团队通常依赖于小型，高价值的用户故事来规划和估算每个Sprint上工作的内容。在用户故事地图中，活动，步骤和详细信息捕获为表示用户操作的短，简洁的动词短语。这些作为用户故事格式的前半部分的基础，描述了用户需要或想要做的。然后可以阐述故事，包括完成叙述的下半部分的关键效益。因此，调用映射方法用户故事映射,因为它可以用来发展动词phrases captured on the map into fully fleshed-out user stories that can be discussed further, eventually paired with acceptance criteria, and added to the product backlog for prioritization and estimation.
故事地图可以在产品开发过程中的任何一点中使用，以驱动讨论并对齐团队。您可以创建一个故事地图，绘制初始后的新产品的体验发现工作, or for an existing product, after可用性测试。In either case, the story map begins to illustrate solutions to the problems uncovered in the research. Once created, teams will maintain and refer back to their story map over time; they add to it, modify it to reflect the actual state of the product, and use it to guide what to work on and release in subsequent sprints.
- 用户目标和需求：Outline what users are trying to do,为什么the product or feature(s) you are story-mapping are important, and what真实的你解决问题。
- 故事地图的范围：State whether your story map will portray a current or a future iteration of the product and whether you will map an entire product, just one feature, or a section of the experience. Use caution in mapping massive products; breaking story maps up into manageable scopes and segments is often better than tackling an entire large-scale product in one story map. Being transparent about the scope of the story map upfront helps the team stay on topic and on task.
- 结果：Talk about what your users will be able to do as a result of launching the product or feature outlined in the map. This information will help the team maintain focus on the outcomes instead of getting too bogged down by specific solutions and tools. Focusing on outcomes also sets realistic beginning and end points for the map.
Assign differentlycolored sticky notes(whether real or virtual) to each row of activities, steps, and details to keep the story map visually organized. It’s also important to frame your activities, steps, and details by what the用户在产品中的那个特定点，而不是产品是什么从技术上讲为用户做。例如，如果您正在使用人工智能和机器学习创建数字产品，故事中的一步可能会显示为分享偏好， 不是Train the AI.
A user-story map takes the perspective of the product. It aims to guide the planning and implementation of features and functionality to solve users’ problems. Put simply, a user-story map connects what we uncover in customer-journey mapping to what we’re going to intentionally do about it in the product we create, beyond listing out general ideas and opportunities.
A customer-journey map can easily evolve into a user-story map by adding the activities, steps, and details. Similarly, a user-story map can morph into a customer-journey map if the users’ context, thoughts, and feelings are added. These two map types can work well when combined, but are also effective when used independently, as the研究方法used to inform and create each of them are often the same.
User-Story Maps in Agile
User-story maps support the success of Agile product-development teams for several reasons:
- 促进产品积压的创建和扩展。The second-level steps in your story map translate to epics in an Agile product backlog. An epic is a large user story that must be broken down into multiple, smaller user-stories and tasks. The third-level details in the story map are the inputs for those smaller user stories and tasks, albeit with a bit more detail and acceptance criteria added before they hit the product backlog.
- Minimum-viable-product slicing and well-informed prioritization.Story maps help teams see what theirminimum-viable-product releasecould or should include, along with how and when to release end-to-end product increments with specific goals and outcomes in mind. Teams will often draw release lines directly on the story map, moving the details included in each release above the corresponding lines and leaving deferred details for a subsequent release below. Those deferred details, along with any new activities, steps, and details added to the map, become candidates for future sprints and releases based on what the team learns and prioritizes over time.
- Support identification of risky assumptions.Creativity can sometimes get the best of us: when we’re working with sticky notes and stories, we may add risky elements to the map — items that are not backed up by user data, aren’t technically feasible, or take our project’s budget or timeline off course. A story map helps us see where these risks exist.We can deprioritize these risky stickies in the story map and replace them with other low-risk ideas with same value proposition. In this way, we can learn from the leaner alternative first before investing further in sophisticated or time-consuming design and development.