用户体验地图 用户体验地图为什么这么好使？来看蚂蚁金服的实战案例就知道了

用户体验图作为一种常用工具，可以让工作更加顺畅，在团队协作中起到很好的作用。产品、设计和开发可以熟悉易懂，便于整理产品的结构和使用过程。

但是体验地图能解决什么问题，如何使用呢？很多同学可能不太了解。本次分享主要是总结我们从各种渠道了解到的关于用户体验图的各种说法，并结合我们在工作中的实际应用，为有兴趣了解这种方法的同学提供一些感悟和见解。

本文的图文内容来自蚂蚁金服技术部门分享的“奶酪俱乐部”。

本文将分为五个部分:

如何做

提高效率

价值

总结

相关材料

大多数中后端产品使用产品化工具来提高用户效率。随着用户的应用场景开始延伸到线上线下的各个角落，设计师们也开始从时间空维度思考如何关注完整的用户体验。

用户发现你提供的产品的真正价值，就像这个封面的背景图一样，往往要经历一段旅程，绝对不是马平川。通过我们的专业知识、感悟和洞见，我们可以发现这个旅程中的坑在哪里，怎么填，让用户走得更顺畅。帮助用户更容易获得产品价值，帮助项目团队取得成功。

1.怎么做

用户故事地图虽然是一个大家熟悉的体验工具，但是当你触摸它的时候并不容易知道。需要注意的点很多，可以找到的模型也很多，这就使得做出正确的方向变得复杂。因此，它可能会产生适得其反的用户故事地图，或者什么也没有。那么我们该怎么办呢？

在项目支持过程中，我们会选择“故事写作工作坊”的形式，整理出产品初期的用户故事图。一般由项目团队成员创建，参与人员包括:技术开发、产品经理、项目经理、设计师、用户、产品负责人。

重要流程分为四个步骤:产品定义-梳理骨干故事-拆分故事-沟通确认。

我简单介绍下四步需要做什么。

第一步:产品定义

一般来说，在故事写作工作坊的准备阶段，输出首先由PD牵头，主要包括以下内容:

产品的目标用户

解决了哪些问题

用户目标

产品目标

把这些内容记录在黑板上，和大家讨论达成共识，最后确定产品定义。简单来说，我们需要明确“我们为什么要这样做？”和“用户为什么使用这个？明确业务需求和用户需求，为后续设计提供指导，不仅在接下来的讨论过程中不易迷失，还避免陷入设计细节的纠结。事实上，基于业务需求和用户需求，是为了不忘记你的主动思维，是为了澄清设计的初衷。所以，在做交互设计之前，一定要问自己这两个问题:“这能给我们带来什么价值？”这能给用户提供什么价值？这一步允许项目团队中的所有人和用户共同定义产品覆盖的整个范围。

第二步:整理骨干故事

为了方便大家理解，我举一个每个人的人生都会发生的例子。故事的整个范围:起点是起床——终点是到达公司。闭上眼睛，想想今天早上起床的过程。把这个故事分成几个阶段:起床-洗漱-穿衣-出门-上班-到公司。

在真实项目的过程中，每个人都可能在这一步写不同粒度的故事，这就需要设计师控制故事的大小。这个故事可以向下梳理到一层粒度较小的故事。比如起床可以分为:闹钟响了——挣扎——关闹钟——起床。剩下的故事卡可以继续这样拆分分类。

这样，我们的骨干故事有两层:一级故事和二级故事。故事的发生是一个从左到右的叙事流程。

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

综上所述，这一步我们做了什么？首先，第一步，我们尽量在产品的整体范围内讲述整个故事。比如我们这种情况，起床，洗漱，穿衣，出门，上班路上到公司。这样，我们项目团队的每个人都可以对整个产品有一个全局的印象。其次，需要注意讲一个完整的故事，但一定要以广度为主，不能以深度为主，要做到一公里宽一厘米深。比如刷牙的故事，这个阶段就不需要关注找牙刷挤牙膏这类故事，也不要过早的沉浸在细节中。在这一步中，让每个人都处于只看到森林而看不到产品树的状态。

第三步:拆分故事

在这一步中，我们需要在刚刚梳理的每个二级故事下停下来，对二级故事进行拆分，以获得更多细节。如果说次要故事是海平面，那么次要故事上面的故事就是海平面故事，现在需要关注更多海平面以下的隐形故事。项目组会围绕这个故事写很多细节。我们可以按照以下维度对细节进行分类:故事细节、想法、痛点、机会、情绪。情绪可以通过固定的问题获得，也可以通过用户的想法和痛点结合主观判断。

