超周全！关于用户故事地图的7种用法

金蝶云之家体验中间交互设计师-方馨月：之前读完 Jeff Patton 的《用户故事地图》觉得是一本好书，但是一向没有机会去实践。

最近在工作中使用了用户体验地图进行云之家工作汇报轻应用的开发评审，发如今讨论过程中，思路更加清晰、交流更加顺畅了。

详细体现在：

• 开发人员能够很容易发现产品设计的题目。
• 小组成员的参与度更高。
• 决策更加敏捷，会议更加高效。
• 会议结束后，有写意的讨论效果产出。

会后，更加觉得用户故事地图是一个可以进步协作服从的工具，所以，想写一篇“读书笔记&实行思考”，来记录这段时间的收获。

《用户故事地图》不仅仅是讲述什么是用户地图、怎么使用用户地图，也讲了许多团队协作的Tips，并且给出了许多实例。我这里直接从这本书的其中一个角度——“怎么使用用户地图”为内容，然后结合一些本身的想法，来写这篇读书笔记。

用户故事地图的使用，重要可以分为三个方面：

• 产品的「0，0.5」：新产品功能规划／发布规划。
• 产品的「0.5，1」：需求讨论／需求拆解／优先级排序。
• 产品的「1，＋∞」：产品优化。

下面将根据以上三个方面，细致进行说明。

两点诠释：

• 我很粗暴的根据「是否必要开发人员介入」这一条件，将产品发版前分为两部分，即产品的「0，0.5」，产品的「0.5，1」。在开发人员介入前，更多的是产品经理如何进行产品设计，产品整个的基调和走向都是在这一部分定下来的。当开发人员开始介入后，就详细聚焦于功能的实现方面了。能否实现？如何更好的实现？是这一部分的重要题目。但是要解决这一部分的题目的一个大前提就是，开发人员如何周全的理解这个产品？让大家脑海里的东西是同等的？这个是最艰难的题目。
• 上面三点的「产品」，其实不仅仅指的是一个完备的产品，也可以是一个组件、一个大型功能。总之是必要进行思考、设计、开发并之后会有维护升级的一个模块。

一. 产品的「0 ，0.5」

当产品或某一个大型模块在进行功能设计的时候，可以采取用户故事地图的体例来梳理所有的功能点，并进行迭代周期的规划。

新产品功能规划之产品全景图

1. 目的

建立产品／模块的全局印象，有全局观，进而可以团体规划产品／模块。

2.适用场景

产品经理（可能搭配交互设计师）梳理产品框架。

3.所需资源

• 2-3名参与人员（需原谅产品设计者、产品决策者）。
• 卡片／便利贴，笔。

4.操作体例

• 一边讨论，一边将想要的功能写在卡片上。
• 一边讨论，一边将将功能分类，按照x轴为模块名称，y轴为所属模块下的功能进行排列。
• 一边讨论，一边调整当前的布局（可剔除／添加卡片、调整卡片位置）。

5.诠释／说明／tips

1）为什么是2-3小我？

对于有的项目，产品设计人和产品决策人是一小我，为什么还必要2-3小我呢？由于在我看来，一小我的想法是无法做到完美的，但是假如是两小我合作则可以避开90%以上的产品漏洞，所以在产品功能规划的方面，更建议2人以上（当然假如碰到牛人，思维无漏洞，一小我建立产品全景图也是没任何题目的）。不建议3人以上，则是由于对产品指手画脚的人多了，只会越来越乱，产品设计层面，要少而精。

2）假如只是理个产品逻辑，为什么不用脑图：

从操作体例也可以看出，这是一个必要团队合作的过程。脑图更像是一小我的思维梳理，不利于多人的团队合作。卡片化的好处在于：

• 所有人都有调整布局的权限。
• 没有了屏幕的限定可以支持高复杂度的产品架构。
• 可以更方便的删减和备注。
• 为了后续的操作。

新产品功能规划之大家来找茬（功能点设计）

1.目的

对于关键的功能点或有争议的功能点，可以拿出来大家一路讨论，进而明确功能点的详细操作流程，削减踩坑的可能性。

2.适用场景

确定某个有争议的功能点的设计。

3.所需资源

• 3-4名参与人员（需原谅产品决策者、产品设计者、用户体验设计师）。
• 产品全景图。
• persona卡片 及 scenario卡片。
• 不同颜色的卡片／便利贴，笔。

4.操作体例（以功能点A的设计为例）

• 围绕A，各参与人员站在本身的角度，思考A在流程中可能出现的情况与题目，挑刺与找茬。
• 围绕A，根据刚刚点意见，优化流程或提出更好的体例。
• 将讨论效果在不同颜色的卡片／便利贴上写出，贴在功能点A的旁边。

5.诠释／说明／tips

• 肯定要围绕A，跑题太可怕，降低会议服从且达不到目的。
• 肯定要得出效果，更好的方案／保持当前方案不变。

发布规划

1.目的

优先级排序，划分发布路线图。

2.适用场景

产品经理（可能搭配交互设计师）确定产品发布内容。

3.所需资源

• 2-3名参与人员（需原谅产品设计者、产品决策者）
• 产品全景图

