用户故事地图浅析.docxVIP

用户故事地图浅析 无论你在团队中担任什么角色，想要让自己的产品更由于价值，提升用户体验。那么就离不开一定的需求规划能力。用户故事地图目前已经成为敏捷需求规划中的一个流行方法，但可能还有很多同学不太了解。作者结合了自身的工作经历为我们分享了用户故事地图该怎么用。 　　中后台产品大多通过产品化工具来给用户提效，随着用户的应用场景开始延伸到线上线下各个角落，设计师也开始思考如何从时间空间维度去关注完整的用户体验。 　　因此用户故事地图作为一种常见工具，进入了大家的视野。但是体验地图到底能解决什么问题，该怎么用呢？很多同学也许并不太了解。 　　这次分享主要是将我们在各类渠道了解到的关于用户体验地图的各类说法做了一个总结，并结合了我们在工作中的实际运用，给有兴趣了解该方法的同学提供一点我们的见解和看法。 　　如有不赞成地方或更好的见解，希望可以不吝赐教，我们相互学习，共同进步。 　　用户发现你提供的产品真正的价值，往往要经过一段旅程，必定不是一马平川。 　　通过我们的专业知识、见解和洞察搞清楚用户这段旅途当中坑在哪里、怎么填才能让用户走的更顺。帮助用户更容易获取产品价值，帮助项目组获得成功。 　　用户故事地图虽然是一个耳熟能详的体验工具，但事实上当你接触的时候才知道并不容易。 　　其中需要注意的要点很多，能找到的模型也很多样，导致做一个正确的方向变得复杂，结果可能会产出一个适得其反的用户故事地图，或者什么都没有产出，那我们到底该怎么做呢？ 　　我们在支持项目的过程中，初期会选择采用“故事编写工作坊”的形式来梳理产品的用户故事地图。一般是项目组成员共创的形式，参与人员包括：技术开发、产品经理、项目经理、设计师、用户、产品老大。 　　重要流程分成四个步骤： 　　产品定义 梳理骨干故事 拆分故事 沟通确认 下面我简要介绍下这四步分别需要做哪些事情。 　　一般是在故事编写工作坊准备阶段，首先由PD提主导产出，主要有几点内容： 　　（1）产品的目标用户 　　（2）解决了哪些问题 　　（3）用户目标 　　（4）产品目标 　　将这些内容记录在黑板上，与大家讨论达成共识，最终确定产品定义。简单来说，需要明确“我们为什么要做这个？”以及“用户为什么要用这个？” 　　明确业务诉求和用户诉求为之后的设计提供了指导，不仅可以在接下来的讨论的过程中不易迷失方向，还可以避免陷入设计细节纠结。基于业务诉求和用户诉求其实就是为了不忘初心，是为了明确设计的初衷。 　　所以，在做交互设计之前，一定要问自己这两个问题：“这能给我们带来什么价值？”、“这能为用户提供什么价值？”这一步可以让项目组内所有人和用户共同明确产品覆盖的整个范围。 　　为了方便大家理解，我在这里举一个大家生活都会发生的例子。 　　故事的整个范围：起点是起床，终点是到达公司。闭上眼睛，回想一下今天早上起床的过程。 　　把这段故事分成这样几个阶段：起床——洗漱——穿衣——出门——上班途中——到达公司。 　　在真实做项目过程中，大家在这一步可能会写出不同颗粒度的故事，需要设计师把控故事的大小，这段故事可以再往下梳理一层颗粒度更小一点的故事。 　　比如起床就可以再拆分为：闹铃响了——挣扎——关闹钟——下床。剩下的故事卡片都可以继续这样拆分归类。 　　这样我们骨干故事就有两层，一级故事和二级故事，故事的发生从左至右是一个叙事流。 　　这里需要注意的是，在真实业务中，故事的流程不可能是一帆风顺的，情况会变得复杂，我们可以借助流程图的图例线连接我们的故事卡片。 　　总结一下，我们在这步怎么做的。 　　首先，我们在第一步确定产品整体范围之内尽量把故事讲完整，比如我们这个例子，起床——洗漱——穿衣——出门——上班途中——到达公司。这样我们项目组的所有人就可以对整个产品有个全局的印象。 　　其次，我们需要注意是要讲完整的故事，但是一定要广度优先，而非深度，要做到一公里宽一厘米深。 　　比如刷牙这个故事里面，找牙刷、挤牙膏这类故事在这个阶段我们无须关注，不要过早地沉浸到细节中。在这步让大家做到对产品只见森林不见树木的状态。 　　在这一步，我们需要在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。 　　如果二级故事是一个海平面的话，那二级故事以上就是海平面故事，那现在我们需要关注的是海平面以下更多不可见的故事。项目组会围绕这个故事写出很多细节来。 　　我们可以按照以下几个维度对细节进行归类，分别是：故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得，也可以通过用户想法、用户的痛点结合主观判断。 　　在这个过程中，先让大家在一定时间内按照自己的想法写出来，每一条写在一张卡片上，做到相互不干扰，然后每个人出声说出自己的卡片内容，让所有人了解并贴在墙上。 　　项目组人在写想法的时候，相当于脑暴的