前言

总结：用户故事图能帮助敏捷开发团队定义构建的内容，并使得产品整体呈现效果清晰可见。故事图使以用户为中心的对话、协作和功能优先级排序成为可能，从而有利于对迭代产品的开发过程进行协调和指导。

在传统的产品开发过程中，为了把对电子产品的期望转化为“它应该包括什么”和“它应该如何工作”的具体表述，团队往往需要依赖低效率且冗长的业务需求文档和功能性设计规范。比起不断讨论用户、问题、想法和解决方案，团队期望这些分散的文档能够满足这个需求。

然而，这些文档通常效果很差；没有人有时间或精力去阅读它们，即使从头到尾阅读了这些文档的人也可能对将要构建的内容有截然不同的理解。这些冗杂的文档不仅没有提高生产力，反而从一开始就扼杀了创造力、沟通、协作和革新。作为一种替代方案，用户故事图能更好地、轻量地代表敏捷开发团队（Agile）想要构建的电子产品。

一、用户故事图的定义

定义：用户故事图（也称为故事图）是敏捷开发团队常用的一种精益UX绘图方法，即用便签和草图来概述团队希望用户通过哪些交互在电子产品中完成他们的目标。

Jeff Patton推广了这种方法，它取代了瀑布式（Waterfall）开发方法中冗长的、技术性的需求收集和封闭的更新过程。故事图旨在促进敏捷开发团队成员之间的协作和对话，同时为他们展现更宏观的、产品使用时任务流和呈现效果。后一种作用在敏捷开发环境中尤其重要，因为一个常见挑战就是团队成员会忽视产品的整体性，尤其是当团队根据待办事项列表中一堆互不关联的用户故事进行工作时，可能会出现这种情况。

用户故事图描述了3种详略度不同的操作类型：活动（最概略的操作）、步骤和细节（最具体的操作）。用户活动和步骤在图示的顶部横向展示，而详细信息则按优先级顺序垂直堆叠在各自步骤的下方。为了定义故事图的每个层级，本文接下来会以一个通过银行移动应用存入支票的功能作为示例:

1. 活动代表了用户在电子产品中要完成的首要任务——例如，检查账户余额或存入支票。根据你创建的应用程序或网站的类型，用户可能只有几项基本活动。这些活动可以按顺序显示，如果存在为不同类型用户提供的多个路径，也可以平行显示。关于首要用户任务的探索性研究应该为故事图的这一层提供信息。

2. 步骤位于活动的正下方，也按顺序显示。它们表示用户在产品中为完成上面的活动所要经历的具体的子任务。例如，存入支票这个活动可以被分解成以下几步：输入移动端存储细节、在支票上签名、拍摄支票、提交支票存入请求和确认支票存入。

3. 细节是故事图的第三层，表示团队预计用户在完成上述步骤时将经历的最具体的交互过程。例如，输入用户名或电子邮件和输入密码会作为两个独立的细节出现在登录步骤的下面。

用户故事图包含了用户在电子产品中为完成目标而采取的3个主要层级的行动（活动、步骤和细节）。

二、为什么叫做“用户故事图”？

如果你对用户故事的概念感到陌生，那么你需要知道：用户故事是从用户角度对功能、用户界面元素或任务的非正式、自然语言的描述。它的目的是让团队从用户和用户收益的角度讨论解决方案。这些对话能够帮助团队每个人达成共同的理解，比阅读需求文件快得多。用户故事可以从宏观角度入手，描述一个完整的产品或功能，以及它能让用户干什么，或者从微观角度入手，概述一个界面元素及其价值。举例来说：

1. 宏观角度的用户故事：“作为一个支票账户的持有人，我想从我的移动设备上存入一张支票，这样我就不必浪费时间去银行了。”

2. 微观角度的用户故事：“作为一个支票账户的持有人，我想储存我的登录信息，这样我就不必在每次登录时输入我的用户名和密码。”

