作为一名体验设计师,和产品对接的工程中,经常会出现一些分歧,那么应该用什么方法去解决分歧呢?我总结了“场景还原”和“独立思考”以下两个方法,通过这两种方法的运用,我不但和产品经理的分歧变少了,也对需求和业务的理解更加深刻了。🤔

方法一:场景还原

作为一名体验设计师,在日常产品需求对接中,我们的正常流程是:由产品经理发起需求,撰写 Prd 文档,然后输出给交互设计师,交互设计师补充原型设计等,原型设计完成后输出给 UI 设计师,UI 设计师输出视觉 UI 图,剩下的步骤就是交给程序开发同事,最后 PM、设计师验收上线,运营同事开始做用户运营等。这是一个正常的产品需求对接流程,简单来说就是产品经理提出需求,剩下的同事角色配合产品经理完成需求。

现在我们想一下,产品经理的需求怎么来的?谁给产品经理提出需求?产品经理可能回复说是业务方提出的需求,那么谁才是业务方?是老板、直属领导、市场/运营同事、还是产品经理对用户的调研、数据分析后的结果?无论是哪种来源的需求,产品经理都需要输出prd(产品需求文档),最后这个 prd 文档就是产品经理对用户和场景的分析后的产出,也就是说产品经理做每个需求之前,已经有了明确的使用场景后才输出 prd 文档。

当然了,上面这是一种正常的对接状态,既然有正常对接状态也就会有非正常的状态。打比方说:有些产品经理没有做用户和场景的调研,只是从自身角度出发,我认为用户的使用场景是这样的,根据自己所认为的结果直接输出 prd 文档。最后导致与有些不太“谨慎”的产品经理提出的需求没有充分考虑用户场景,出现了一些不正常的需求。典型的例子就是,之前微博上疯传的某位产品经理要求用户 app 主题颜色能随着手机壳颜色自动调整,开发和产品经理打架,上了微博热搜的这条八卦新闻。

所以,为了我们体验设计师能更好的理解这个需求背景和目的,我们拿到需求以后,可以问产品经理一下问题:
这个需求的目的是什么?
这个需求的目标用户是谁?
这个需求需要解决的用户痛点是什么?
这个需求给用户带来的价值是什么? 这个需求给平台带来的价值是什么?
这个需求的使用场景是什么?
这个需求的盈利模式什么?
如果我们和产品经理充分了解沟通以上问题后,相信产品经理也不会提出“要求用户app颜色能随着手机壳颜色自动调整”这种需求吧。

总结一下:我们接到需求以后,首先要了解用户,场景和要解决的问题,然后思考是否能找到应用场景?我们为什么要做这个功能?使用场景是什么?解决的问题是什么?都充分的问清楚了,可以做,那么我们就开始做。假如找不到应用场景,那么就可以判断这是个伪需求,优先级不高的需求,可以考虑不做或者是排期靠后再做。
方法1.png
例如:美团外卖app的产品经理开需求评审会,要加一个“多人拼单”的功能。多人在某家外卖餐厅一起点餐,大家点的餐都加入到同一个购物车里,然后统一一个人支付,最后一起送来。我们接到这个需求后,了解用户,场景,问题后,开始还原用户使用场景。针对这个需求开始思考🤔,既然是拼单,肯定是多个人一起点餐的场景,什么时候才会出现多人一起点餐的场景?
方法2.png
1、工作日午餐。
2、聚会的时候。
3、加班,老板请客。
我们找到了场景,开始思考用户真的会按照我们设想的拼单去点餐么?
1、工作日大家点餐,直接问同事你想吃什么,直接帮他点了付款,然后微信转我饭钱不就可以了?为什么还得那么麻烦,分享个链接,让他自己点?
2、拼单是针对于单独一个餐厅,这家餐厅饭菜种类有点少,聚会的时候由于人比较多,大家口味都不太一样,你想吃烤鸭,我想吃红烧肉,他想吃烤串,这种场景下怎么拼单?
3、晚上加班,老板请客?试想一下,老板真的会问我们想吃什么?然后把链接甩给我们,一起拼单么?一般不都是老板直接买好了,群里通知一声加班餐来了,大家快来吃吧。就算老板把拼单链接给我们,也会让某个人统计你吃什么,我吃什么,让这个人统计好以后直接点餐。

回到最初的场景还原,我们找到了用户使用场景,但是用户不会按照我们的想法来使用这个功能,那么这就是伪需求,可以不做或者排期靠后做。

最后当我们判定这是伪需求的时候,直接说这需求场景不明确、不成立,我们设计不做,这么说我们可能又要和产品经理“撕逼”了,那么我们该怎么说出这个需求不成立呢?

