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

方法一 ：场景还原

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

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

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

所以，为了我们体验设计师能更好的理解这个需求背景和目的，我们拿到需求以后 ，可以问产品经理一下问题：

这个需求的目的是什么 ？

这个需求的目标用户是谁 ？

这个需求需要解决的用户痛点是什么？

这个需求给用户带来的价值是什么？ 这个需求给平台带来的价值是什么
？

这个需求的使用场景是什么？

这个需求的盈利模式什么？

如果我们和产品经理充分了解沟通以上问题后 ，相信产品经理也不会提出“要求用户 app 颜色能随着手机壳颜色自动调整”这种需求吧 。

总结一下
：我们接到需求以后，首先要了解用户 ，场景和要解决的问题，然后思考是否能找到应用场景 ？我们为什么要做这个功能 ？使用场景是什么？解决的问题是什么？都充分的问清楚了，可以做，那么我们就开始做。假如找不到应用场景 ，那么就可以判断这是个伪需求，优先级不高的需求，可以考虑不做或者是排期靠后再做。

例如 ：美团外卖 app 的产品经理开需求评审会 ，要加一个“多人拼单”的功能。多人在某家外卖餐厅一起点餐，大家点的餐都加入到同一个购物车里 ，然后统一一个人支付，最后一起送来。我们接到这个需求后，了解用户
，场景 ，问题后 ，开始还原用户使用场景
。针对这个需求开始思考，既然是拼单，肯定是多个人一起点餐的场景，什么时候才会出现多人一起点餐的场景  ？

1. 工作日午餐。
2. 聚会的时候 。
3. 加班 ，老板请客 。

我们找到了场景，开始思考用户真的会按照我们设想的拼单去点餐么？

1. 工作日大家点餐，直接问同事你想吃什么  ，直接帮他点了付款 ，然后微信转我饭钱不就可以了 ？为什么还得那么麻烦 ，分享个链接，让他自己点 ？
2. 拼单是针对于单独一个餐厅，这家餐厅饭菜种类有点少，聚会的时候由于人比较多，大家口味都不太一样
   ，你想吃烤鸭 ，我想吃红烧肉，他想吃烤串 ，这种场景下怎么拼单？
3. 晚上加班，老板请客？试想一下，老板真的会问我们想吃什么？然后把链接甩给我们，一起拼单么？一般不都是老板直接买好了，群里通知一声加班餐来了，大家快来吃吧
   。就算老板把拼单链接给我们，也会让某个人统计你吃什么 ，我吃什么，让这个人统计好以后直接点餐。

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

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

首先寻找使用场景的时候，把场景一一列出来。然后根据列出来的每个场景讲故事
，以讲故事的方式反馈给产品经理 。

例如：中午吃饭点外卖，我们一般都是直接问同事 
，你吃什么？我帮你点了吧  ，或者是把点外卖的手机给他，让他自己选，最后我付款一起送来，同事微信转我饭钱。

再举个例子：你和女朋友在不同的公司上班
，白天你俩正在各自公司上着班呢 ，你正在开心的摸着鱼中 ，突然你女朋友给你发微信说 ：我肚子疼
，很难受。这时候你会用拼单的功能么 ？

我们场景还原一下。这时候你会怎么做？

1. 首先安慰一下对方，表示一下关心。然后问她想吃点啥？打开美团外卖帮她点杯奶茶 。
2. 直接发个大红包
   。
3. 直接帮她点她喜欢吃的。

通过上面这两个场景的分析，我们可以分析出在这两种场景下 ，我们不需要拼单这个功能 。
那么为什么外卖 app 上还存在拼单功能呢？拼单功能有什么价值呢 ？既然上线了，那么就有其使用的场景，我们刚才的分析只是没有找到对的拼单功能使用场景，那么拼单功能的正确使用场景是什么呢
？思考一下 。

公司周边就这么几家餐厅或者就这么几家比较好吃的餐厅，大家都经常点这几家餐厅的外卖，为了省配送费 ，和同事可能会点同一家餐厅。最后定义需求的场景是
：“为了省配送费，才会用拼单功能”。

再举个例子
 ：语雀协同功能。

通过语雀员工写的文章分析可以看到 
，语雀现在已经有上千万用户，50 万+的协同组织用户，然而使用文档协同的人数不足 5%，刚开始的时候语雀没有做文档协同
，但是后来还是做了这个功能，为什么做这个功能呢 ？我们试着场景还原分析一下 。

首先我们要了解到有 50 万+组织用户，现在要解决这些组织成员协同办公写文档的场景
。解决的方法就是文档协同
，那么什么时候才用协同功能呢？

1. 每周开周会之前，大家需要把自己的进度及时同步到进度文档中。
2. 大家需要在同一个文档中写出这周所工作的内容和个人思考。
3. 需求较多，设计部同事需要知道每个人工作排期 。