在这个过程中，让大家在一定的时间内根据自己的想法写出来，一个个写在一张卡片上，这样才不会互相干扰。然后，大家把自己卡上的内容说出来，让大家都能看懂，贴在墙上。

当项目组在写想法的时候，就相当于脑暴力的过程。这时，有些问题可以用来刺激人们迸发出更多的内容，比如:

用户在这一步做什么？

用户还有其他选择吗？

用户可以做什么来更享受？

如何处理问题？

其他用户来了怎么办？

回到我们的例子，我们洗澡的时候有一个正常的流量，但是没有热水的时候这个流量就变了。同样，在现实的商业中，这种情况会更常见，所以我们会更关注这一步中所有场景的故事。

经过这一步，我们已经获得了足够详细的信息，整个项目团队将处于见林见树的状态。

第四步:沟通和确认

在这里，我们的故事变得丰满甚至臃肿，所以沟通和确认变得极其重要。这一步我们需要花很多时间。我们会对内容进行基准化，充分讨论，把接受的抛在脑后，拒绝无用的。同时可以区分故事细节要做的优先级。

以此类推，当所有的故事都被整理出来后，一个完整的用户故事地图就完成了，如下所示。

总结一下。首先，我们需要标记所有人写的卡片，排除无效的故事。其次，因为我们通常没有足够的项目时间，缺乏开发资源，不可能一口吃掉一个胖子，所以达成共识做什么，分清轻重缓急就显得尤为重要。最后，不是所有的故事卡都需要同时细化。在实际业务中，有些模块的故事在开始时无法梳理清楚，可以先写一个占位符，在合适的时候拆分。

通过这个格式一致的清晰故事图，可以让所有的项目团队获得足够的信息，让项目有一个清晰的开发流程。

回头再看，我们通过这四个步骤整理出产品的故事图，里面有很多细节，以后会总结出来分享给大家，这次就不做过多的描述了。

当真正的业务落地的时候，我们会发现，因为一般的项目时间都很紧，这样一个完整的流程会很重很费时间，所以一直在思考如何提高效率。

二.提高效率

目前，我们通过三种方式提高效率，即事件前和事件后。

1.事先

我们制作了一个Excel故事地图制作模板，可以在故事写作工作坊开始前一两天发给参与者，让大家以相对结构化的方式对产品进行整理和思考，有助于提高工作坊的产出量和质量。

2.在这件事上

如果是需要优化的产品，可以打印出设计草图演示或者在线产品截图，可以增强人们的代入感，提高输出质量。

3.后来

我们制作了Axure的经验地图整理模板，方便快速整理电子版，高效传播我们的讨论内容。

最后，我想说一下这个方法的价值。你可以自己判断什么商业背景适合这个方法。

三.价值

1.共识；一致

在过去，我们设计师在两个方面达成一致:一个是文档，当我们看着它们时，那些格式化的语言就成了世界上最好的摇篮曲。读书写字的人会怎么样？写文件的PD肯定会在脑子里回响一个问题:有人仔细看过这个东西吗？

看文档还是不错的，PD直接拉你和你聊天，手动画几个线框的情况比较多。即使移交了需求，这两种方法都可以用于下一步的界面设计，但是你确定你收到的是真实的需求吗？而且这里的共识是点对点，或者单点对多点，信息传递也会带来信息内容的流失，甚至是错误的信息。

这里说的共识有什么区别？

在用户故事地图的过程中，要做到多角色多视角，尤其是中后端产品，不仅仅是估算用户需求。

项目中不同的参与者有不同的需求，PM想要跟踪进度，开发者想要实现，产品经理想要功能，产品所有者有更高的视角，用户想要一个可用的系统。在这些相互冲突的视角中，很难做出一个大家都支持，都开心的决定，也很难持续保持平衡。整个项目团队就像一个四驱。一个角色的力量相当于一个轮子转得太快，对产品是一种损失，导致车的方向偏离。我们让项目组所有的人，包括用户，在800英里空的高度俯视产品，这种同空内多点到多点的共识自然就完成了，应该是在空之前。

再比如，在很多情况下，当我们通过文档交流的时候，我们会认为我们理解了，我想的就是你想的。

但是如果我们说，写，画自己的想法，可能会发现你想的和我想的不一样。

故事图的方法是基准每个人的想法，通过讨论达成一致。