首先寻找使用场景的时候,把场景一一列出来。然后根据列出来的每个场景讲故事,以讲故事的方式反馈给产品经理。
例如:中午吃饭点外卖,我们一般都是直接问同事,你吃什么?我帮你点了吧,或者是把点外卖的手机给他,让他自己选,最后我付款一起送来,同事微信转我饭钱。

方法3.png
再举个例子:你和女朋友在不同的公司上班,白天你俩正在各自公司上着班呢,你正在开心的摸着鱼中,突然你女朋友给你发微信说:我肚子疼,很难受。这时候你会用拼单的功能么?
我们场景还原一下。这时候你会怎么做?
1、首先安慰一下对方,表示一下关心。然后问她想吃点啥?打开美团外卖帮她点杯奶茶。
2、直接发个大红包。
3、直接帮她点她喜欢吃的。

通过上面这两个场景的分析,我们可以分析出在这两种场景下,我们不需要拼单这个功能。
那么为什么外卖 app 上还存在拼单功能呢?拼单功能有什么价值呢?既然上线了,那么就有其使用的场景,我们刚才的分析只是没有找到对的拼单功能使用场景,那么拼单功能的正确使用场景是什么呢?思考一下。
公司周边就这么几家餐厅或者就这么几家比较好吃的餐厅,大家都经常点这几家餐厅的外卖,为了省配送费,和同事可能会点同一家餐厅。最后定义需求的场景是:“为了省配送费,才会用拼单功能”。

再举个例子:语雀协同功能。
通过语雀员工写的文章分析可以看到,语雀现在已经有上千万用户,50万+的协同组织用户,然而使用文档协同的人数不足5%,刚开始的时候语雀没有做文档协同,但是后来还是做了这个功能,为什么做这个功能呢?我们试着场景还原分析一下。
首先我们要了解到有50万+组织用户,现在要解决这些组织成员协同办公写文档的场景。解决的方法就是文档协同,那么什么时候才用协同功能呢?
1、每周开周会之前,大家需要把自己的进度及时同步到进度文档中。
2、大家需要在同一个文档中写出这周所工作的内容和个人思考。
3、需求较多,设计部同事需要知道每个人工作排期。

有了场景我们开始分析
1、同步进度,假如我们都把自己的进度情况单独发给领导或者群里,领导整理起来是不是很麻烦?效率很低?
2、如果我们把自己的工作内容都发给同一个人,那么整理起来是不是很费时间?很容易乱?内容沉淀下来很麻烦?
3、需求太多,排期很重要,大家都在一个文档填写自己的排期这样更高效便捷。

通过上面的场景还原分析,用户会用协同的功能么?对比传统的Office 工具,协同功能确实很实用、也很方便,用户会按照语雀所设定的功能去使用。所以呢,就算只满足了 5% 用户的协同需求,那么这个需求就是有价值的,所以最后语雀还是做了这个功能。

总价一下。我们拿到需求后,也找到了用户的使用场景,怎么判定这个场景合理不合理呢?我们可以从用户,目标,行为,媒介,环境来做对比,把场景一一列出来,用讲故事的方式把场景一一讲出来,还原正确的用户使用场景,最后对需求做出正确的判断。

方法二:独立思考

先分析一下什么是独立思考?独立百度百科的解释:单独的站立或者指关系上不依附、不隶属,依靠自己的力量去做某事。那么怎么理解独立思考呢?独立思考就是依靠自己的思考去分析某件事,对你接受到的每个信息都保持质疑,对每件事都有自己的判断和思考,只相信自己判断甄别后的结果。

独立思考是一种思维模式,有了独立思考就像打通任督二脉,进步飞快。
方法3备份.png
例如:我说大海都是蓝色的。有独立思考的人当听到我这句话的时候首先要质疑我,大海都是蓝色的么?他会去调查,搜集资料甄别大海是蓝色这个信息,通过分析发现有些地方的大海海滩是粉色的?他先质疑了我想法,然后搜集信息全局思考,最后发现真相,大家不仅仅只有蓝色,也有其他的颜色。
这个过程就是独立思考的过程,可以总结一下:1、先质疑。2、搜索信息,思考。3、得出真确的答案。

体验设计师工作中的独立思考是什么呢?
日常的产品需求对接中,产品经理发现了问题,最后也给出了的 prd 解决方案,没有独立思考的人会直接按照prd方案开始陷入细节,直接开始设计。有独立思考的人会怎么做呢?我会先质疑这个方案,然后收集资料思考,最后给出解决方案。当你开始质疑的时候,也就意味着你进入了独立思考的状态。

