说人话、少吵架！被“姐夫（Jeff）”称为「共情雷达」的用户故事

【水伯】《消费者洞察指引》作者，stygoogle创始人；

移动网络时代唯一壁垒就是认知，周二有约给思想洗澡让认知破壁！

用户故事地图

说人话、少吵架！被“姐夫（Jeff）”称为「共情雷达」的用户故事地图火了

引语：不说人话，光打架！

近日，产品经理来福和程序员喜顺打架的视频火了。

来福和喜顺负责开发中国某想的App；产品经理来福突发奇想，要求App的基色能够根据手机壳的颜色自动调整。

程序员喜顺觉得这个要求太过分了，于是一言不合打了起来。

后来中国某想声称这两名员工是外包人员，已被开除。

为程序员喜顺惋惜，但毕竟你我不是当事人，只能想象却无法体会到他的愤怒；为产品经理来福顿足，他应该好好学习并应用“用户体验地图”，否则也不会提出这么无聊的需求。《用户故事地图》作者姐夫(Jeff Patton)解释道：故事定义了我们的世界，从洞穴的墙壁到篝火旁的传说，自从有了交流，故事就一直陪伴我们。虽然故事在不断演变，但目的依旧是：“娱乐、分享、传承”。因此，“讲故事”不仅是吸引用户的手段，更是一个让企业更了解用户的有效方式。数据常常无法清晰传达出用户使用产品的挫败感和体验度，故事却可以做到，商业领域讲故事的最好工具就是用户故事地图。 用户故事地图的最大的贡献，不是引入了三个新的令人困惑的层级，而是把时间引入到需求的空间结构中。这种革命，无异于在二十世纪初期，爱因斯坦告诉人们宇宙是由三维空间和一维时间组成的。

一、用户故事地图，神奇的「共情雷达」

用户故事地图是以视觉化呈现用户为达成某一目标所历经过程的工具，通过创建历程图，能够更好地理解目标用户在特定时间里的感受、想法和行为，认识到这个过程的演变过程，寻找用户的痛点，通过讲故事（Storytelling）的方式描述用户的体验过程，采用视觉化（Visualization）的方式将信息高效简单明了的呈现出来，便于记忆与团队分享。

用户故事地图：一张第一人称视角的图，用来了解用户与产品、服务、系统交互时的体验和关系，从全局角度定位体验关键点和洞察点。

1、用户故事地图的本质特征：「共情雷达」

首先是共情，用户故事地图是第一人称视角的图，从用户的角度出发，审视整个体验过程。同时，用户体验地图中重要组成部分为用户画像，我们知道用户画像代表一类用户，因此一张用户体验地图只是从第一人称视角出发，讲述这一类用户的体验过程，并不能适用所有情况。

其次，用户故事地图从全局、包括时间维度的角度挖掘用户与产品、服务和系统交互时的体验和关系，尤其适用于多场景、流程化、平台多、关系人多的产品和服务。例如各种O2O、网络叫车、看病就医等。

第三，用户故事地图通过用户故事深入挖掘和锁定产品、服务引发强烈情绪反应的雷达，从而照顾到用户的情感需求，有利于情感化设计。

2、用户故事地图核心结构

每一张用户故事地图都会因场景不同而各不相同，但一般而言，它们都包括：“Lens”（用户视角），体验的流程，机会点洞察三大区块。

1）Zone A：Lens区域包括

（1）用户的人物画像（“who”）以及产品的使用场景（“what”）。

（2）为旅程地图提供基本的人物情境设定。

2）Zone B：是旅程地图的核心部分，包括用户体验历程的各个阶段划分

（3）用户的活动。（4）任务。（5）感受。（6）根据用户调研反馈填写。

3）Zone C：此区域会因各项目商业目标的不同而不同：

（7）未来的机会点。（8）企业内部执行计划。

二、为什么“用户故事地图”有「共情雷达」之称？

