编辑导语：在产品后续的迭代升级中，用户需求与用户体验是产品迭代的重要依据因素之一。其中，用户旅程图直接、清晰地描述了用户人机交互时的体验，而通过可视化地图的创建，团队可以有效推动后续的业务协作。本文作者阐述了制作用户旅程图的方法，一起来看一下。

解决用户的需求是每个成功的软件研发团队重中之重的工作。团队通过研究、分析与预测用户的需求目标，可以创建真正有价值与易用性的产品。

但是如何知道软件产品为用户提供了真正的价值？

这是每个研发团队长期研究的问题，整个项目过程都需要以用户为中心。用户旅程图可以在整个项目过程内帮助研发团队往正确的方向前进。

图片来源：Jelvix.com

往下阅读，你就会知道为什么用户旅程图能够给开发团队正确的方向指导，以及为什么它能打造成功的、用户至上的数字产品。

一、什么是用户旅程？What are User Stories？

用户旅程是敏捷开发项目的一环，其设计目的在于达成指定性目标。

从用户的角度来看，用户旅程不是描述产品的功能性，而是描述实现用户最终目标的一系列场景故事。用户旅程使开发团队能够了解特定的工作单元，了解整个项目如何为目标用户带来最终价值。

故事可以用一个或几个句子概括。其中包括：

• 终端用户人群；
• 用户的使用目标；
• 用户与产品交互时的场景描述；
• 从用户的使用角度描述产品的主要功能。

这是定义用户故事的基本模板：

作为【用户】我想拥有【功能描述】，然后我可以【达到什么样的收益或目标】。

用户旅程的最终版本可能是这样的（以下为针对关键字工具的案例）：

“作为一个关键字工具的使用者，我希望看到的结果是竞争关系较少的词条，以便在 google 搜索的结果里该关键字能提高我司网站的曝光机会。”

以上可见，该描述中没有任何关于如何开发与实现用户故事中相关功能的详细信息。

这是一个完全以用户为中心的描述，只需要简单描述人们如何与数字产品交互并如何从中获利。

二、什么是用户旅程图？What is User Story Mapping？

用户旅程图直观描述了用户如何创建用户故事以及故事旅程，它概述了用户进行人机交互的体验。

作为敏捷开发方法的重要组成部分，用户旅程图对工作排期、工作优先级与人员分配起到重大意义与责任。

此信息应作为指导整个项目团队（开发人员、设计师、项目经理等）的框架，并使他们专注于最终用户的实际需求。

用户旅程图的最佳实践方法是创建可视化地图。其目的是概述用户的使用体验，并提供有关产品功能的更多详细信息。

用户旅程图包含四个层级：

• 用户类型；
• 用户行为；
• 用户任务；
• 功能触点（从用户的角度描述）。

这是开始构建产品之前的地图结构（从上到下，从用户活动开始逐一拆解至具体功能）。

每个行为都对应了任务。用户是通过每个相应任务下的功能来完成行为的。

例如，要执行 A 任务，产品需要具备 A1 功能和 A2 功能帮助用户完成。反过来，要完成 A 活动（行为），他们需要能够同时完成 A 任务和 B 任务。

三、用户旅程图的优势是什么？What are the Benefits of User Story Mapping？

用户旅程图，提出能够关联并帮助终端用户视角看待产品功能的机会，是一个强大的研究用户的方法。以下将介绍用户旅程图带来的几大好处。

1. 确保所有成员认知相同

创建用户旅程图是产品经理确保每个团队成员都了解项目目标的好方法。

如果你在项目开始时就设计用户旅程图，可以帮助团队了解用户的实际需求，有助于开发人员确定对用户最有用的功能，并优先对其进行处理。

2.更有效地安排工作优先级

正如伟大的史蒂夫·乔布斯（ Steve Jobs ）曾经说过的那样，专注于某件事并不是要对它说 “是” 。这是对其他数百种事物说 “不” 。

随着你的项目不断发展变复杂，说 “不” 可能会越来越难。为避免团队负责人提出新的建议，你应该与他们一起，从一开始就确认关注的重点。用户旅程图是实现此目标的理想工具，它简述了用户的使用体验以及与未来项目的交互行为。

产品负责人可以依据用户旅程图来决定哪些功能和任务需要先开发与实施。如果你在开始工作之前就定义好了用户故事，就意味着参与开发过程中的每个人都能从用户角度出发。这会让项目的工作流程变得更顺畅。

因此，与你的团队坐下来，讨论用户的目标，并确定将哪些用户任务安排在哪些 sprint（敏捷开发中的一个 sprint 框架）中。产品负责人确认需开发的用户任务、用户流程与目标任务优先级，从而确保工作流程顺畅并最终发挥关键作用。

3.聚焦于产品价值

通过了解用户如何从产品中受益以及如何与产品进行交互，可以确保开发中的需求与任务同用户需求保持一致。这强调了产品对终端使用者的价值。

4. 激励团队成员进行目标对齐

研发团队往往容易忽视终端用户的使用视角，尤其在项目初期。