4.操作体例

• 按照产品的长线目标，对功能排优先级。
• 制订产品发布计划，确保每一次的发布内容都是 MVP。

5.诠释／说明／tips

• 如何排列优先级？

我觉得书里面有一句话能够很充分的回答这个题目：

聚焦于成果，即产品发布后用户能使用和感知的东西，切分发布计划应该以成果为导向。 ——《用户故事地图》P56

• 怎么划分发布周期？

同样也是聚焦于成果，每一个发布的版本盼望能够达到什么样的结果，再就是，保证 每一个版本都是当前情况下的 MVP。

二. 产品的「0.5 ，1」

当产品形态及功能确定后，则进入到需求确认阶段。这个阶段是必要产品的所有参与者参与其中的，但是重要以开发人员为主，确认产品功能的可实现性。

需求讨论 —— 大家来找茬

1.目的

与开发人员正确、高效地确认需求。

2.适用场景

产品的某一个迭代，必要确认需求。

3.所需资源

• 7名以内项目参与人员（需原谅产品设计者、用户体验设计师、开发人员），开发团队负责人必须参与，其他开发人员尽量参与（假如人数超过7人，可以采用金鱼缸协作模式）。
• 产品全景图。
• 迭代功能的较细致文档（可能是word文档、可能直接是设计稿、可能是更详细的故事地图）。

4.操作体例

• 各参与人员站在本身的角度，思考各功能点在流程中可能出现的情况与题目，挑刺与找茬。
• 根据刚刚点意见，优化流程或提出更好的体例。
• 将讨论效果在不同颜色的卡片／便利贴上写出，贴在功能点的旁边。

5.诠释／说明／tips

1）为什么必要产品全景图？如许做有什么益处？

产品全景图可以帮助开发人员建立整个产品形态，能够完全清楚当前的团体的开发内容，利于架构的搭建，代码模块化／复用等等。

2）必要细致的一点：在此过程中必要控制住，尽量不要延长出新功能，也不要大范围的修改功能。假如大范围的修改了功能，也不建议直接以会议效果为最闭幕果。由于本来的方案是经过深思熟虑的，而在会议上，人太过于愉快的状况下容易冲动，岑寂下来再思考一下方案也会发现会议上的效果可能会存在许多漏洞。

需求拆解 —— story 下的 story 细分

1.目的

将当前的 story 细分为开发人员可以接受、方便开发的 story。

2.适用场景

当产品的 story 颗粒度过大时，开发人员必要将 story 进一步细化。

3.所需资源（与需求讨论的资源同等）

• 7名以内项目参与人员（需原谅产品设计者、用户体验设计师、开发人员），开发团队负责人必须参与，其他开发人员尽量参与（假如人数超过7人，可以采用金鱼缸协作模式）。
• 产品全景图。
• 迭代功能的较细致文档（可能是word文档、可能直接是设计稿、可能是更详细的故事地图）。

4.操作体例

• 在多方讨论下，将大的 story 按照开发必要进行拆分。
• 将拆分好的 story 写在卡片／便利贴上，贴在对应大的 story 下方／旁边。

5.诠释／说明／tips

产品经理不要太过于干涉技术人员的拆分，在不涉及原则的情况下，他们开发怎么恬逸就随着他们来吧。

优先级排序

1.目的

开发人员在一个迭代内，对开发内容进行排序。

2.适用场景

在「需求拆解」后，很天然的进入到优先级排序。

3.所需资源（与需求讨论的资源同等）

• 7名以内项目参与人员（需原谅产品设计者、用户体验设计师、开发人员），开发团队负责人必须参与，其他开发人员尽量参与（假如人数超过7人，可以采用金鱼缸协作模式）
• 产品全景图
• 迭代功能的较细致文档（可能是word文档、可能直接是设计稿、可能是更详细的故事地图）

4.操作体例

在多方讨论下，将已经拆分成颗粒度适宜的 story 进行排序。

三. 产品的「1，＋∞」

当产品的出版发布后，后续的工作就是优化和更新了。在此阶段可能会进行用户调研，那么调研的数据如何进行处理才能够反映更多的题目呢？这里提供一种体例，在用户故事地图中被称作 journey map （也就是 experience map ），但是在其基础上做了一些些调整。在上面叠加了情绪版的使用方法。

旅行地图

1.目的

用户调研数据处理，确定产品的优化点与优化需求。

2.适用场景

用户调研数据处理。

3.所需资源

• 目标用户的评价数据
• 3-7名参与人员（需原谅产品设计者、产品决策者、用户体验设计师）
• 不同颜色的便利贴／卡片

4.操作体例

• 用户操作路径，每一个触点按步骤写在便利贴上，在x轴排开。
• 评价数据写在便利贴上，按照体验良好程度，在y轴排开。
• 综合每个触点上的评价数据，进行打分。
• 根据得分，调整触点卡片的y坐标。

以上就是用户故事地图的 7 种用法，分别对应于产品的「0 ，0.5」、「0.5 ，1」、「1，＋∞」三个大的阶段。盼望对大家能有所帮助。

迎接关注微信公众号：「UXD-Cloudhub」