有了场景我们开始分析

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

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

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

方法二 ：独立思考

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

独立思考是一种思维模式，有了独立思考就像打通任督二脉 ，进步飞快 。

例如 ：我说大海都是蓝色的。有独立思考的人当听到我这句话的时候首先要质疑我 ，大海都是蓝色的么？他会去调查 ，搜集资料甄别大海是蓝色这个信息 ，通过分析发现有些地方的大海海滩是粉色的？他先质疑了我想法，然后搜集信息全局思考，最后发现真相 ，大家不仅仅只有蓝色，也有其他的颜色。

这个过程就是独立思考的过程 ，可以总结一下 ：1、先质疑 。2、搜索信息，思考 。3、得出真确的答案 。

体验设计师工作中的独立思考是什么呢
？

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

这里说一下“抬杠”和“独立思考”的差异 。

工作中可能对某位同事之前有过一些误会 ，他说的任何需求你都认为是错的没有价值的，这是抬杠。

工作中无论对方是谁 ，针对他的话进行质疑，思考一下对不对 ，最后给出结论 ，这是独立思考。

例如 ：拼多多早期假货泛滥  ，大家都在调侃拼多多是拼夕夕，但是过去两三年，拼多多通过百亿补贴 、签约品牌形象店等操作，改变了人们最初对拼多多的认知。这时候你准备在拼多多买一部手机 ，身边有人建议你别在拼多多买，去京东买 ，拼多多都是假货。这时候首先我要质疑 ，拼多多都是假货吗？然后打开拼多多看到百亿补贴，翻了翻评论 ，大家都在说真香，最后得出结论 ，发现拼多多不止只有假货啊 ，也有很多正式的店铺嘛。这就是典型的独立思考过程 。

再举个例子
：滴滴当刚对外推出的时候，大家都没有搭乘陌生人汽车的习惯
，对于这种新的交通出行方式有些不适应 ，滴滴为了保证用户的出行安全，降低用户对安全的担心 ，做了一个乘车之前需要打开 app 扫描一下司机师傅的脸
，看看是不是车主本人。滴滴花了大量的人力物力去解决人脸识别的问题，也花了大量的财力去做宣传，最后发现大家并不买账
，哪里出现了问题呢？

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

再举个例子，最近我想买一个 iPad 二手键盘 ，在闲鱼上搜索后和一位小伙伴交流很愉快
，于是开始见面交易，见面后 ，我在闲鱼付款 ，他点击发货，不到一分钟我点击确认收货 ，这时候出现了风控的问题 。正常来讲 ，我已经确认收货，资金应该直接到卖家支付宝
，但是由于发货和确认收货时间间隔过短，闲鱼判定买家受骗，资金冻结，卖家拿不到钱 。过了几分钟 ，有个杭州电话打来询问我是否收到货 ？直到我回复确认收到货物以后，资金才到卖家账号
。通过这个小案例 ，我们分析一下产品需求的场景。

首先要确认场景：卖家发货时间和买家收货时间间隔过短，闲鱼平台判定为风控交易，冻结资金。什么时候才会出现这种情况？

1. 买家被骗，根据以往被骗的案例判断，卖家忽悠买家必须先确认收货才可以进行交易。
2. 买家被卖家恐吓，早年闲鱼中关村见面交易几乎都是骗子，卖家强迫买家确认收货，最后买家钱花了，货没拿到。

基于以往买家被骗的案例 ，为了减少买家被骗事件的发生 ，产品经理就把这种场景判定为风控交易，打电话给买家二次确认后才把资金给卖家 。我们思考一下，首先质疑这种场景存在么？确实存在，新闻上确实也看到过这样被骗的案例 ，这个需求是成立的
，有价值的 ，这个需求值得做。

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

最后我们思考一下 ：在一辆 7 座 中大型 SUV 车中，智能车舱（HMI）副驾驶位置添加一块大屏幕 ，作为副驾驶的娱乐屏 ，这个需求是否成立
 ？

总结

虽然本文写的对接场景有些理想化，在日常的工作需求对接中，根本没有时间让设计师们去思考，一般情况下需求来了，设计师作为执行把 UI 画好看就行了，通过我以往的工作经验认知，没有思考的执行，就是停滞不前。我记得之前周陟老师说过：同样一张 UI 页面，新手只是看到了图标的好看与否 ，高级设计师看到了背后的交互逻辑
，而专家设计师看到了背后的运营策略以及对平台产生的价值。为了能更好的提高我们对需求和业务的理解，我们应认真对待每次需求，再小的需求也有它可研究的价值。

本文介绍的两种方法：场景还原、独立思考，不仅仅运营在工作中，在生活中也特别实用 ，对待每件事情都要有自己的观点和看法，有自己的理解，就算当时理解是错的 ，随时思考的深入 ，慢慢也会发现真相。

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

作者：七帅