因为手机、社会化媒体和网络正在改变用户行为，因此企业需要更加聚焦用户需求，以用户为中心。用户故事地图是一个强大的共情工具，如果你是产品经理，它会帮你理解用户的使用场景，清晰地了解用户来源以及他们试图达到怎样的目的；如果你是内容运营，它将帮你理解用户遇到的问题以及他们的感受，并且可以提供给管理者用户体验的全景图，看到用户是如何在销售漏斗中流动的，进而提升用户体验。此外，用户故事地图还可以呈现出用户服务的提升是如何改变消费体验的，洞察到用户体验中的断层和痛点等等。有鉴于此，我们梳理出用户故事地图被称为「共情雷达」，所体现出的四大价值“共识、同理心、参与性设计以及记录”。

1、共识

项目里不同的参与者有不同的需求、PM想跟踪进度、开发人员想实现、产品经理想功能、产品老大有更高的视角，而用户想要一个可用的系统。在这些充满冲突的视角中，想要做出一个人人都支持、皆大欢喜的决定，并且持续保持平衡是很困难的事情。整个项目组就像一个四驱车，一个角色的强势就相当于一个轮子转的过快，这对产品都是损失，导致车子的方向偏移。我们通过大家一起建立产品全景图的方式，让项目组所有人包括用户站在八百里高空俯视产品，这种同一空间多点对多点的共识就自然的完成了，这种共识应该是空前的。

2. 同理心

同一项目组的人有一个很大问题就是无同理心，面对业务里很多专有名词会很无力，甚至不同模块的人都相互不理解对方的专有名词。那故事地图是如何解决这个问题的。这里举了一个例子，如图所示，我们所有人都可以快速知道用户想要什么，为什么要这个。通过这种简洁明了、场景还原的方式让大家都更容易理解，每个故事我们都做到站在用户的频道，说人话。

3. 参与性设计

与参与性设计对立的是经验性设计。经验性设计高度依赖前期的用户调研，包括用户访谈和用户观察，但是用户不会成为产品设计的真正参与者，后面的阶段基本是靠设计师经验，几乎没有用户身影。用户故事地图是一个吸引用户参与设计他们所需产品的便捷手段。我们原型设计阶段的所有内容来源于用户故事地图，因为故事地图是用户全程参与的，所以在我们整个设计过程中都有用户的身影。用户故事易读、易懂，边聊故事的同时进行页面框架绘制，因此能激发用户的积极性，成为产品设计的参与者。同时，随着用户渐渐掌握如何口头表达故事来描绘他们的需求，项目组成员与用户间的关系变得更加亲密主动，这种良性的循环使所有人员都获益良多。

4. 记录

我们以往记录的方式无非有几种：文档记录、笔记记录或者记录在聊天记录里面。这种方式大多是单点对单点或多点的，而且记录内容有限。用户故事地图的记录方式有什么不同？为了方便大家理解，这里我再举一个例子。大家看到下面这张图片，那这张图片传达给大家的信息是什么？大多数人得到的信息可能是你们玩的很开心，沙滩的风景真美等等这些表面的信息。但是这张照片对于在照片里的人传达的信息就多得多，比如看到这张照片会想起我们为了来这个沙滩开了一个小时车，脱了鞋走进来；我们找了当地导游给我们拍照片等等很多发生在那个时间段的很多细节信息。那对于照片里的人来说，这张照片不仅仅是照片。同样的道理，故事地图的每张卡片，记录的也绝不只是卡片上的内容，它记录了大家围绕这张卡片讨论的那个时间段所有的信息，记录的信息量是更加庞大的。

三、用户故事地图如何在需求拆分过程中保持全景视野？

故事地图是一门在需求拆分过程中，保持全景图的技术；是连接开发和设计的桥梁；可以使我们专注于用户和用户体验，产生更好的沟通效果，最终做出更好的产品。故事地图制作步骤会根据应用情况不同略有不同。常见的场景，如新产品规划、版本发布规划、现有产品需求梳理、需求拆解，优先级排序等等。虽然步骤略有不同，主体框架和原则是一致的。都是按照发散-收敛模式，都要讲故事而不是写故事等等。按照如下五个步骤，制作用户故事地图。并且按照用户故事地图的步骤，梳理可能用到的实践、方法或工具，建立用好故事地图的武器库。