不同的利益相关者可能会提出不同的要求与服务不同的场景任务，这很容易导致紧张与冲突。如果将用户旅程图明确定义好，也许能阻止这种情况的发生。

一旦用户旅程图创建完毕，便用于指导所有团队（开发人员、设计师等）的高度协作。因此，用户旅程图的创建意味着大家已经达成了共识。一旦用户旅程图被项目中的所有团队开发和使用，就意味着每个人都对项目的目标和优先级具有共同的认识与理解。

5. 提高用户满意度

如果你的团队完成了任务，开发出具备市场即可用性的产品，那么人们更有可能使用该产品。从业务角度来看，这有助于：

另一方面，如果你没有用户旅程图，代表了缺失用户相关的可靠佐证，项目可能存在假设错误的风险。

四、如何创建用户旅程图？How Do You Create a User Story Map？

创建用户旅程图需要一些时间。在本节中，让我们引导你从头到尾完成整个过程。

1.从用户调查开始

要为某人创建有用的数字产品，例如网站、应用程序等等，需要尽可能多地了解用户。这就是为什么需要和你的团队坐下来讨论你所知道的和需要进一步研究的东西。

提出以下问题：

• 产品预期用户有哪些？
• 用户的目标和痛点是什么？
• 产品的用途是什么？
• 我们试图解决哪些问题？哪些功能适用于这些问题？
• 用户将从产品中得到什么？
• 产品对用户的最终价值是什么？
• 我们能以多快的速度开发这些功能，最终完成这个项目？

记住让所有团队负责人和潜在合作者都参与进来。

合作的人越多，一同为项目明确共同目标，以后遇到的冲突和问题就越少。

本次研究和讨论会应在明确回答这些问题后结束。每个人都应该了解哪些人是最终用户以及他们的目标是什么。

如果有机会，请使用以前的故事地图版本，或来自类似产品的可用性测试结果。因为它们可以确保用户旅程图与真实用例相似。

许多人依赖可用性测试得到准确的用户旅程图。无论是研究还是测试，许多公司都会进行 4 到 20 次测试。

所以，一定要深入挖掘数据，找出用户喜欢什么。至少进行 4 次测试，但是如果觉得对用户的理解不够完美，那么可以考虑更多的测试。

2. 概述用户需求

这是用户旅程图的第二级，包含最终将作为产品功能的用户需求。这个部分被称为“用户行为”，用于显示用户需完成的操作步骤。该部分为地图其余模块提供非常重要的指导信息。

开始定义用户需求，写下用户可能需要用产品实现的最重要目标。假设这些用户行为非常符合关键字工具的使用场景。

假设在研究了你的目标用户数字营销人员或企业主之后，你发现他们需要完成这四项基本活动：找到相关的关键字、生成关键字想法、寻找关键字的竞争者、理解关键字的指标。

以上用户行为最有价值，这就是你需要首先关注它们的原因。你需要按照用户使用产品的时间顺序排列这些行为。此外请记住，还需补充与帐户创建、管理、删除等关键节点行为。

以下是使用关键字工具可能采取的步骤详细列表：

• 注册账户；
• 输入付款信息；
• 查看相关关键字研究的教程；
• 向帐户添加更多详细信息，提升个性化的观看体验；
• 查找相关关键字；
• 产生更多的关键字想法；
• 将关键字想法保存为PDF报告；
• 找出竞争对手使用的关键字词条；
• 通过工具提示了解关键字的指标，如流量。

如你所见，这几乎就是整个用户工作流程或他们的 “旅程”，这将是用户旅程图的 “主干”，你将使用它来定义产品的功能和用户体验。

在列出所有任务的清单之后，一定要确定它们的优先级，这样团队领导就知道如何组织工作。

3. 将行为拆解为任务

用户旅程图的下一个层级是用户任务。这些是用户完成行为时所需完成的任务。它们包括产品中的特定功能。你需要将行为分解为任务，并从用户的角度对其进行描述。它们中的大多数都过于复杂和耗时，无法在一个 sprint 中完成。

将任务放在与之相关的行为活动下面，并按照团队认可的顺序进行整理。这有助于理解每个任务如何支持每个目标。

一个行为可能存在多个任务，但请限制任务于故事地图上的数量，以避免操作流程过于复杂。

4. 优先排序、划分和拆分

案例的用户旅程图看起来干净整洁，因为它只包含 4 个活动和 8 个任务。而大多数情况下，项目经理的最终产出物会包含 10 多个活动和 30 多个任务，因此地图可能看起来相当混乱。

这就是你下一步要解决的问题。意思是：

• 选择对用户最重要的活动和任务；
• 为任务创建类别，即 “关键字搜索”、“文件导入”、“关键字分析”。

当然，你可以随意做出你认为合适的修改，以使地图更符合逻辑、更清晰、更易于遵循。

5. 地图的迭代更新

用户旅程图的最终版本应该为你提供一个简单的产品指南，使项目真正以用户为中心。

“千万不要把它当作完成之后不可更改的东西。”

