标王 热搜: fobtx.com    公司  手机  www.fobtx.com  低收入者  B2B电子商务平台  贷款攻略  广东  b2b,fobtx.com 
 
• 回收Keysight34420A纳伏表 • 求购Keysight34401A • 求购Keysight34970A • AFG3102/C函数信号发生器/ • MSO-X3102A、Keysight 大
• MSO3052/MSO3052 • 找货MDO3052、MDO3054、徐 • TDS3012C,收TDS3012C,仪 • TCP0030A /TCP0030A泰克/ • 求购、AQ6319、AQ6319、徐
• 求购 E4445A/Agilent频谱 • TPS2024B隔离示波器/Tektr • MSO3012/Tektronix 二手找 • MSO3034二手找、示波器 • 二手大回收 MDO4034B-3 /
• 求购 MSO-X3024A MSO-X302 • 回收 DPO5104/B /数字示波 • 工厂仪器收购 BM-7A,BM-7 • 二手购 /MS9740A 光谱分析 • 回收 二手闲置 TCP0030A /
• 收购E5071B”大量回收E507 • 泰克、回收TDS3012C回收 • 罗德与施瓦茨、回收R&S FS • 吉时利、回收Keithley2400 • 全新、二手TDS7254回收
• 全新、二手N9912A回收 • 租售、二手E5062A回收 • 二手、全新chroma 63803回 • 二手、全新Agilent 85033E • Agilent 34970A回收、报价
• 求购-,长期回收MT8860C • 求购-,长期回收IQXEL80 • 求购-,长期回收E4438C • 求购-,长期回收E4402B • 求购-,长期回收CA-310
• 求购-,长期回收Agilent 3 • 求购-长期回收Agilent 345 • 销售、回收GPS101 • 二手、回收Agilent 34970A • 回收、回收Agilent 34908A
• 回收Agilent 34901A、价格 • 福禄克、回收FLUKE 726回 • 安捷伦、回收E3633A回收 • 回收.DSO6014A-DSO6014A • 电源求购chroma 6215H-600
• 求购二手R3131A|爱德万回 • 二手回收MT8860C|安立MT88 • 二手IFR GPS-101回收|艾法 • 闲置DPO4034泰克DPO4034回 • 二手DPO3014回收|泰克DPO3
 
 |   |  文字广告 广告推广中心
 |   |  文字广告 广告推广中心
 
当前位置: 首页 » 资讯 » 商务技巧 » 正文

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

放大字体  缩小字体 发布日期:2017-12-20  来源:fobtx.com  作者:fobtx.com  
核心提示:我有酒,你有故事吗?我们常聊的用户故事我有酒,你有故事吗?我们可以彼此说说故事,但这故事不是你的也不是我的,而是用户的。
我有酒,你有故事吗?

我们常聊的用户故事

我有酒,你有故事吗?我们可以彼此说说故事,但这故事不是你的也不是我的,而是用户的。在一家业务复杂的2B企业做产品设计,跟一群大脑强悍程序员沟通,难免磕磕绊绊。但自从学会了用故事来沟通和交流,省了不少事,也少惹了很多麻烦。

大家都在说,产品经理要有场景思维,要有同理心,要有“零秒变小白”的能力。当然这些都是很好的思维习惯,但说多了容易形成某种幻觉,以为自己就是这么干的,最后麻木了不以为意。

所以要时常问自己,是不是真的站在了用户的角度,是否真正理解了最真实的用户场景。其实这种场景思维不只局限于产品设计上,从产品初期到最后上线,都可以用到,同时也不仅仅是设计人员的专利,将这种方式应用在每个环节的角色上,会大大降低沟通成本。可使每个角色都更加了解自己参与的产品,更有成就感和责任感。

用故事进行沟通

同理心说得容易,其实做起来相当困难,大家不自觉地就会从自我出发,以为其他人都跟自己一样,你认为的就是别人认为的。以下是沟通过程模型图,先简单介绍下,发送方在沟通过程中处于信息传递的主动地位,是沟通的起点。

发送方将需要传达的信息进行编码,编码后的表现形式可以多种多样,比如语言、文字、图形、动作或表情等等。通过不同的媒介(面对面、电话、电邮、互联网聊天等)与接受者进行交流。

在传递过程中会对信息产生干扰的一切因素都可称作噪音,噪音越大,信息传递障碍越大,效率也越低。

接受者处于沟通过程中的被动地位,对接受到信息需要进行解码,转化成需要的信息。

最后一个环节是接受者对发送者进行信息反馈,反馈使沟通过程变成一个闭合循环的过程。而实际沟通过程中,每一个环节的信息量都在递减。

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