Step1 创意框架：精益创业、商业画布/精益画布、价值主张画布、电梯测试等。

Step2 写大故事：用户画像/企业画像、客户旅行地图、影响地图等。

Step3 探索：设计思维、精益数据分析。

Step4 发布策略：MVP、“正好-更好-最好”游戏、MoSCoW方法、Kano方法、需求优先级矩阵。

Step5 开发策略：实例化需求

1、 创意框架

故事地图是从讨论机会开始。创意框架阶段，产品论到极致的三个问题：

-你的用户是谁？-你能给带来什么价值？-如何与他们建立连接？

1）精益创业

企业最大的浪费不是员工上班玩手机，而是构建出的产品没人用。精益创业的目标是，做一个能卖出去的产品，而不是卖一个能做出来的产品。精益创业思维，在整个过程中都有渗透，如用户故事的发布策略，影响地图选择优先级等。

2）商业画布

一页纸的商业画布，更容易让我们抓住商业本质。商业画布聚焦创业者的同时，更聚焦执行。

3）价值主张画布

价值主张是指对客户来说什么是有意义的，即对客户真实需求的深入描述。价值主张地图可以与商业画布很好结合使用。同时，为后续用户细分打下基础。

4）电梯测试

在乘电梯的30秒内清晰准确地向客户解释清楚解决方案。以精炼的语言刻画产品服务于谁，解决什么问题，产生什么价值，有什么优势。相似的工具有愿景图、封面故事等，目的是明确产品愿景，让整个团队对产品目标达成共识。

-为了.........(目标用户)；

-他们的.........（痛点和业务目标）；

-这个.........（产品名称）；

-是一个.........（产品类型）；

-它可以.........（为客户做什么，带来什么价值）；

-而不像.........（主要竞争对手）；

-我们的产品.........（主要差异优势）

2、写大故事

这一过程主要是，确定关键用户，讲完整故事，重广度而非深度。

1）用户画像/企业画像

针对不同场景对用户进行分类，给每类用户建立用户画像。

-尽量使用真实的用户画像，而不是使用虚拟画像；

-尽量描述行为，而不是用基本属性区别；

-画像是为场景服务，不要脱离场景讨论它；

-对于ToB业务，可以绘制企业画像；

-有时可用移情图，丰富用户画像。

2）客户旅行地图

客户旅程地图讲述了用户经历的故事：从初次接触，形成契约，进入到一个长期合作关系；目的是更快的了解用户。工具在后续的探索中也可以使用，通过了解用户体检，寻找痛点、痒点和改进点。

-它可以关注故事中特定的部分，亦或给出一个完整体验的全貌。

-它总是在确定用户与组织的关键交互行为。

-它讲述了用户的感受、动机以及在每一次点击遇到的问题。

3）影响地图

通过影响人的行为来影响目标。对什么样的人，产生怎样的影响，才能帮助实现目标；

提供什么样的产品功能（或服务），才能产生这样的影响。

3、探索

该步骤主要探索细节、风险等，面对着地图，讨论：

-用户在这一步做什么？-还有其它选择么？-存在什么风险？-有何替代方案？-如何用的更爽？

1）设计思维

把创意像公式一样“推导”出来的方法。设计思维是一种以人为本，以用户为中心的设计方法。解决问题，要从人的需求出发，多角度地寻求创新解决方案，并创造更多的可能性。设计思维不仅仅是一套流程，还包括很多实用工具或方法：

2）精益数据分析

精益数据分析是精益创业在度量过程中的一个有效补充；在制作故事地图时，对设立目标、故事探索都要充分考虑度量内容；挑选一个唯一的对你当前阶段无比重要的指标为第一关键指标（OMTM）；

4、发布策略

发布策略一步骤核心关注问题：

-如何制定发布策略；-如何需求排序。