“如果你发现了与用户关联性更强的内容，请组织团队参考该内容，并根据你的研究调整。”

——《顶级作家评论》的项目管理作家索尼娅·埃德尔曼

如果团队同意，并且研究结果能提供理论支持，那就去做吧。

五、用户旅程图模板 User Story Map Templates

如果你需要一个用户旅程图的模板，请随意享用这些例子。

1. 模板 1

用户旅程图的模板就是我们在本文中一直使用的模板。它几乎是一个地图的经典样式，包含四个级别：用户类型、用户行为、用户任务和产品功能。

你可以在与团队讨论项目时，使用旧便签条来创建此地图。这样以后就更容易改正了。不过，最终版本需要以电子格式保存，以便与参与项目的每个人轻松共享。

优点：

缺点：

仅包括有限数量的产品用户类型。

2. 模板 2

这里有个和之前相比更简化的、不同格式的模板示例，在规划的初始阶段，它表现得更好。你可以在第一次与团队会面时分发此模板。让每个人都写下自己的想法并进行讨论。

如你所见，该模板非常适合讨论多个用户的旅程。

优点：

• 最适合让每个开发人员在用户故事开始时，参与用户旅程的头暴；
• 包含多个预期用户。

缺点：

不适合绘制整个用户旅程。

六、需避免 4 类常见的错误状况 4 Common User Story Mapping Mistakes to Avoid

如果做得正确，是项目成功的必备条件。然而，如果负责绘制地图的项目经理未能正确进行研究，那么将错过设计出用户至上产品的宝贵机会。下面是常见的用户故事地图错误。

1. 用户研究不足

一些项目经理将调研方向限制在关注目标用户的基础信息。这增加了开发人员开发出无意义产品功能的可能性。除此之外，开发团队可能很难理解目标用户的真正目标和动机。

为了避免这种情况，研究真实人群的需求，而不是 “特殊用户”。

使用调查、访谈、案例研究、用户画像等一切觉得有用的方式。这些用研方法是最好的，因为它们提供的是真实世界的数据，而不是刻板印象的或常识性的知识。

2. 创建的用户故事过于模糊

一个没有给出足够细节的用户旅程实际上是无用的。例如：“作为一个内容创建者，我需要一个好的关键字工具，来获取更多的关键字词条。”

虽然它有目标用户和产品，但它并没有真正解释用户为什么需要关键字工具以及如何从中受益。遵循故事地图的模板，避免使用诸如 “好”、“有效” 或 “强大” 之类的模糊词。

3. 未让团队成员参与用户故事的撰写过程

如果没有开发人员、设计师、用户体验作者和团队的其他开发产品成员，创建一个详细而真实的故事地图几乎是不可能的。编写用户故事也是同理。

这就是很多项目经理犯错误的原因。未让团队成员参与用户故事的撰写，他们将冒着最终研发出的产品缺少关键功能这个风险。

为了避免这种情况，需要召开一次关于用户故事和体验过程的会议。分享你的研究成果，努力让每个参与项目的人都参与进来。

4. 过于技术性或验收标准模糊

验收标准列表是用户旅程的一环。它描述了产品的目标用户为实现其主要目标所需努力的方面。

在编写验收标准时，项目经理通常会犯两个错误。

第一个错误是使它们过于技术化。

以至于只有开发人员才能正确理解。下面是一个关于通知功能过度技术性的标准示例：

“作为关键字工具的使用者，我希望能够轻松配置通知设置，以便在进行更新时接收通知。”

没有用户会这么说，所以此类验收标准肯定是一个缺乏对用户进行调研的警示信号。它显然是从开发人员的角度考虑产品功能的。

另一个常见的错误是制定模糊的标准。

如：“作为一个用户，我需要一个优秀的关键字产品功能来进行定制化我的关键字调研结果。”

这对开发者来说基本上没有什么意义。“优秀” 对用户意味着什么？什么是 “定制化”？为了避免与你的团队发生混淆以及陷入长时间、不必要的讨论，请与他们一起制定验收标准，并使用清晰的字段表达所有内容。

七、整合运用知识 Putting it all Together

只有通过调研手法和预测用户的需求，才能创造出受欢迎的数字产品。没有足够的用户所需信息，会导致出现不必要的和不关联的产品功能（或者更糟糕的是，缺少必要产品功能）。设计用户故事地图是避免这种情况的好方法。

希望本文能为你提供足够的信息，让你了解若设计一个以人为本且具备意义与关联性的产品，要如何创建它的用户故事地图。所以，轮到你来创建你的故事地图了。开展你的调研，最终用户会用高参与度和对产品的良性评价来回报你。

本文翻译已获得作者的正式授权（授权截图如下）

作者：Sasha Andrieiev，译者：刘昱茜，编辑：徐小淇，审核：徐曼鹭、张聿彤；公众号：TCC翻译情报局

原文链接：
https://uxplanet.org/user-story-mapping-templates-and-examples-e3c5e3c0c18b

本文由@TCC翻译情报局 翻译发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议