第2章 To B产品设计研究

2.1 关于用户故事地图的多种用法

作者：方馨月

之前读完Jeff Patton的《用户故事地图》觉得是一本好书，但是一直没有机会去实践。最近在工作中使用了用户体验地图进行“工作汇报”应用的开发评审，发现在讨论过程中，思路更加清晰、交流更加顺畅了，具体表现在：

（1）开发人员能够很容易发现产品设计的“坑”；

（2）小组成员的参与度更高；

（3）决策更加迅速，会议更加高效；

（4）会议结束后，有满意的讨论结果产出。

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

关于用户故事地图的使用，我按照自己的理解认为主要可以分为三个方面：

（1）产品的[0,0.5]：新产品功能规划、发布规划；

（2）产品的（0.5,1]：需求讨论、需求拆解、优先级排序；

（3）产品的（1, +∞）：产品优化。

下面将根据以上三个方面，详细进行说明。此前有两点需要解释：

（1）简单根据“是否需要开发人员介入”这一条件，将产品发布前分为两部分，即产品的[0,0.5]和产品的（0.5,1]。在开发人员介入前，更多的是产品经理如何进行产品设计，产品整个的基调和走向都是在这一部分定下来的。当开发人员开始介入后，就具体聚焦于功能的实现方面了。能否实现、如何更好实现是这一部分的主要问题。但是要解决这一部分的问题的一个大前提就是，开发人员要全面理解产品，大家脑海里的东西是一致的，这个是最艰难的问题。

（2）上面三点的“产品”，其实不仅仅指的是一个完整的产品，也可以是一个组件、一个大型功能。总之是需要进行思考、设计、开发，并在发布之后会有维护升级的一个模块。

1．产品的[0,0.5]

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

1）新产品功能规划之“产品全景图”

（1）目的：建立产品/模块的全局印象，有全局观，进而可以整体规划产品/模块。

（2）适用场景：产品经理（可能搭配交互设计师）梳理产品框架。

（3）所需资源：2～3名参与人员（包含产品设计者、产品决策者）；卡片/便利贴、笔。

（4）操作方式：

· 一边讨论，一边将想要的功能写在卡片上；

· 一边讨论，一边将功能分类，按照横向为模块名称，纵向为所属模块下的功能进行排列；

· 一边讨论，一边调整当前的布局（可剔除或添加卡片、调整卡片位置）。

（5）说明：

为什么是2～3个人参与？

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

如果只是理个产品逻辑为什么不用思维导图？

从操作方式也可以看出，这是一个需要团队合作的过程。思维导图更像是一个人的思维梳理，不利于多人的团队合作。卡片化的优点在于：①所有人都有调整布局的权限；②没有了屏幕的限制可以支持高复杂度的产品架构；③便于删减和备注；④便于后续的操作（后续很多用法都是建立在产品全景图上）。

2）发布规划

（1）目的：优先级排序，划分发布路线图。

（2）适用场景：产品经理（可能搭配交互设计师）确定产品发布内容。

（3）所需资源：2～3名参与人员（包含产品设计者、产品决策者）；产品全景图。

（4）操作方式：

· 按照产品的长线目标，对功能排优先级；

· 制定产品发布计划，确保每一次的发布内容都是MVP（Minimun Viable Product，最小化可行产品）。

（5）说明：

怎么划分发布周期？

聚焦于成果，明确每一个发布的版本希望能够达到什么样的效果；再就是，保证每一个版本都是当前情况下的MVP。我觉得书里面有一句话能够很充分地回答这个问题：

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

——《用户故事地图》, P56

2．产品的（0.5,1]

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

1）需求讨论 —— 大家来找茬

（1）目的：与开发人员准确、高效地确认需求。

（2）适用场景：产品的某一个迭代，需要确认需求。

（3）所需资源：

· 7名以内项目参与人员（包含产品设计者、用户体验设计师、开发人员），开发团队负责人必须参与，其他开发人员尽量参与（如果人数超过7人，可以采用“金鱼缸协作模式”）；

· 产品全景图；

· 迭代功能的较详细文档（可能是Word文档、直接设计稿、更具体的故事地图）。

（4）操作方式：

· 各参与人员站在自己的角度，思考各功能点在流程中可能出现的情况与问题，挑刺与找茬；