敏捷开发团队通常依靠小的、高价值的用户故事来计划和估计每个冲刺周期（Sprint）的工作内容。在用户故事图中，活动、步骤和细节被捕捉为短小简洁的动词短语，用以代表用户行为。这些是用户故事前半部分的基础，描述用户需要或想要做什么。然后我们可以进一步阐述故事，通过描述用户可以获得的关键利益来完成用户故事的后半部分。这种方法被称为用户故事图，因为它可以将图示上表述的动词短语补充为可以进一步讨论的完整的用户故事，最终与验收标准相核对，并添加到产品待办事项列表中，来确定优先级和进一步评估。

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

在产品开发过程中的任何时候都可以使用故事图来促进讨论，并使团队保持一致。你可以在最初的探索性工作之后为新产品创建一个故事图，或者在可用性测试之后，为现有的产品绘制体验图。无论是哪种情况，故事图的初创都是为了阐明针对研究中发现问题的解决方案。在创建之后，团队将随着时间推移不断维护和参考故事图；需要在原图上增删减改以反映产品的实际状态，并使用它来指导后续冲刺阶段要完成的工作和发布任务。

故事图最好由一个小型团队来绘制，这个团队应包含来自产品、UX、开发和质量监控部门的成员。这些成员协作地讨论和制定产品计划。在开始创建故事图之前，确定以下背景十分重要：

1. 用户目标和需求：概述用户想要做什么，为什么你们正在绘制故事图的产品或功能是重要的，以及你们正在解决什么实际问题。

2. 故事图的范围：说明你们的故事图是描绘产品的当下版本还是未来的迭代版本，以及你们是否要为整个产品绘制，还是只为一个功能，或体验的一部分进行故事图绘制。在绘制大型产品时要谨慎——将故事图分解成可管理的范围和部分，往往效果会比在一个故事图中展现整个大型产品要好。对故事图的范围保持公开透明有助于开发团队的工作紧扣主题和任务。

3. 成果：讨论用户在图中描绘的产品或功能发布后能够干什么。这些信息将有利于团队保持对结果的关注，而不是被具体的解决方案和工具所迷惑。专注于结果也为故事图设定了现实的开始和结束点。
为了创建故事图，线下工作的团队可以使用便签、白板和开放的墙面空间；远程团队可以利用视频会议和协作式电子表格、演示幻灯片或在线应用程序。每个人都应该在图上一起工作；没有人应该支配其他人的行动。

为每一行的活动、步骤和细节分配不同颜色的便签（无论是线下的还是线上的），以保持故事图在视觉上具有条理性。同样重要的是，要根据用户在使用产品时的那个特定节点上正在做的事情来确定具体的活动、步骤和细节，而不是产品从技术角度上能为用户做什么。例如，如果你正在创建一个使用人工智能和机器学习技术的电子产品，故事中的一个步骤可能是分享偏好，而不是训练人工智能。

远程工作的团队可以使用视频会议和在线协作工具，如CardBoard、电子表格，甚至是演示幻灯片来共同创建故事图。

四、用户故事图与用户旅程图

当我在UX在线课程中介绍用户故事图时，从业者经常会问它与用户旅程图有什么不同。关键的区别在于，每种图示类型都是从不同的角度进行可视化的，而且它们的目的也不同。用户旅程图从用户的角度出发，显示用户为完成一个目标所经历的步骤，以及她的想法、情绪、渠道和过程中使用的设备。

用户故事图则从产品的角度出发。它的目的是指导及计划产品特性、功能的实现，从而解决用户的问题。简单地说，用户故事图将我们在用户旅程图中发现的东西与我们在创造的产品中要有意做的事情联系起来，而不是列出概略性的想法和机遇。

通过添加活动、步骤和细节，用户旅程图很容易演变为用户故事图。同样，如果加入用户的情境、想法和感受，用户故事图也可以演变成用户旅程图。这两种图示类型结合起来可以很好地工作，但独立使用时也很有效，因为用于创建它们的研究方法往往是相同的。

用户旅程图是从单个用户的角度出发，描述用户为完成一项任务所经历的旅程，以及其想法、感受和使用的设备。

