作为一名体验设计师，用方和产品对接的法高过程中 ，经常会出现一些分歧 ，效对那么应该用什么方法去解决分歧呢 ？接产我总结了“场景还原”和“独立思考”以下两个方法 ，通过这两种方法的品需运用 ，我不但和产品经理的掌握分歧变少了 ，也对需求和业务的个实理解更加深刻了。
作为一名体验设计师 ，用方在日常产品需求对接中 ，法高我们的效对正常流程是 ：由产品经理发起需求 ，撰写 Prd 文档 ，接产然后输出给交互设计师 ，品需交互设计师补充原型设计等 ，掌握原型设计完成后输出给 UI 设计师 ，UI 设计师输出视觉 UI 图 ，剩下的步骤就是交给程序开发同事，最后 PM、设计师验收上线 ，运营同事开始做用户运营等。这是一个正常的产品需求对接流程 ，简单来说就是产品经理提出需求 ，剩下的同事角色配合产品经理完成需求 。
现在我们想一下，产品经理的需求怎么来的 ？谁给产品经理提出需求 ？产品经理可能回复说是业务方提出的需求 ，那么谁才是业务方 ？是老板 、直属领导 、市场/运营同事 、还是产品经理对用户的调研 、数据分析后的结果 ？无论是哪种来源的需求 ，产品经理都需要输出 prd（产品需求文档），最后这个 prd 文档就是产品经理对用户和场景的分析后的产出 ，也就是说产品经理做每个需求之前 ，已经有了明确的使用场景后才输出 prd 文档 。
当然了 ，上面这是一种正常的对接状态，既然有正常对接状态也就会有非正常的状态。打比方说 ：有些产品经理没有做用户和场景的调研 ，只是从自身角度出发 ，我认为用户的使用场景是这样的 ，根据自己所认为的结果直接输出 prd 文档 。最后导致与有些不太“谨慎”的产品经理提出的需求没有充分考虑用户场景 ，出现了一些不正常的需求 。典型的例子就是 ，之前微博上疯传的某位产品经理要求用户 app 主题颜色能随着手机壳颜色自动调整 ，开发和产品经理打架 ，上了微博热搜的这条八卦新闻。
所以 ，为了我们体验设计师能更好的理解这个需求背景和目的 ，我们拿到需求以后 ，可以问产品经理一下问题 ：
这个需求的目的是什么 ？
这个需求的目标用户是谁 ？
这个需求需要解决的用户痛点是什么 ？
这个需求给用户带来的价值是什么 ？ 这个需求给平台带来的价值是什么 ？
这个需求的使用场景是什么 ？
这个需求的盈利模式什么 ？
如果我们和产品经理充分了解沟通以上问题后，相信产品经理也不会提出“要求用户 app 颜色能随着手机壳颜色自动调整”这种需求吧。
总结一下 ：我们接到需求以后 ，首先要了解用户 ，场景和要解决的问题 ，然后思考是否能找到应用场景？我们为什么要做这个功能 ？使用场景是什么 ？解决的问题是什么 ？都充分的问清楚了 ，可以做 ，那么我们就开始做 。假如找不到应用场景，那么就可以判断这是个伪需求 ，优先级不高的需求 ，可以考虑不做或者是排期靠后再做 。
例如：美团外卖 app 的产品经理开需求评审会 ，要加一个“多人拼单”的功能 。多人在某家外卖餐厅一起点餐 ，大家点的餐都加入到同一个购物车里，然后统一一个人支付 ，最后一起送来 。我们接到这个需求后 ，了解用户 ，场景 ，问题后，开始还原用户使用场景 。针对这个需求开始思考 ，既然是拼单 ，肯定是多个人一起点餐的场景 ，什么时候才会出现多人一起点餐的场景 ？
我们找到了场景 ，开始思考用户真的会按照我们设想的拼单去点餐么 ？
回到最初的场景还原 ，我们找到了用户使用场景 ，但是用户不会按照我们的想法来使用这个功能 ，那么这就是伪需求 ，可以不做或者排期靠后做。
最后当我们判定这是伪需求的时候 ，直接说这需求场景不明确 、不成立，我们设计不做，这么说我们可能又要和产品经理“撕逼”了，那么我们该怎么说出这个需求不成立呢 ？
首先寻找使用场景的时候，把场景一一列出来 。然后根据列出来的每个场景讲故事 ，以讲故事的方式反馈给产品经理 。
例如 ：中午吃饭点外卖 ，我们一般都是直接问同事，你吃什么？我帮你点了吧 ，或者是把点外卖的手机给他，让他自己选 ，最后我付款一起送来 ，同事微信转我饭钱 。
再举个例子 ：你和女朋友在不同的公司上班 ，白天你俩正在各自公司上着班呢 ，你正在开心的摸着鱼中 ，突然你女朋友给你发微信说：我肚子疼 ，很难受 。这时候你会用拼单的功能么 ？
我们场景还原一下 。这时候你会怎么做 ？
通过上面这两个场景的分析 ，我们可以分析出在这两种场景下
，我们不需要拼单这个功能。
那么为什么外卖 app 上还存在拼单功能呢 ？拼单功能有什么价值呢 ？既然上线了
，那么就有其使用的场景
，我们刚才的分析只是没有找到对的拼单功能使用场景
，那么拼单功能的正确使用场景是什么呢？思考一下。
公司周边就这么几家餐厅或者就这么几家比较好吃的餐厅 ，大家都经常点这几家餐厅的外卖 ，为了省配送费，和同事可能会点同一家餐厅 。最后定义需求的场景是 ：“为了省配送费 ，才会用拼单功能” 。
再举个例子 ：语雀协同功能。
通过语雀员工写的文章分析可以看到，语雀现在已经有上千万用户 ，50 万+的协同组织用户 ，然而使用文档协同的人数不足 5%，刚开始的时候语雀没有做文档协同，但是后来还是做了这个功能 ，为什么做这个功能呢 ？我们试着场景还原分析一下 。
首先我们要了解到有 50 万+组织用户 ，现在要解决这些组织成员协同办公写文档的场景 。解决的方法就是文档协同，那么什么时候才用协同功能呢？
有了场景我们开始分析
通过上面的场景还原分析，用户会用协同的功能么 ？对比传统的 Office 工具 ，协同功能确实很实用、也很方便 ，用户会按照语雀所设定的功能去使用 。所以呢 ，就算只满足了 5% 用户的协同需求 ，那么这个需求就是有价值的 ，所以最后语雀还是做了这个功能 。
总价一下 。我们拿到需求后，也找到了用户的使用场景 ，怎么判定这个场景合理不合理呢 ？我们可以从用户 ，目标 ，行为，媒介 ，环境来做对比 ，把场景一一列出来 ，用讲故事的方式把场景一一讲出来 ，还原正确的用户使用场景 ，最后对需求做出正确的判断 。
先分析一下什么是独立思考 ？独立百度百科的解释 ：单独的站立或者指关系上不依附 、不隶属 ，依靠自己的力量去做某事 。那么怎么理解独立思考呢 ？独立思考就是依靠自己的思考去分析某件事 ，对你接受到的每个信息都保持质疑 ，对每件事都有自己的判断和思考 ，只相信自己判断甄别后的结果 。
独立思考是一种思维模式 ，有了独立思考就像打通任督二脉 ，进步飞快 。
例如 ：我说大海都是蓝色的 。有独立思考的人当听到我这句话的时候首先要质疑我 ，大海都是蓝色的么 ？他会去调查，搜集资料甄别大海是蓝色这个信息 ，通过分析发现有些地方的大海海滩是粉色的 ？他先质疑了我想法 ，然后搜集信息全局思考 ，最后发现真相，大家不仅仅只有蓝色 ，也有其他的颜色 。
这个过程就是独立思考的过程 ，可以总结一下：1 、先质疑 。2 、搜索信息 ，思考。3、得出真确的答案 。
体验设计师工作中的独立思考是什么呢？
日常的产品需求对接中 ，产品经理发现了问题 ，最后也给出了的 prd 解决方案 ，没有独立思考的人会直接按照 prd 方案开始陷入细节 ，直接开始设计。有独立思考的人会怎么做呢 ？我会先质疑这个方案 ，然后收集资料思考 ，最后给出解决方案 。当你开始质疑的时候，也就意味着你进入了独立思考的状态 。
这里说一下“抬杠”和“独立思考”的差异 。
工作中可能对某位同事之前有过一些误会，他说的任何需求你都认为是错的没有价值的 ，这是抬杠 。
工作中无论对方是谁 ，针对他的话进行质疑 ，思考一下对不对 ，最后给出结论 ，这是独立思考 。
例如 ：拼多多早期假货泛滥 ，大家都在调侃拼多多是拼夕夕 ，但是过去两三年 ，拼多多通过百亿补贴 、签约品牌形象店等操作 ，改变了人们最初对拼多多的认知 。这时候你准备在拼多多买一部手机 ，身边有人建议你别在拼多多买，去京东买 ，拼多多都是假货 。这时候首先我要质疑 ，拼多多都是假货吗 ？然后打开拼多多看到百亿补贴 ，翻了翻评论，大家都在说真香 ，最后得出结论 ，发现拼多多不止只有假货啊 ，也有很多正式的店铺嘛 。这就是典型的独立思考过程 。
再举个例子 ：滴滴当刚对外推出的时候 ，大家都没有搭乘陌生人汽车的习惯 ，对于这种新的交通出行方式有些不适应 ，滴滴为了保证用户的出行安全 ，降低用户对安全的担心 ，做了一个乘车之前需要打开 app 扫描一下司机师傅的脸 ，看看是不是车主本人。滴滴花了大量的人力物力去解决人脸识别的问题 ，也花了大量的财力去做宣传 ，最后发现大家并不买账 ，哪里出现了问题呢 ？
产品提出需求后 ，开发同事开始思考技术的实现难度，运营同事开始思考运营策略，那么我们设计师就要承担还原用户场景的责任 ，用独立思考的方式去思考按照产品的方案 ，到底能不能解决用户对安全性担心的问题 ？很显然 ，上车后扫描司机师傅的脸是个伪命题，晚上加班后打车回家 ，上车后先扫描师傅的脸 ？车里光线那么暗，你还着急回家，这时候不扫师傅的脸不匹配 ，这种场景合适么 ？就算是白天乘车 ，用户拿着手机去扫一个陌生人的脸 ，用户和死机师傅尴尬么 ？后来滴滴就取消了这个扫师傅脸的功能 ，反而直接是看实际乘坐车辆的车牌号是否和打车车牌号一致 ，司机师傅校对乘客手机号 ，匹配上后就可以直接上车了 。基于这个案例 ，我们接到需求后 ，先质疑 ，扫脸真的能解决用户对安全性的顾虑问题么？然后我们去做场景还原 ，发现扫脸这个解决方案并合适 ，最后给出判断 。这就是我们独立思考的过程 。
再举个例子 ，最近我想买一个 iPad 二手键盘 ，在闲鱼上搜索后和一位小伙伴交流很愉快，于是开始见面交易 ，见面后 ，我在闲鱼付款，他点击发货 ，不到一分钟我点击确认收货 ，这时候出现了风控的问题。正常来讲，我已经确认收货 ，资金应该直接到卖家支付宝 ，但是由于发货和确认收货时间间隔过短 ，闲鱼判定买家受骗 ，资金冻结 ，卖家拿不到钱 。过了几分钟，有个杭州电话打来询问我是否收到货 ？直到我回复确认收到货物以后 ，资金才到卖家账号 。通过这个小案例，我们分析一下产品需求的场景 。
首先要确认场景：卖家发货时间和买家收货时间间隔过短，闲鱼平台判定为风控交易，冻结资金 。什么时候才会出现这种情况 ？
基于以往买家被骗的案例 ，为了减少买家被骗事件的发生 ，产品经理就把这种场景判定为风控交易 ，打电话给买家二次确认后才把资金给卖家 。我们思考一下，首先质疑这种场景存在么？确实存在 ，新闻上确实也看到过这样被骗的案例，这个需求是成立的，有价值的 ，这个需求值得做 。
总结一下独立思考的过程就是 ：先质疑 ，质疑对方说的话对不对 ，成立不成立 ？然后整合线索，全局思考 ，定义问题 ，最后得出正确的答案 。
最后我们思考一下 ：在一辆 7 座 中大型 SUV 车中 ，智能车舱（HMI）副驾驶位置添加一块大屏幕 ，作为副驾驶的娱乐屏 ，这个需求是否成立 ？
虽然本文写的对接场景有些理想化 ，在日常的工作需求对接中 ，根本没有时间让设计师们去思考 ，一般情况下需求来了 ，设计师作为执行把 UI 画好看就行了 ，通过我以往的工作经验认知，没有思考的执行，就是停滞不前 。我记得之前周陟老师说过 ：同样一张 UI 页面 ，新手只是看到了图标的好看与否，高级设计师看到了背后的交互逻辑 ，而专家设计师看到了背后的运营策略以及对平台产生的价值 。为了能更好的提高我们对需求和业务的理解 ，我们应认真对待每次需求 ，再小的需求也有它可研究的价值 。
本文介绍的两种方法：场景还原 、独立思考 ，不仅仅运营在工作中 ，在生活中也特别实用，对待每件事情都要有自己的观点和看法 ，有自己的理解 ，就算当时理解是错的，随时思考的深入 ，慢慢也会发现真相 。
最后，加入您看完本文认为对自己有一些帮助 ，请把本文分享给自己的好友 ，谢谢 。
作者 ：七帅