这里说一下“抬杠”和“独立思考”的差异。
工作中可能对某位同事之前有过一些误会,他说的任何需求你都认为是错的没有价值的,这是抬杠。
工作中无论对方是谁,针对他的话进行质疑,思考一下对不对,最后给出结论,这是独立思考。
方法4.png
例如:拼多多早期假货泛滥,大家都在调侃拼多多是拼夕夕,但是过去两三年,拼多多通过百亿补贴、签约品牌形象店等操作,改变了人们最初对拼多多的认知。这时候你准备在拼多多买一部手机,身边有人建议你别在拼多多买,去京东买,拼多多都是假货。这时候首先我要质疑,拼多多都是假货吗?然后打开拼多多看到百亿补贴,翻了翻评论,大家都在说真香,最后得出结论,发现拼多多不止只有假货啊,也有很多正式的店铺嘛。这就是典型的独立思考过程。
方法5.png
再举个例子:滴滴当刚对外推出的时候,大家都没有搭乘陌生人汽车的习惯,对于这种新的交通出行方式有些不适应,滴滴为了保证用户的出行安全,降低用户对安全的担心,做了一个乘车之前需要打开 app 扫描一下司机师傅的脸,看看是不是车主本人。滴滴花了大量的人力物力去解决人脸识别的问题,也花了大量的财力去做宣传,最后发现大家并不买账,哪里出现了问题呢?

产品提出需求后,开发同事开始思考技术的实现难度,运营同事开始思考运营策略,那么我们设计师就要承担还原用户场景的责任,用独立思考的方式去思考按照产品的方案,到底能不能解决用户对安全性担心的问题?很显然,上车后扫描司机师傅的脸是个伪命题,晚上加班后打车回家,上车后先扫描师傅的脸?车里光线那么暗,你还着急回家,这时候不扫师傅的脸不匹配,这种场景合适么?就算是白天乘车,用户拿着手机去扫一个陌生人的脸,用户和死机师傅尴尬么?后来滴滴就取消了这个扫师傅脸的功能,反而直接是看实际乘坐车辆的车牌号是否和打车车牌号一致,司机师傅校对乘客手机号,匹配上后就可以直接上车了。基于这个案例,我们接到需求后,先质疑,扫脸真的能解决用户对安全性的顾虑问题么?然后我们去做场景还原,发现扫脸这个解决方案并合适,最后给出判断。这就是我们独立思考的过程。

再举个例子,最近我想买一个 iPad 二手键盘,在闲鱼上搜索后和一位小伙伴交流很愉快,于是开始见面交易,见面后,我在闲鱼付款,他点击发货,不到一分钟我点击确认收货,这时候出现了风控的问题。正常来讲,我已经确认收货,资金应该直接到卖家支付宝,但是由于发货和确认收货时间间隔过短,闲鱼判定买家受骗,资金冻结,卖家拿不到钱。过了几分钟,有个杭州电话打来询问我是否收到货?直到我回复确认收到货物以后,资金才到卖家账号。通过这个小案例,我们分析一下产品需求的场景。
首先要确认场景:卖家发货时间和买家收货时间间隔过短,闲鱼平台判定为风控交易,冻结资金。什么时候才会出现这种情况?
1、买家被骗,根据以往被骗的案例判断,卖家忽悠买家必须先确认收货才可以进行交易。
2、买家被卖家恐吓,早年闲鱼中关村见面交易几乎都是骗子,卖家强迫买家确认收货,最后买家钱花了,货没拿到。
基于以往买家被骗的案例,为了减少买家被骗事件的发生,产品经理就把这种场景判定为风控交易,打电话给买家二次确认后才把资金给卖家。我们思考一下,首先质疑这种场景存在么?确实存在,新闻上确实也看到过这样被骗的案例,这个需求是成立的,有价值的,这个需求值得做。

总结一下独立思考的过程就是:先质疑,质疑对方说的话对不对,成立不成立?然后整合线索,全局思考,定义问题,最后得出正确的答案。

最后我们思考一下:在一辆 7 座 中大型 SUV 车中,智能车舱(HMI)副驾驶位置添加一块大屏幕,作为副驾驶的娱乐屏,这个需求是否成立?方法6.png

总结

虽然本文写的对接场景有些理想化,在日常的工作需求对接中,根本没有时间让设计师们去思考,一般情况下需求来了,设计师作为执行把 UI 画好看就行了,通过我以往的工作经验认知,没有思考的执行,就是停滞不前。我记得之前周陟老师说过:同样一张 UI 页面,新手只是看到了图标的好看与否,高级设计师看到了背后的交互逻辑,而专家设计师看到了背后的运营策略以及对平台产生的价值。为了能更好的提高我们对需求和业务的理解,我们应认真对待每次需求,再小的需求也有它可研究的价值。
本文介绍的两种方法:场景还原、独立思考,不仅仅运营在工作中,在生活中也特别实用,对待每件事情都要有自己的观点和看法,有自己的理解,就算当时理解是错的,随时思考的深入,慢慢也会发现真相。

最后,加入您看完本文认为对自己有一些帮助,请把本文分享给自己的好友,谢谢。