image.png

图片来自《用户故事地图》

写在前面

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

1. 开发人员能够很容易发现产品设计的坑；
2. 小组成员的参与度更高；
3. 决策更加迅速，会议更加高效；
4. 会议结束后，有满意的讨论结果产出。

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

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

用户故事地图的使用，主要可以分为三个方面（当然，这个只是我自己的一个归纳）：

1. 产品的［0，0.5］：新产品功能规划／发布规划
2. 产品的（0.5，1］：需求讨论／需求拆解／优先级排序
3. 产品的（1，＋∞）：产品优化

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

两点解释：

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

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

一、产品的［0 ，0.5］

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

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

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

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

（3）所需资源：

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

（4）操作方式：

• 一边讨论，一边将想要的功能写在卡片上
• 一边讨论，一边将功能分类，按照x轴为模块名称，y轴为所属模块下的功能进行排列

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

  
  
  image.png

（5）解释／说明／tips：

• 为什么是2-3个人：

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

• 如果只是理个产品逻辑为什么不用脑图：

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

2，发布规划

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

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

（3）所需资源：

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

（3）操作方式：

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

• 制定产品发布计划，确保每一次的发布内容都是 MVP

  
  
  image.png

（4）解释／说明／tips：

• 怎么划分发布周期

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

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

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

二、产品的（0.5 ，1］

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

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

（1）目的：与开发人员准确、高效地确认需求
（2）适用场景：产品的某一个迭代，需要确认需求
（3）所需资源：

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

（4）操作方式：

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

image.png

（5）解释／说明／tips：

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

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

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

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

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

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

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

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

（4）操作方式：

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

image.png

5）解释／说明／tips：

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

3，优先级排序

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

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

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

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

（4）操作方式：

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

image.png

三、产品的（1，＋∞）

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

旅行地图

（1）目的：着眼全局、完整查看用户交互路径，发现用户痛点、寻找机会。
（2）适用场景：用户路径明确、产品复盘
（3）所需资源：

• 3-7 名参与人员（需包涵产品设计者、产品决策者、用户体验设计师）
• 不同颜色的便利贴／卡片

（4）操作方式

• 用户操作路径，每一个触点按步骤写在便利贴上，在 x 轴排开
• 在每个触点下方（沿 y 轴），标明用户的操作场景（比如时间、环境等可能的因素）、行动、问题
• 团队人员浏览全局，针对每一个触点提出疑问，进行讨论
• 得出痛点和收获

image.png

用户体验地图

（1）目的：用户调研数据处理，确定产品的优化点与优化需求
（2）适用场景：用户调研数据处理
（3）所需资源：

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

（4）操作方式

• 用户操作路径，每一个触点按步骤写在便利贴上，在 x 轴排开
• 用户操作、评价数据（优/劣）、用户想法/感觉、用不同的便利贴写在便利贴上，在 y 轴排开
• 综合每个触点上的评价数据，进行打分
• 根据得分，调整触点卡片的y坐标,得分高的卡片位置越高、得分低的卡片位置越低，得出用户情绪曲线（ emotion journey ）
• 全盘思考，找出机会点，将机会点写在便利贴上，贴在对应的触点下方（如下图的粉色便利贴）

image.png

两者的差别

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

笔者英语程度有限，感兴趣的同学可以直接看视频（视频长度2分49秒，观看需自备轻功）：
Customer Journey Mapping vs. Experience Mapping

One More Thing：

关于《用户故事地图》这本书的一个小方面的总结到这里就结束了。其实关于这本书，我认为里面真的讲了很多很实用的方法，能够帮助你更好地协作、更好地思考产品。它能够让产品设计师、产品经理、交互设计师们去更有效地整理思路、更有效地找出解决方法、更有效地统筹全局。
希望大家能够拉上身边的小伙伴去试一试，也许会发现一个完全不一样的世界呢~

COVER FROM:http://coffee.pmcaff.com/article/1265700889032832/pmcaff?utm_source=forum