以往我们设计师共识的方式有两种：一种是文档，翻开一看，那些格式化的语言就变成了世界上最好的催眠曲。读尚且如此，写的人会怎么样?写文档的PD脑子里一定会回响一个问题：这东西写了有人认真看么?

　　有文档看还是好的，还有更多情况是PD直接拉上你找你聊，手绘几个线框图，就算交接需求了，这两种方式都可以进行接下来的界面设计，但是你确定你收到的就是真实的需求么?而且这里的共识是点对点的，或者单点对多点的，信息传递也会带来信息内容的损耗，甚至错误的信息。

　　这里提到的共识有什么不同?

　　用户故事地图过程中做到多角色、多视角，尤其是中后台产品不只是单纯的估计用户需求。

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

　　再举一个例子，很多情况我们通过文档沟通，会以为我们了解了，认为我以为的就是你以为的。

　　但是如果我们把各自的想法说出来、写出来、画出来，我们可能发现你以为其实不是我以为的。

　　故事地图这种方法就是：通过讨论把大家的想法对标，达成一致。

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

　　2. 同理心

　　我们在真实支持中后台产品时，设计有一个很大问题就是无同理心，面对业务里很多专有名词会很无力，甚至同一项目组不同模块的人都相互不理解对方的专有名词。

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

　　这里举了一个例子，如图所示，我们所有人都可以快速知道用户想要什么，为什么要这个。通过这种简洁明了、场景还原的方式让大家都更容易理解，每个故事我们都做到站在用户的频道，说人话。

　　3. 参与性设计

　　与参与性设计对立的是经验性设计。新产品的设计，都是设计者通过观察未来用户以及发挥产品的各种效用各种情形。经验性设计高度依赖前期的用户调研，包括用户访谈和用户观察，但是用户不会成为产品设计的真正参与者，后面的阶段基本是靠设计师经验，几乎没有用户身影。

　　用户故事地图是一个吸引用户参与设计他们所需产品的便捷手段。我们原型设计阶段的所有内容来源于用户故事地图，因为故事地图是用户全程参与的，所以在我们整个设计过程中都有用户的身影。