关于用户故事地图的7种用法.docVIP

关于用户故事地图的7种用法 　　《用户故事地图》不仅仅是讲述什么是用户地图、怎么使用用户地图，也讲了很多团队协作的tips，并且给出了很多实例。我这里直接从这本书的其中一个角度——“怎么使用用户地图”为内容，然后结合一些自己的想法，来写这篇读书笔记。 　　 　　之前读完 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，跑题太可怕，降低会议效率且达不到目的