这个模型中的噪音指的是很多客观环境,我们暂忽略不计。信息衰减最严重的地方一般是发送者对信息的编码和表述过程,比如刚说的需求传递者经常这么干,要么用简单的几句话概括,要么直接给你一个自认为合理的设计方案。要是碰到提需求的人恰好是程序员出身,就更惨不忍赌,提需求过程中掺杂着实现方法。他以为自己传递得很完美了,其实产品人员在心中痛苦地撕喊,我根本没有真正理解嘛,心里一堆疑问:

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

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

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

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

同时有了这么一份文档,每次需求会议或简单传达时,会及时提醒自己先从理解场景入手,提需求人员也只好乖乖给你讲个完整的故事。这样一份文档既结合了场景建模和用户建模又可以进行需求管理。

除了需求来源沟通外,在与开发人员进行讨论时,也经常出现沟通障碍。作为产品设计者,当遇到某个“疑难杂症”需要与开发大哥进行探讨时,往往大哥的程序思维会爆棚,把后台表结构拿来一一讲解。

他讲得精疲力尽,你听得昏天黑地,但效果甚微,根本没有解决问题嘛。换种思路,你讲个小故事,有人物有背景,然后最后抛出问题,让他按照你的思维结构给出答案,这比你去理解程序要快得多。

再说说会议沟通,一般立项时,与会者往往包括产品线几乎所有环节的人员。会议最重要的目的是将你的信息以最快速度传播出去,然而大家的知识背景、技术水平、思维结构差别很大,他们关心侧重点也不同。

所以非常有效的一个方式便是讲故事,对于每一个小功能模块,都可以概括成,谁(用户角色)在什么情况下为了达到什么目的,需要做什么(功能),成功了会怎么样,失败了又会怎么样…这样的沟通至少让大家先理解了产品目标,保证大家在同一个频道上对话。

用故事进行产品设计

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

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

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

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

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

上一篇文章提到过框架设计的注意点,而说故事的方式在框架设计上也很有用武之地。一般我们常用的方法是将某个角色的操作进行汇总归类,然后进行模块划分。然而对于角色众多,场景复杂的B端产品,这种方法设计出来的框架可能会过于“软件”化,用户体验未必会很好。

如果能考虑加入场景故事线的维度,会使产品更加灵活和有人味儿。比如某个后台设置功能只是为了一个特定场景使用,我就未必非要放在全局设置中,而是可以考虑做入这个故事中的某个环节。

至于页面设计,在设计时,我们至少需要考虑以下几点:

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

举个例子,这是某个理财APP的页面,故事是这样的,我在这个APP里投入了部分资金进行理财,恰好前两天需要用钱,所以打算赎回大部分资金。对于我这种对网上理财还是有点不放心且理财金是我大部分家当,那赎回的过程中我是不是特别关注赎回进度。

可是这个APP在经过赎回确认后(资金还未到账),就显示为下面第的一个页面(跟赎回前无异,只是总金额少了),此时我的第一本能反应有点惊慌了:金额怎么这么少了?赎回的钱呢?我明明没有收到钱啊?赎回失败?… 它的做法是需要通过点击“交易记录”到“赎回”列表中去查看明细。

这就是带着故事做设计,这APP的设计是满足了用户基本需求,却没有把握住故事中主人公的真正心理状态,如果在这个页面有个赎回提示,是不是更好。而且它又不是家喻户晓的产品,主要还是新用户占绝大多数。

总结

大家都爱听故事,就像一篇学术论文和一篇小说,想必大家都更喜欢看小说。所以现在才有越来越多的作者将专业文章写得通俗易懂,各种举例讲故事。

以上只是说了两大方面,其实在项目验收,场景测试时,都可以“讲故事”,如果连我的故事线都走不通,还有必要进行功能测试吗?还有给客户演示,别以为做几张很炫酷的PPT,然后截几张产品图片就很OK了,其实这样客户往往不会买单的。还是要说故事,模拟场景,使用不同角色账号登录系统,说一个完美而顺畅的故事,继而打动用户。

 
关键词: 产品
 
[ 资讯搜索 ]  [ 加入收藏 ]  [ 告诉好友 ]  [ 打印本文 ]  [ 关闭窗口 ]

 
0条 [查看全部]  相关评论

 
按热门浏览
推荐图文
推荐资讯
点击排行
 
网站首页 | 隐私保护 | 使用协议 | 联系我们 | 关于我们 | 网站地图 | 排名推广 | 广告服务 | 积分换礼 | 网站留言 | RSS订阅 | 粤ICP备12078281号-3
Powered by DESTOON