别小看“讲故事”的力量，我们该学习讲故事的力量

我们常聊的用户故事

我有酒，你有故事吗？我们可以彼此说说故事，但这故事不是你的也不是我的，而是受众群体的。学习做过产品，跟一群大脑强悍程序员沟通，难免磕磕绊绊。现在学习做培训版块，记得J告诉我 用故事来沟通和交流，省了不少事，也少惹了很多麻烦。

他是产品经理当然有很强的沟通能力，和有场景思维，要有同理心，要有“零秒变小白”的能力。当然这些都是很好的思维习惯，但说多了容易形成某种幻觉，以为自己就是这么干的，最后麻木了不以为意。所以要时常问自己，是不是真的站在了受众群体的角度，是否真正理解了最真实他们舍去场景。其实这种场景思维不只局限于事件本身上，将这种方式应用在每个环节的角色上，会大大降低沟通成本。可使每个角色都更加了解自己参与的产品，更有成就感和责任感。

用故事进行沟通

同理心说得容易，其实做起来相当困难，大家不自觉地就会从自我出发，以为其他人都跟自己一样，你认为的就是别人认为的。以下是沟通过程模型图，先简单介绍下，发送方在沟通过程中处于信息传递的主动地位，是沟通的起点。发送方将需要传达的信息进行编码，编码后的表现形式可以多种多样，比如语言、文字、图形、动作或表情等等。通过不同的媒介（面对面、电话、电邮、互联网聊天等）与接受者进行交流。在传递过程中会对信息产生干扰的一切因素都可称作噪音，噪音越大，信息传递障碍越大，效率也越低。接受者处于沟通过程中的被动地位，对接受到信息需要进行解码，转化成需要的信息。

拿个实际工作例子来说，老板或运营部的人，准备将客户的需求传达给产品人员，假设他们都真正理解了客户的诉求（信息度100%），经过自己整理编码，信息完整度可能降到90%，然后经过一部分的噪音干扰，产品人员得到的信息可能降到80%，最后被自己的思维处理过滤，估计只剩不到一半的准确信息了。

谁要用这个功能？

使用这个功能的目的是什么？

什么时候会用？

...

负责任的人员会刨根问底，去挖掘对方真正的需求。否则只根据不到一半的信息度进行设计，浪费设计人员时间不说，还打击人家信心，同时影响整个产品进度。

经过几次这种低效沟通后，寻找发现问题的所在。然后我们开始用说故事的方式进行传达，因为不是C端产品，很多场景实际上是无法亲自体会的。而通过情景代入的确是个好方法。具体做法如下：

创建场景列表，在与需求方沟通的时候，随手记录场景需求

将场景需求拆解成场景步骤，列出每个步骤对应的角色

对每个场景步骤继续拆解成功能，得到功能列表

然而大家的知识背景、技术水平、思维结构差别很大，他们关心侧重点也不同。所以非常有效的一个方式便是讲故事，对于每一个小功能模块，都可以概括成，谁（用户角色）在什么情况下为了达到什么目的，需要做什么（功能），成功了会怎么样，失败了又会怎么样...这样的沟通至少让大家先理解了产品目标，保证大家在同一个频道上对话。

用故事进行事件描述

沟通事件是由粗到细的活儿，都是在“讲故事”。以下是信息传递模型，这个模型其实与上面说的沟通模型大同小异，重点是加入了逻辑思维、故事思维和受众思维，如果能将这三种思维在信息传递中利用起来，将会大大提高传递的效率。

比如写作，就是为了传递作者的信息。利用这个模型，写作的一般步骤可以归纳为：

1）先用受众思维，选用合适的表达方式和写作素材；

2）再借助逻辑思维和故事思维，组织信息，写作成文。

同理，我们的产品设计也是传递信息的一种，故而可概括为：

1）先用故事思维理解用户需求；

2）然后运用受众思维和逻辑思维，设计合理框架结构和事件的交互。

总结

大家都爱听故事，就像一篇学术论文和一篇小说，想必大家都更喜欢看小说。所以现在才有越来越多的作者将专业文章写得通俗易懂，各种举例讲故事。以上只是说了两大方面，其实在项目验收，场景测试时，都可以“讲故事”，如果连我的故事线都走不通，还有必要进行功能测试吗？还有给客户演示，别以为做几张很炫酷的PPT，然后截几张产品图片就很OK了，其实这样客户往往不会买单的。还是要说故事，模拟场景，使用不同角色账号登录系统，说一个完美而顺畅的故事，继而打动受众群体。