关于优先级排序，补充要点：为特定的业务目标、客户和用户确定优先级，然后再为他们目标确定优先级，最后才是功能。（特别是ToB业务，客户可能有自己目标，或政治任务，需要优先满足）

1）MVP（最小可行产品）

最小可行产品是为了验证假设而做的最小规模的实验。聚焦于成果，即产品发布后用户能使用和感知的东西，切分发布计划应以成果为导向。

2）“正好-更好-最好”游戏

这是一个分解故事的简单技术之一。实际上也可以用在发布策略上。

-正好：一开始讨论什么是正好，只是正好而已，解决基本问题；

-更好：讨论如何变得更好，基本让用户满意；

-最好：讨论如何变得最好，可能会超出用户预期。

3）MoSCoW方法

区分出哪些是必须做，应该做，可以做，和不要做的需求。

4）Kano方法 卡诺模型

KANO模型来说明产品需求与用户反应的潜在关系。基本型需求必须满足，期望型需求要清晰明了，兴奋型需求是引爆的关键。

5）需求优先级矩阵

根据价值和风险确定需求优先级，优先完成高客户价值高风险部分。这些需求都属于重要的需求，尽管实现起来很困难，但我们必须有足够的时间（精力）去处理它。横轴的“风险”也可以换为“复杂度”，则变为价值-复杂度矩阵，优先级顺序不变。

5、开发策略

该部分主要解决问题：如何制定开发计划？如何让需求与开发过程更好的结合？

-通过“开局、中局、末局”策略切分需求，制定开发计划。

-运用迭代思维持续评估和打磨产品，运用增量思维做加法。

-想做的事情总是缺人缺时间，制定产品开发的MVP。

-少即是多，最小化输出，最大化成果和影响。

1）实例化需求

以终为始，从目标中获取范围；实例化需求说明可以帮助构建正确的产品，而技术实践可以确保产品正确的构建；

2）测试

实例化的需求说明就是测试，测试也是需求说明。以此打破需求沟通中知识的诅咒。

四、复盘：蚂蚁金服使用用户故事地图的实战案例

用户故事地图虽然是一个耳熟能详的体验工具，但事实上当你接触的时候才知道并不容易。其中需要注意的要点很多，能找到的模型也很多样，导致做一个正确的方向变得复杂，结果可能会产出一个适得其反的用户故事地图，或者什么都没有产出，那我们到底该怎么做呢。蚂蚁金服在实操项目的过程中，初期会选择采用「故事编写工作坊」的形式来梳理产品的用户故事地图。一般是项目组成员共创的形式，参与人员包括：技术开发、产品经理、项目经理、设计师、用户、产品老大。重要流程分成四个步骤：

-产品定义；-梳理骨干故事；-拆分故事；-沟通确认。

1、产品定义

一般是在「故事编写工作坊」准备阶段，首先由PD提主导产出，主要有几点内容：

1）产品的目标用户；2）解决了哪些问题；3）用户目标；4）产品目标；

将这些内容记录在黑板上，与大家讨论达成共识，最终确定产品定义。简单来说，需要明确：

「我们为什么要做这个？」以及「用户为什么要用这个？」

明确业务诉求和用户诉求，为之后的设计提供了指导，不仅可以在接下来讨论的过程中不易迷失方向，还可以避免陷入设计细节的纠结。基于业务诉求和用户诉求其实就是为了不忘初心，是为了明确设计的初衷。所以，在做交互设计之前，一定要问自己这两个问题：

「这能给我们带来什么价值？、这能为用户提供什么价值？」

这一步可以让项目组内所有人和用户共同明确产品覆盖的整个范围。

2、梳理骨干故事

在这里以一个大家生活都会发生的事情为例。故事的整个范围：起点是起床——终点是到达公司。闭上眼睛，回想一下今天早上起床的过程。把这段故事分成这样几个阶段：起床——洗漱——穿衣——出门——上班途中——到达公司。

