在敏捷中映射用户故事

在传统的产品开发过程中，团队通常依赖于浪费和冗长的业务需求文档和功能设计规范来从一个数字产品的视觉来概述它应该包括什么以及它应该如何工作。团队期望分布式文档能够满足需求，而不是进行关于用户、问题、想法和解决方案的持续对话。

然而，这些文档通常会失败;没有人有时间或注意力去读它们，甚至那些做把它们从头到尾读一遍，很可能会得到截然不同的解释。这些沉重的文档从一开始就扼杀了创造力、沟通、协作和创新，而不是推动生产力。作为一种替代方法,用户故事地图作为敏捷团队想要构建的数字产品的轻量级表示，工作起来要好得多。

用户故事映射定义

定义:用户故事映射(也称为用户故事映射、故事映射和故事映射)是一种精益UX-mapping方法，通常由敏捷团队实践，使用便利贴和草图来概述团队希望用户在数字产品中完成他们的目标所经过的交互。

Jeff Patton推广了这种方法，它取代了瀑布式开发中冗长的技术需求收集和竖井式更新过程。故事图旨在激发敏捷团队成员之间的协作和对话，同时为他们提供数字产品如何流动和配合的更大的图景。故事图的后一种质量在敏捷环境中是很重要的，因为忽略整个产品是一个常见的挑战，当团队从待定项中的离散用户故事列表中工作时，很可能会出现这种情况。

用户故事图描述了三种不同粒度的操作类型:活动(最一般的操作)、步骤和细节(最具体的操作)。用户活动和步骤水平显示在地图的顶部，详细信息按优先级顺序垂直堆叠在各自步骤的下方。为了定义故事地图的每个关卡，我们将使用一个通过银行手机应用程序存入支票的功能作为例子:

1. 活动代表了高级任务用户想要在数字产品中完成的目标，例如，检查账户余额或支票存款．根据您所创建的应用程序或网站的类型，您可能只有一些高级活动。如果存在各种用户类型的多条路径，则可以按顺序显示，或者并行显示。探索性研究高级用户任务应该通知这一层的地图。
2. 步骤直接坐在活动的下面，也按顺序显示。它们表示用户在产品中完成上述活动所经过的特定子任务。例如，这个活动，支票存款可以分解为输入手机存款明细，签名支票，照片支票，提交存款，和确认存款．
3. 细节是故事图的第三个层次，描述了团队预期用户在完成上述步骤时将体验到的最低粒度的交互。例如,输入用户名或电子邮件和输入密码显示为下面的两个单独的细节登录的一步。

为什么叫用户故事映射

如果你对这个概念不熟悉用户故事，它们是从用户的角度编写的功能、UI元素或任务的非正式、自然语言描述。他们的目的是让团队在终端用户的背景下互相讨论解决方案以及他们将获得的好处。这些对话帮助每个人比阅读需求文档更快地达成共享理解。用户故事可以在高层次上描述一个完整的产品或特性，以及它能让用户做些什么;在低层次上，可以概述一个界面元素及其价值。例如:

• 高级用户故事:“作为一个支票账户持有人，我想用我的移动设备存一张支票，以便我不必浪费时间去银行．”
• 低级用户故事:“作为一个支票账户持有人，我想拯救我的凭证，以便我不必每次登录都输入用户名和密码．

敏捷团队通常依靠小的、高价值的用户故事来计划和评估每个sprint的工作内容。在用户故事图中，活动、步骤和细节被捕获为表示用户操作的简短、简洁的动词短语。这些是用户故事格式前半部分的基础，描述用户需要或想要做什么。然后可以详细阐述故事，包括完成故事后半部分的关键好处。因此，调用映射方法用户故事映射是因为它可以用来将地图上捕获的动词短语演变成可以进一步讨论的完整的用户故事，最终与验收标准配对，并添加到产品待定项中以进行优先级和评估。

何时以及如何创建用户故事图

故事图可以用于产品开发过程中的任何一点，以推动讨论并使团队保持一致。在初始化之后，您可以创建一个故事图来描绘新产品的体验发现工作，或对现有产品，后可用性测试．无论哪种情况，故事图都开始说明研究中发现的问题的解决方案。一旦创建完成，团队将维护并参考他们的故事地图;他们添加它，修改它以反映产品的实际状态，并使用它来指导在后续的sprint中工作和发布什么。

故事图最好由来自产品、用户体验、开发和QA的代表组成的小团队来协作讨论和塑造产品计划。在开始之前，建立以下背景很重要:

• 用户目标和需求:概述用户正在尝试做什么，为什么你的产品或特性的故事映射很重要，什么真正的你解决问题。
• 故事地图的范围:陈述你的故事图是描述产品当前的还是未来的迭代，你是描绘整个产品，只是一个功能，还是体验的一部分。在绘制大量产品时要谨慎;将故事图分解成可管理的范围和部分通常比在一个故事图中处理整个大型产品要好。将故事图的范围透明化有助于团队专注于主题和任务。
• 结果:讨论你的用户在推出地图中列出的产品或功能后能够做什么。这些信息将帮助团队保持对结果的关注，而不是被特定的解决方案和工具所束缚。关注结果也为地图设定了现实的起点和终点。

为了创造一个故事地图，面对面的团队使用便利贴、白板和开放的墙壁空间;远程团队可以利用视频会议、协作电子表格、演示幻灯片或基于网络的程序。每个人都应该在地图上一起工作;没有一个人或角色应该支配其他的人或角色。

分配不同的彩色的便签(无论是真实的还是虚拟的)到每一行活动、步骤和细节，以保持故事图的可视化组织。同样重要的是，要根据你的目标来规划你的活动、步骤和细节用户是在产品的特定点上做什么，而不是产品是什么从技术上讲为用户做的事情。例如，如果你正在使用人工智能和机器学习创建一个数字产品，故事中的一个步骤可能显示为分享的偏好,而不是人工智能训练。

用户故事映射vs.客户旅程映射

当我在UX会议课程中介绍用户故事映射时精益UX和敏捷，实践者经常问它有何不同客户之旅的映射．关键的区别在于，每种地图类型都是从不同的角度来显示的，它们用于不同的目的。客户旅程图从用户的角度出发，展示了她完成目标所经历的步骤，以及一路上使用的思想、情感、渠道和设备。

用户故事图采用产品的透视图。它旨在指导功能和功能的规划和实施，以解决用户的问题。简单地说，除了列出一般的想法和机会之外，用户故事地图还将我们在客户旅程地图中发现的内容与我们将在我们创造的产品中有意为此做些什么联系起来。

通过添加活动、步骤和细节，客户旅程图可以很容易地演变为用户故事图。类似地，如果添加了用户的上下文、想法和感受，用户故事图也可以变成用户旅程图。这两种映射类型结合使用时可以很好地工作，但单独使用时也很有效，如研究方法用于通知和创建的每一个通常都是相同的。

敏捷中的用户故事地图

用户故事图支持敏捷产品开发团队的成功有以下几个原因:

• 改进协作和团队协作。用户故事图简化了围绕要构建什么、为什么要构建以及为谁构建的对话和协作。它们帮助每个人达成共同的理解和方向，比创建和阅读一份500页的文件更有效。
• 促进产品待办事项列表的创建和扩展。故事图中的第二级步骤转化为敏捷产品backlog中的史诗级步骤。史诗是一个庞大的用户故事，它必须被分解成多个较小的用户故事和任务。故事图中的第三级细节是那些较小的用户故事和任务的输入，尽管在它们进入产品待定列表之前添加了更多的细节和验收标准。

• 最小可行性产品切片和充分了解优先级。故事地图帮助团队了解他们的最小可行产品发布可以或应该包括，以及如何和何时发布具有特定目标和结果的端到端产品增量。团队通常会直接在故事图上画出发行版线，将每个发行版中包含的细节移动到相应的线之上，并将延迟的细节留给下面的后续发行版。这些延迟的细节，以及添加到映射中的任何新活动、步骤和细节，将成为未来sprint和发布的候选者，这取决于团队随着时间的推移学到的内容和优先级。

• 支持识别风险假设。创造力有时能让我们脱颖而出:当我们使用便利贴和故事时，我们可能会在地图中添加风险元素——没有用户数据支持的项目，技术上不可行的项目，或者使我们的项目预算或时间表偏离轨道。一个故事地图可以帮助我们看到这些风险存在的地方。我们可以在故事地图中优先考虑这些有风险的粘性内容，并将其替换为其他具有相同价值主张的低风险理念。通过这种方式，我们可以在进一步投资复杂或耗时的设计和开发之前，先从精简的替代方案中学习。

结论

故事图鼓励关于产品创建的高效、以用户为中心的讨论，提高待办事项列表的可视性，并允许团队看到更大的图景。如果处理得当，用户故事图可以显示符合用户需求的产品增量的逻辑和可发布的部分，同时可以在开发之前发现影响和风险领域。这使得团队能够尽早且经常地了解什么有效，什么无效。精明的团队使用这些知识来驱动关于在后续迭代中把时间集中在哪里以最大化可用性、价值和可行性的决策。

最后，因为敏捷是关于拥抱和响应变化，而不是遵循一个具体的计划，故事图更好地促进了有效的适应;更换便利贴要比修改繁琐的需求文档容易得多。了解更多关于如何创建用户故事图，协作用户故事图的好处，以及如何在我们的敏捷产品开发实践中使用这些图精益UX和敏捷课程在用户体验会议．

参考文献

(2014)。用户故事映射:发现整个故事以构建正确的产品。塞瓦斯托波尔:奥莱利媒体公司