最后理想状态是我以为的就是你以为的。

2.同感

当我们真正支持中后端产品的时候，在设计上有一个很大的问题，就是没有同理心，业务上很多专有名词会比较弱，甚至同一个项目团队不同模块的人都不理解对方的专有名词。

故事地图是如何解决这个问题的？

下面举个例子。如图，我们所有人都能很快知道用户想要什么，为什么要这样。通过这种简单明了的场景还原方式，大家更容易理解每个故事。我们站在用户的频道上，说着人话。

3.参与式设计

参与式设计的反面是经验式设计。在新产品的设计中，设计师观察未来的用户，充分发挥产品的各种效果。经验性设计高度依赖于之前的用户调查，包括用户访谈和用户观察，但用户不会成为产品设计的真正参与者，后期基本依靠设计师体验，几乎没有用户。

用户故事图是吸引用户设计自己需要的产品的便捷手段。我们原型设计阶段的所有内容都来自用户故事图。因为故事地图涉及到用户的整个过程，用户在整个设计过程中是在场的。

用户故事易读易懂。我们边聊故事边画页面框架，这样可以激发用户的积极性，成为产品设计的参与者。同时，随着用户逐渐掌握如何口头表达故事来描述自己的需求，项目团队成员和用户之间的关系变得更加亲密和主动，这种良性循环惠及所有人员。

4.记录

我们过去记录的方式有几种:文档记录、笔记记录或聊天记录。这些方法多为单点到单点或多点，录制内容有限。

记录用户故事地图有什么区别？

为了方便大家理解，这里我再举一个例子。当你看到下图时，这张图片传达给你的信息是什么？大部分人得到的可能是肤浅的信息，比如玩得开心，沙滩上的美景，等等。但是这张照片向照片中的人传达了很多信息。比如，当我看到这张照片时，我会记得我们开了一个小时的车来到海滩，脱掉鞋子，走了进去。万老板没来休息，我们请了当地的导游给我们拍照，等等。

对于照片中的人来说，这张照片不仅仅是一张照片。同理，故事地图中的每张卡片，不仅记录了卡片的内容，还记录了大家围绕这张卡片讨论的时间段内的所有信息，记录的信息更大。

当我们回头看这些卡片时，就像看照片一样，它会很快让我想起那个时候。

四.总结

我们梳理出用户故事地图的这四个价值，即共识、共情、参与式设计和记录。

再加上我们故事地图的四个步骤:产品定义——梳理主干故事——拆分故事——沟通确认

我们想通过这种方法保持范围层的稳定性，这样可以更好的做原型设计。

我想强调的是，在复杂的产品中，不要试图在项目一开始就做出一套保罗万象的决策。相反，故事总是伴随着产品的生产周期，所以我们应该把所有的决策分散到项目过程中。所以要保证一个获取信息的流程和方法，这是一个良性的用户故事图。

这里还有一个比喻。良性用户的故事就像一个钓鱼的过程。

首先，不同大小的网用来捕捉不同大小的故事。第一次，我们可以用大网眼网在故事池中钓鱼，得到所有的大故事。通过大故事，形成产品的整体感觉，再用网孔略小的渔网，获得中等大小的故事，暂时不考虑那些小需求。最后是最低需求。

其次，钓鱼表达了另一层意思。就像钓鱼，故事会随着时间的推移而成长，会有新生的鱼或者死亡。有些需求在某个阶段并不重要，但会像鱼一样成长，随着产品阶段的不同，变得越来越重要。有些需求我们曾经认为很重要，但随着产品阶段的不同，它们会逐渐变得不那么重要，有时甚至会减少到我们的任务。

最后，就像钓鱼一样，我们不能捕捉到这个区域的所有鱼，也不能捕捉到所有的需求。另外，我们钓鱼的时候可能会抓到一些废弃物和碎屑，这不是故事。

从上面的比喻可以看出，在项目前期不可能正确的捕捉并写出需求的所有故事，使用用户故事图的方法也不可能在单个阶段捕捉到用户的所有故事。用户故事不是二维的产品，应该是三维的。时间要加，产品的新用户故事要随着时间的推移和产品的不同阶段而加。捕捉故事的渔网总会改变。

通过用户故事的方法，不仅可以知道哪些坑是怎样填的，还可以知道哪些坑是先填的，哪些坑是后填的。怎么填比较好？这种判断需要我们在使用中总结经验。

转载自:蚂蚁金服用户体验技术部