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

我有酒,你有故事吗?

我们常聊的用户故事

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

用故事进行沟通

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

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

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


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

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

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

用故事进行产品设计

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

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

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

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

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

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

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

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

总结

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

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

版权声明

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

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部