作为深圳网络公司的产品设计师，遇到方案被质疑也是常有只是。但是，并不是说我对此无所谓。相信有很多像我一样的产品设计师，遇到这样的文章，总会有点闷闷不乐，或者曾怀疑过产品设计的价值。其实不管是做产品设计还是做产品经理，在工作时总会遇到唇枪舌战的。虽然我不喜欢争吵，但是我会想尽办法去证明我的想法是对的。有义正言辞的也有歪门左道的，有有理有据的也有撒娇求饶的；总之只要是能按照我的想法做了，卖艺卖身什么的都是可以的；呃~~说多了，还是进入正题吧~

首先，你得自己清楚做这件事情的目的和目标，这是重中之重；

目的很容易理解就是为什么做这个事情，目标就是想要达到一个什么样的效果。这个之所以重要是因为当你为自己的方案申辩时，你需要告诉对方这是达到该目标最便捷的方案或者性价比最高的方案亦或是开发成本最小的方案。当对方认可了你的目的和目标之后，那么基于同一目标他如果无法第一时间想出一个更好、更易开发、更xxx的方案，那你基本就已经成功80%了~；接下来就坐等他帮助你完善这个方案的细节吧~

当然这个方法要求大家都必须有大局观并且认可你这种“目的、目标”的工作方法，而难点在于并不是每一个方案都会有明确的目标。我想身为产品或者交互，你懂得~~

其次，用类比法说服你的伙伴或者基友们接受你的方案~

类比法其实很容易理解，就是把你的方案比喻成现实生活中发生的事情；这样通过大家都有的经历，晓之以理动之以情得到共鸣达成一致，可谓是一气呵成！

其实不只是争吵才能解决问题的，讲故事同样可以的。

对了，不要忘记你们当时打点统计的那些数据~

有时候开发哥哥们会弱弱的问产品或者交互：你们统计的这些数据全部都会看吗？答案是并不一定全部都会去看，但是需要它的时候没有你也会很头疼；线上的数据可以说是最有利的证据去证明方案的好坏与对错；所以在你提交新方案之前可以将之前方案已有的数据准备好，用以证明这个问题非改不可或者改了以后数据会有所改善；

当然很多时候数据只能说明线上的方案有问题，并不能证明新方案一定会更好。这个时候就需要你在执行新方案的时候也做好数据统计的工作。等上线后将两份数据进行对比并将最终结果邮件发送给你的开发哥哥们（记得抄送给他们的领导），方案的好坏一目了然自然不用你多费唇舌。久而久之彼此的信任感会慢慢建立，当你再次把线上数据和新方案拿给他看的时候，他们会心服口服的认可你、帮助你；剩下的事情就是怎么把这件事情做的更好、做出成绩~

还有一个方法，你可以通过问题的发生的概率和带来的影响、方案带来的提升和开发的成本去说服对方；

这个方法是我在网易的时候听另外一个同事分享的方法，当时觉得这个很有道理就记下来；他的原话是这样的：当你想要解决一个问题的时候需要考虑一下这个问题发生的概率和带来的影响；当你告知别人你有一个方案的时候需要考虑下方案带来的提升和开发的成本。这几件事情想明白之后你才可以去和你的同事沟通；这个道理其实很简单，发生频率很低的问题可能重要但是不紧急，可以优先处理影响较大的问题，而低开发成本效果提升显著的方案自然最受大家青睐。当你要和其他部门竞争开发资源的时候，不妨一试这个理论这个方法；或许它会让你在众多的竞争者中成为赢家~

最后，进行小测试或者做个小调研

我们可以进行小规模的可用性测试（灰度测试或者A/B test ）或者借助外力（例如用研同事或者是身边的同事或者朋友）的帮助做个小调研；

先说一下灰度测试和A/Btest,很多网站（包括移动端和web端）你会发现他们很长时间都没有大的页面改版；其实并非是它们没有做优化，反而是它们会进行很多灰度测试；例如Booking web端就有一套很完整的灰度测试框架，大到上线的新功能小到button颜色的变化、位置的变化都会进行灰度测试（我没有实际验证过，听同事说的）；效果不好的功能或者优化不会上线面向用户；

这个对于产品而言是最有力的证据，但是国内并没有多少家公司会去搭建灰度测试或A/Btest的框架支持产品做这件事情；所以很多时候还是得另求他法；你猜对了可用性测试和用户研究要登场了；

以前做交互设计师的时候，每当我无法确定方案好不好或者哪个方案更好的时候，我就会想起我们用研同事亲爱的脸庞；然后屁颠屁颠的去寻求他们的帮助。当拿着用研的测试报告去和开发谈case的时候简直就像是身披盔甲的勇士，有一种以一敌百的气势和此战必胜的决心~~然而很多创业公司初期可能并没有用户研究这样的岗位配置，没有关系你可以问一下自己身边的同事或者朋友呀（甚至是你的那些开发哥哥弟弟们）；测试或调研的这些人中如果有半数以上的认为新方案比线上更好，那么这个结论同样会帮助你打一个漂亮的翻身仗~

说来说去还有一种情况就是所有的方法都无法证明方案的好坏对错，对待这些问题奉劝一句不必过多纠结，上线后密切关注数据及时修正便是极好的！最后想说一句：如果能用一杯奶茶就能解决的问题，以上所有方案都可飘过~