用户故事：别小看“讲故事”的力量

2017-12-19 11:40:00

我有酒，你有故事吗？

我们常聊的用户故事

我有酒，你有故事吗？我们可以彼此说说故事，但这故事不是你的也不是我的，而是用户的。在一家业务复杂的2B企业做产品设计，跟一群大脑强悍程序员沟通，难免磕磕绊绊。但自从学会了用故事来沟通和交流，省了不少事，也少惹了很多麻烦。
大家都在说，产品经理要有场景思维，要有同理心，要有“零秒变小白”的能力。当然这些都是很好的思维习惯，但说多了容易形成某种幻觉，以为自己就是这么干的，最后麻木了不以为意。
所以要时常问自己，是不是真的站在了用户的角度，是否真正理解了最真实的用户场景。其实这种场景思维不只局限于产品设计上，从产品初期到最后上线，都可以用到，同时也不仅仅是设计人员的专利，将这种方式应用在每个环节的角色上，会大大降低沟通成本。可使每个角色都更加了解自己参与的产品，更有成就感和责任感。

用故事进行沟通

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

拿个实际工作例子来说，老板或运营部的人，准备将客户的需求传达给产品人员，假设他们都真正理解了客户的诉求（信息度100%），经过自己整理编码，信息完整度可能降到90%，然后经过一部分的噪音干扰，产品人员得到的信息可能降到80%，最后被自己的思维处理过滤，估计只剩不到一半的准确信息了。
这个模型中的噪音指的是很多客观环境，我们暂忽略不计。信息衰减最严重的地方一般是发送者对信息的编码和表述过程，比如刚说的需求传递者经常这么干，要么用简单的几句话概括，要么直接给你一个自认为合理的设计方案。要是碰到提需求的人恰好是程序员出身，就更惨不忍赌，提需求过程中掺杂着实现方法。他以为自己传递得很完美了，其实产品人员在心中痛苦地撕喊，我根本没有真正理解嘛，心里一堆疑问：

谁要用这个功能？
使用这个功能的目的是什么？
什么时候会用？

…
负责任的产品人员会刨根问底，去挖掘用户真正的需求。否则只根据不到一半的信息度进行设计，浪费设计人员时间不说，还打击人家信心，同时影响整个产品进度。
经过几次这种低效沟通后，寻找发现问题的所在。然后我们开始用说故事的方式进行传达，因为不是C端产品，很多场景实际上是无法亲自体会的。而通过情景代入的确是个好方法。具体做法如下：

创建场景列表，在与需求方沟通的时候，随手记录场景需求
将场景需求拆解成场景步骤，列出每个步骤对应的角色
对每个场景步骤继续拆解成功能，得到功能列表
将功能列表进行优先级排序

同时有了这么一份文档，每次需求会议或简单传达时，会及时提醒自己先从理解场景入手，提需求人员也只好乖乖给你讲个完整的故事。这样一份文档既结合了场景建模和用户建模又可以进行需求管理。
除了需求来源沟通外，在与开发人员进行讨论时，也经常出现沟通障碍。作为产品设计者，当遇到某个“疑难杂症”需要与开发大哥进行探讨时，往往大哥的程序思维会爆棚，把后台表结构拿来一一讲解。
他讲得精疲力尽，你听得昏天黑地，但效果甚微，根本没有解决问题嘛。换种思路，你讲个小故事，有人物有背景，然后最后抛出问题，让他按照你的思维结构给出答案，这比你去理解程序要快得多。
再说说会议沟通，一般立项时，与会者往往包括产品线几乎所有环节的人员。会议最重要的目的是将你的信息以最快速度传播出去，然而大家的知识背景、技术水平、思维结构差别很大，他们关心侧重点也不同。
所以非常有效的一个方式便是讲故事，对于每一个小功能模块，都可以概括成，谁（用户角色）在什么情况下为了达到什么目的，需要做什么（功能），成功了会怎么样，失败了又会怎么样…这样的沟通至少让大家先理解了产品目标，保证大家在同一个频道上对话。

用故事进行产品设计

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

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

先用受众思维，选用合适的表达方式和写作素材；
再借助逻辑思维和故事思维，组织信息，写作成文。

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

先用故事思维理解用户需求；
然后运用受众思维和逻辑思维，设计合理框架结构和页面交互。

上一篇文章提到过框架设计的注意点，而说故事的方式在框架设计上也很有用武之地。一般我们常用的方法是将某个角色的操作进行汇总归类，然后进行模块划分。然而对于角色众多，场景复杂的B端产品，这种方法设计出来的框架可能会过于“软件”化，用户体验未必会很好。
如果能考虑加入场景故事线的维度，会使产品更加灵活和有人味儿。比如某个后台设置功能只是为了一个特定场景使用，我就未必非要放在全局设置中，而是可以考虑做入这个故事中的某个环节。
至于页面设计，在设计时，我们至少需要考虑以下几点：

这个页面要展示什么内容？
用户进入这个页面的场景有哪些？
每个场景的目的是什么？
针对不同的场景页面需要有哪些变化？

举个例子，这是某个理财APP的页面，故事是这样的，我在这个APP里投入了部分资金进行理财，恰好前两天需要用钱，所以打算赎回大部分资金。对于我这种对网上理财还是有点不放心且理财金是我大部分家当，那赎回的过程中我是不是特别关注赎回进度。
可是这个APP在经过赎回确认后（资金还未到账），就显示为下面第的一个页面（跟赎回前无异，只是总金额少了），此时我的第一本能反应有点惊慌了：金额怎么这么少了？赎回的钱呢？我明明没有收到钱啊？赎回失败？… 它的做法是需要通过点击“交易记录”到“赎回”列表中去查看明细。
这就是带着故事做设计，这APP的设计是满足了用户基本需求，却没有把握住故事中主人公的真正心理状态，如果在这个页面有个赎回提示，是不是更好。而且它又不是家喻户晓的产品，主要还是新用户占绝大多数。

总结

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

作者 @ 一念。

关键字：产品经理, 用户故事, 故事, 场景

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击举报进行投诉反馈！