《用户故事地图》不仅仅是讲述什么是用户地图、怎么使用用户地图，也讲了很多团队协作的tips，并且给出了很多实例。我这里直接从这本书的其中一个角度——“怎么使用用户地图”为内容，然后结合一些自己的想法，来写这篇读书笔记。
之前读完 Jeff Patton 的《用户故事地图》觉得是一本好书，但是一直没有机会去实践。
最近在工作中使用了用户体验地图进行云之家工作汇报轻应用的开发评审，发现在讨论过程中，思路更加清晰、交流更加顺畅了。
具体表现在：
开发人员能够很容易发现产品设计的坑；
小组成员的参与度更高；
决策更加迅速，会议更加高效；
会议结束后，有满意的讨论结果产出。
会后，更加觉得用户故事地图是一个可以提高协作效率的工具，所以，想写一篇“读书笔记&执行思考”，来记录这段时间的收获。
《用户故事地图》不仅仅是讲述什么是用户地图、怎么使用用户地图，也讲了很多团队协作的tips，并且给出了很多实例。我这里直接从这本书的其中一个角度——“怎么使用用户地图”为内容，然后结合一些自己的想法，来写这篇读书笔记。
用户故事地图的使用，主要可以分为三个方面（当然，这个只是我自己的一个归纳）：
产品的（0.5，1］：需求讨论／需求拆解／优先级排序
下面将根据以上三个方面，详细进行说明。
两点解释：
我很粗暴的根据 “是否需要开发人员介入” 这一条件，将产品发版前分为两部分，即产品的［0，0.5］，产品的（0.5，1］。在开发人员介入前，更多的是产品经理如何进行产品设计，产品整个的基调和走向都是在这一部分定下来的。当开发人员开始介入后，就具体聚焦于功能的实现方面了。能否实现？如何更好的实现？是这一部分的主要问题。但是要解决这一部分的问题的一个大前提就是，开发人员如何全面的理解这个产品？让大家脑海里的东西是一致的？这个是最艰难的问题。
上面三点的“产品”，其实不仅仅指的是一个完整的产品，也可以是一个组件、一个大型功能。总之是需要进行思考、设计、开发并之后会有维护升级的一个模块。
一、产品的［0 ，0.5］
当产品或某一个大型模块在进行功能设计的时候，可以采取用户故事地图的方式来梳理所有的功能点，并进行迭代周期的规划。
（1）目的
建立产品／模块的全局印象，有全局观，进而可以整体规划产品／模块。
（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）所需资源
产品全景图
（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，＋∞）三个大的阶段。希望对大家能有所帮助。