在真实过程中，大家在这一步可能会写出不同颗粒度的故事，需要设计师把控故事的大小，这段故事可以再往下梳理一层颗粒度更小一点的故事。比如起床就可以再拆分为：闹铃响了——挣扎——关闹钟——下床。剩下的故事卡片都可以继续这样拆分归类。这样我们骨干故事就有两层：一级故事和二级故事，故事的发生从左至右是一个叙事流。

这里需要注意的是，在真实业务中，故事的流程不可能是一帆风顺的，情况会变得复杂，我们可以借助流程图的图例线连接我们的故事卡片。

总结一下，首先，我们在第一步确定产品整体范围之内尽量的把故事讲完整，比如我们这个例子，起床——洗漱——穿衣——出门——上班途中——到达公司。这样我们项目组的所有人就可以对整个产品有个全局的印象。其次，我们需要注意是要讲完整的故事，但是一定要广度优先，而非深度，要做到一公里宽一厘米深。比如刷牙这个故事里面，找牙刷、挤牙膏这类故事在这个阶段我们无须关注，不要过早的沉浸到细节中。在这步让大家做到对产品只见森林不见树木的状态。

3、拆分故事

在这一步，需要在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。如果二级故事是一个海平面的话，那二级故事以上就是海平面故事，那现在需要关注的是海平面以下更多不可见的故事。项目组围绕这个故事写出很多细节来。可以按照以下几个维度对细节进行归类，分别是：故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得，也可以通过用户想法、用户的痛点结合主观判断。

在这个过程中，先让大家在一定时间内按照自己的想法写出来，每一条写在一张卡片上，做到相互不干扰，然后每个人出声说出自己的卡片内容，让所有人了解并贴在墙上。

项目组人在写想法的时候，相当于脑暴的过程，这时可以通过一些问题来刺激大家脑暴出更多的内容，比如：

-用户在这步具体做什么？

-用户还有其他选择么？

-用户怎么做才能更爽？

-出现问题如何处理？

-其他用户来到这里该如何处理？

回到实例，我们洗澡的时候有正常的流程，但当没有热水时这个流程就会发生变化。同样，在真实业务当中，这类情况将更普遍的发生，所以这一步我们将尽量多的关注到所有场景的故事。做完这步，我们已经获取到了足够多的细节信息，整个项目组都会做到对产品又见森林又见树木的状态。

4、沟通确认

这里故事已经变得很丰满，甚至变得臃肿，所以沟通确认变得极为重要。我们在这步需要花费相对多的时间，大家对内容进行对标、充足讨论，把公认的留下来，无用的剔除掉。同时可以区分要做的故事细节的优先级。依次类推，当所有故事梳理完成之后，就完成了如下这样一张完整的用户故事地图了。

总结一下。首先，我们需要对大家写的所有卡片进行对标，排除无效故事。其次，因为我们一般项目时间不够，开发资源紧张，不可能一口吃个胖子，所以把要做的事情达成共识排出优先级变得尤为重要。最后，并不是所有的故事卡片都需要在同一时间细化，在真实业务中有些模块的故事是无法一开始就梳理清楚的，所以可以先写个占位符，待合适的时机再做拆分。我们通过这种一目了然、格式一致的故事地图，让项目组所有人都获得足够的信息，让项目有一个明朗的开发流程。

彩蛋：关系＝信息;公众号：SFA-0002

一个女孩与一个男孩相亲，简单地收集数据的做法是问“你有多少存款啊？你有房吗？有车吗？月薪多少啊？“但这些数据只能代表这个人，作为当下这个“点”的截面特性，你能根据这些数据做决策吗？你知道这个人经历了什么，才成为今天的样子吗？

每个人对这些数据的解读，肯定是不一样的，而且各有各的道理，各有各的逻辑。大家拿着数据和逻辑PK，其实很难有说服力。量子物理中有个定义很有趣，关系＝信息。如何判断你跟一个人关系好不好，无非就是你知道多少他的信息，以及他的最新动态信息会有多少跟你同步。所以一个好产品是从“第一只羊”被真正被满足开始的。我们充分认识这“第一只羊”，能够完全用他的语言说话，你需要了解他的故事。一个好产品，是从一个好故事开始的。

-End-