用户故事图是从产品的角度出发，表示用户在使用产品时的细微交互。它们被用于协调、规划产品功能的开发、发布及产品迭代，目的是解决在旅程图中所发现的问题。

五、敏捷开发环境中的用户故事图

用户故事图能够促成敏捷开发团队的成功，原因有以下几点：

1. 促进协作和团队一致性。用户故事图围绕着建立什么、为什么、为谁建立，使得对话和合作变得容易。它能够帮助每个人达成共同的理解和前进方向，比创建和参阅一份500页的文件要有效得多。

2. 促进产品待办事项的创建和扩展。故事图中的第二级步骤可以转化为敏捷产品待办事项的“用户叙事（epics）”。用户叙事是宏观的用户故事，它必须被分解成多个小的用户故事和任务。故事图中的第三级细节是这些小的用户故事和任务，尽管在它们进入产品待办事项清单之前，还需要增加一些细节和验收标准。

故事图中的步骤可以转化为用户叙事，或者敏捷产品待办事项清单中的若干组用户故事。细节也被进一步分解为用户故事和任务，并加入到待办事项清单中。

3. 能够实现最小可行产品（Minimum-viable-product，MVP）的切分和信息充分的优先级排序。故事图帮助团队了解他们的最小可行产品发布时可以及应该包括什么，以及在明确了具体目标和成果的前提下，明晰如何、何时发布终端产品增量。团队通常会在故事图上直接画出发布线，将每个版本中的细节移到相应的线上，并将推迟的细节留在下面，以便后续发布。这些被推迟发布的细节，以及其他新的活动、步骤和细节都会被添加到故事图上，并基于团队随着时间推移获得的经验和优先级排序，成为未来冲刺阶段和发布时的候选条目。

一个通过切分故事图来表示第一版产品发布的例子：线以上的所有东西都被包括在了原型设计中，以了解用户是否理解过程（目标）并能够成功地存入支票（成果）。

4. 有助于识别存在风险的假设。当我们用便签和用户故事工作时，创造力有时会得到最好的发挥：我们可能会在故事图上添加存在风险的元素——一些没有用户数据支持，另一些可能在技术上不可行，或者会使项目预算或时间表偏离轨道。但是故事图可以帮助我们看到这些存在风险的地方。我们可以在故事图中降低这些有风险条目的优先级，或者用其他具有相同价值的低风险想法来代替它们。通过这种方式，我们先了解更精简的替代项，再考虑进一步投资那些复杂或耗时的设计和开发。

故事图展现了存在风险的产品领域，这些领域可能会使用户反感或花费过多的开发时间。用能实现相同价值的更精简的方案来替代有风险的条目。在投入额外的时间和精力来开发完整的功能之前，先进行实验并了解用户的反应。

总结

故事图能够促进以用户为中心、关于产品开发的高效讨论，使得待办事项更为清晰，并帮团队成员获得更为宏观的产品视野。如果合理运用，用户故事图可以揭示出符合逻辑的、可发布的产品增量，以满足用户的需求，同时在开发前揭示功能的影响力和存在风险的领域。这使得团队能够尽早地、经常性地了解什么是可行的，什么是不可行的。聪明的团队利用这些信息来决定将时间集中花费在哪里，以在后续的迭代中最大化可用性、价值和可行性。

最后，因为敏捷开发方法的关键是拥抱变化并对变化做出反应，而不是遵循一个具体的计划，所以故事图能更好地实现高效率的动态改变——毕竟更换便签比修改庞大的需求文件要容易得多。

附录

参考文献
Patton, J., & Economy, P. (2014). User Story Mapping：Discover the Whole Story to Build the Right Product. Sebastopol：O’Reilly Media, Inc.

原文地址：https://www.nngroup.com/articles/user-story-mapping/

版权声明
本文版权属尼尔森诺曼集团（Nielsen Norman Group）所有。欢迎转发至朋友圈，如需转载，请邮件Support@nngroup.com。未经授权的转载、翻译是侵权行为，版权方将保留追究法律责任的权利。