· 根据刚刚的意见，优化流程或提出更好的方式；

· 将讨论结果在不同颜色的卡片/便利贴上写出，贴在功能点的旁边。

（5）说明：

为什么需要产品全景图？这样做有什么好处？

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

需要注意的一点：在此过程中需要控制住，尽量不要延伸出新功能，也不要大范围地修改功能。如果大范围地修改了功能，也不建议直接以会议结果为最终结果。因为原本的方案是经过深思熟虑的，而人在会议上太过于兴奋的状态下容易冲动，冷静下来再思考一下方案也会发现会议上的结果可能存在很多漏洞。

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

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

（2）适用场景：当产品的story颗粒度过大时，开发人员需要将story进一步细化。

（3）所需资源：与“需求讨论”的资源一致。

（4）操作方式：

· 在多方讨论下，将大的story按照开发需要进行拆分；

· 将拆分好的story写在卡片/便利贴上，贴在对应大的story下方/旁边。

（5）说明：产品经理不要太过于干涉技术人员的拆分，在不涉及原则的情况下，他们怎么舒服就怎么来吧。

3）优先级排序

（1）目的：开发人员在一个迭代内，对开发内容进行排序。

（2）适用场景：在“需求拆解”后，很自然地进入到优先级排序。

（3）所需资源：与“需求讨论”的资源一致。

（4）操作方式：在多方讨论下，将已经拆分成颗粒度适宜的story进行排序。

3．产品的（1, +∞）

当产品的初版发布后，后续的工作就是优化和更新了。在此阶段可能会进行用户调研，那么调研的数据如何进行处理才能够反映更多的问题呢？这里提供一种方式，即用户体验地图（Experience Map），它可以用于完整地处理分析数据。但是在书中，还提到了一种叫作旅行地图（Journey Map）的方法，它可以使用在功能整盘复查的时候，来发现用户痛点、找出优化机会。这两种方法有极大的相似之处，所以放在一起来讲。

1）旅行地图

（1）目的：着眼全局，完整查看用户交互路径，发现用户痛点，寻找机会。

（2）适用场景：用户路径明确，产品复盘。

（3）所需资源：

· 3～7名参与人员（包含产品设计者、产品决策者、用户体验设计师）；

· 不同颜色的便利贴/卡片。

（4）操作方式：

· 按照用户操作路径，将每一个触点按步骤写在便利贴上，横向排开；

· 在每个触点下方（沿纵向），标明用户的操作场景（例如时间、环境等可能的因素）、行动、问题；

· 团队人员浏览全局，针对每一个触点提出疑问，进行讨论；

· 得出痛点和收获。

2）用户体验地图

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

（2）适用场景：用户调研数据处理。

（3）所需资源：

· 目标用户的评价数据；

· 3～7名参与人员（包含产品设计者、产品决策者、用户体验设计师）；

· 不同颜色的便利贴/卡片。

（4）操作方式：

· 按照用户操作路径，将每一个触点按步骤写在便利贴上，横向轴排开；

· 将用户操作、评价数据（优/劣）、用户想法 / 感觉归类写在不同颜色的便利贴上，紧向排开；

· 综合每个触点上的评价数据，进行打分；

· 根据得分，调整触点卡片的高度，得分高的卡片位置越高、得分低的卡片位置越低，得出用户情绪曲线（Emotion Journey）；

· 全盘思考，找出机会点，将机会点写在便利贴上，贴在对应的触点下方。

3）两者的差别

其实关于“用户体验地图”和“旅行地图”的不同点，各种资深的用户体验设计师都有讨论过这个问题。我自己在私底下也有查询过一些资料，其中，在YouTube上找到了Mapping Experiences的作者James Kalbach的采访，正好提到了这个问题，他给出的回答是从本质上讲，两者都是一样的，都是借助一定方式去形式化用户的交互路径。但是两者还是挺不一样的，你可以认为旅行地图是整理用户操作路径的一种方式，但是用户体验地图更注重用户在每个触点交互时的体验。

关于《用户故事地图》这本书中“怎么使用用户地图”的总结到这里就结束了。其实这本书里面真的讲了很多很实用的方法，能够帮助你更好地协作、更好地思考产品。它能够让产品设计师、产品经理、交互设计师们去更有效地整理思路、找出解决方法、统筹全局。