当你的设计被开发质疑你如何证明你是对的

　　亲爱的产品&交互设计师，你是否发现你的方案经常被别人质疑；你是否因为无法反驳或者说服他人而闷闷不乐；你是否怀疑过交互设计师的价值？其实不管是交互还是产品经理，工作时的唇枪舌战不可避免；但是我相信一定有很多人和我一样不喜欢争吵的氛围，因此我也是想尽各种办法在避免争吵的同时证明我是对的。有义正言辞的也有歪门左道的，有有理有据的也有撒娇求饶的；总之只要是能按照我的想法做了，卖艺卖身什么的都是可以的；呃~~说多了，还是进入正题吧~
　　首先，你得自己清楚做这件事情的目的和目标，这是重中之重；
　　目的很容易理解就是为什么做这个事情，目标就是想要达到一个什么样的效果。这个之所以重要是因为当你为自己的方案申辩时，你需要告诉对方这是达到该目标最便捷的方案或者性价比最高的方案亦或是开发成本最小的方案。当对方认可了你的目的和目标之后，那么基于同一目标他如果无法第一时间想出一个更好、更易开发、更xxx的方案，那你基本就已经成功80%了~；接下来就坐等他帮助你完善这个方案的细节吧~
　　当然这个方法要求大家都必须有大局观并且认可你这种＂目的、目标＂的工作方法，而难点在于并不是每一个方案都会有明确的目标。我想身为产品或者交互，你懂得~~
　　其次，用类比法说服你的伙伴或者基友们接受你的方案~
　　类比法其实很容易理解，就是把你的方案比喻成现实生活中发生的事情；这样通过大家都有的经历，晓之以理动之以情得到共鸣达成一致，可谓是一气呵成！
　　举个栗子，之前做过一个关于直播的案子；本来的交互方案是如下图一所示：
　　图一 直播人数已达上限的提醒
　　用户在点击【观看直播】按钮的时候进行弹窗提示，告知他直播人数已达上限，不能观看（页面为说明问题随手一画，请不要深究）。然而，到了测试环境走查的时候我发现方案成了图二所示。
　　图二 测试环境的效果
　　究其原因是由于在课程介绍页弹出弹窗的方案客户端需要单独请求数据，而进入直播间之后相关数据会一并传给客户端，所以开发哥哥们觉得在直播间提示也一样，美其名曰还可以让用户进去看看直播间长什么样子。然而真的是这个样子的吗？进入直播间后发现无法观看用户还需要再次点击返回才能回到课程介绍页，这样用户体验会好吗？但是你该怎么取说服技术让他们心肝情愿的修改呢？
　　于是我们把这种情况类比成平时开车出游在高速上最常见的情况。你可以给他讲个美妙的故事：
　　假如某个阳光灿烂周末你的开发哥哥带着女友兴致勃勃的要去自驾游（记得阳光一定要灿烂、妹子一定要身材好颜值高），驶上高速之后忽然前面变的拥堵，这时路边出现了一个温馨提示：很抱歉前方正在施工。然后你一边唱着忐忑一边继续前行；忽然发现前方不通！！！这个时候你肯定心中一万头草泥马飞奔而过，你百分之百会问候刚刚写温馨提示那哥们他们全家！！！为什么刚刚不告诉我，还要我掉头！！！
　　然后你可以意味深长的告诉他：其实这个例子和线上的情况如出一辙，你觉得该怎么办呢？故事说到这里一般技术哥哥们会陷入一种沉默，然后扭头出去抽根烟默默的坐回电脑前拿起了他们的鼠标，因为他们知道你说的是对的~
　　所以不只是争吵才能解决问题，讲故事同样可以~
　　对了，不要忘记你们当时打点统计的那些数据~
　　有时候开发哥哥们会弱弱的问产品或者交互：你们统计的这些数据全部都会看吗？答案是并不一定全部都会去看，但是需要它的时候没有你也会很头疼；线上的数据可以说是最有利的证据去证明方案的好坏与对错；所以在你提交新方案之前可以将之前方案已有的数据准备好，用以证明这个问题非改不可或者改了以后数据会有所改善；
　　当然很多时候数据只能说明线上的方案有问题，并不能证明新方案一定会更好。这个时候就需要你在执行新方案的时候也做好数据统计的工作。等上线后将两份数据进行对比并将最终结果邮件发送给你的开发哥哥们（记得抄送给他们的领导），方案的好坏一目了然自然不用你多费唇舌。久而久之彼此的信任感会慢慢建立，当你再次把线上数据和新方案拿给他看的时候，他们会心服口服的认可你、帮助你；剩下的事情就是怎么把这件事情做的更好、做出成绩~
　　还有一个方法，你可以通过问题的发生的概率和带来的影响、方案带来的提升和开发的成本去说服对方；
　　这个方法是我在网易的时候听另外一个同事分享的方法，当时觉得这个很有道理就记下来；他的原话是这样的：当你想要解决一个问题的时候需要考虑一下这个问题发生的概率和带来的影响；当你告知别人你有一个方案的时候需要考虑下方案带来的提升和开发的成本。这几件事情想明白之后你才可以去和你的同事沟通；这个道理其实很简单，发生频率很低的问题可能重要但是不紧急，可以优先处理影响较大的问题，而低开发成本效果提升显著的方案自然最受大家青睐。当你要和其他部门竞争开发资源的时候，不妨一试这个理论这个方法；或许它会让你在众多的竞争者中成为赢家~
　　来张图放松下心情（图片来自于网络）
　　最后，可以进行小规模的可用性测试（灰度测试或者A/B test ）或者借助外力（例如用研同事或者是你身边的同事或者朋友）的帮助做个小调研；
　　先说一下灰度测试和A/Btest,很多网站（包括移动端和web端）你会发现他们很长时间都没有大的页面改版；其实并非是它们没有做优化，反而是它们会进行很多灰度测试；例如Booking web端就有一套很完整的灰度测试框架，大到上线的新功能小到button颜色的变化、位置的变化都会进行灰度测试（我没有实际验证过，听同事说的）；效果不好的功能或者优化不会上线面向用户；
　　这个对于产品而言是最有力的证据，但是国内并没有多少家公司会去搭建灰度测试或A/Btest的框架支持产品做这件事情；所以很多时候还是得另求他法；你猜对了可用性测试和用户研究要登场了；
　　以前做交互设计师的时候，每当我无法确定方案好不好或者哪个方案更好的时候，我就会想起我们用研同事亲爱的脸庞；然后屁颠屁颠的去寻求他们的帮助。当拿着用研的测试报告去和开发谈case的时候简直就像是身披盔甲的勇士，有一种以一敌百的气势和此战必胜的决心~~然而很多创业公司初期可能并没有用户研究这样的岗位配置，没有关系你可以问一下自己身边的同事或者朋友呀（甚至是你的那些开发哥哥弟弟们）；测试或调研的这些人中如果有半数以上的认为新方案比线上更好，那么这个结论同样会帮助你打一个漂亮的翻身仗~
　　说来说去还有一种情况就是所有的方法都无法证明方案的好坏对错，对待这些问题奉劝一句不必过多纠结，上线后密切关注数据及时修正便是极好的！最后想说一句：如果能用一杯奶茶就能解决的问题，以上所有方案都可飘过~