作為深圳網絡公司的產品設計師，遇到方案被質疑也是常有只是。但是，并不是說我對此無所謂。相信有很多像我一樣的產品設計師，遇到這樣的文章，總會有點悶悶不樂，或者曾懷疑過產品設計的價值。其實不管是做產品設計還是做產品經理，在工作時總會遇到唇槍舌戰的。雖然我不喜歡爭吵，但是我會想盡辦法去證明我的想法是對的。有義正言辭的也有歪門左道的，有有理有據的也有撒嬌求饒的；總之只要是能按照我的想法做了，賣藝賣身什么的都是可以的；呃~~說多了，還是進入正題吧~

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

目的很容易理解就是為什么做這個事情，目標就是想要達到一個什么樣的效果。這個之所以重要是因為當你為自己的方案申辯時，你需要告訴對方這是達到該目標最便捷的方案或者性價比最高的方案亦或是開發成本最小的方案。當對方認可了你的目的和目標之后，那么基于同一目標他如果無法第一時間想出一個更好、更易開發、更xxx的方案，那你基本就已經成功80%了~；接下來就坐等他幫助你完善這個方案的細節吧~

當然這個方法要求大家都必須有大局觀并且認可你這種“目的、目標”的工作方法，而難點在于并不是每一個方案都會有明確的目標。我想身為產品或者交互，你懂得~~

其次，用類比法說服你的伙伴或者基友們接受你的方案~

類比法其實很容易理解，就是把你的方案比喻成現實生活中發生的事情；這樣通過大家都有的經歷，曉之以理動之以情得到共鳴達成一致，可謂是一氣呵成！

其實不只是爭吵才能解決問題的，講故事同樣可以的。

對了，不要忘記你們當時打點統計的那些數據~

有時候開發哥哥們會弱弱的問產品或者交互：你們統計的這些數據全部都會看嗎？答案是并不一定全部都會去看，但是需要它的時候沒有你也會很頭疼；線上的數據可以說是最有利的證據去證明方案的好壞與對錯；所以在你提交新方案之前可以將之前方案已有的數據準備好，用以證明這個問題非改不可或者改了以后數據會有所改善；

當然很多時候數據只能說明線上的方案有問題，并不能證明新方案一定會更好。這個時候就需要你在執行新方案的時候也做好數據統計的工作。等上線后將兩份數據進行對比并將最終結果郵件發送給你的開發哥哥們（記得抄送給他們的領導），方案的好壞一目了然自然不用你多費唇舌。久而久之彼此的信任感會慢慢建立，當你再次把線上數據和新方案拿給他看的時候，他們會心服口服的認可你、幫助你；剩下的事情就是怎么把這件事情做的更好、做出成績~

還有一個方法，你可以通過問題的發生的概率和帶來的影響、方案帶來的提升和開發的成本去說服對方；

這個方法是我在網易的時候聽另外一個同事分享的方法，當時覺得這個很有道理就記下來；他的原話是這樣的：當你想要解決一個問題的時候需要考慮一下這個問題發生的概率和帶來的影響；當你告知別人你有一個方案的時候需要考慮下方案帶來的提升和開發的成本。這幾件事情想明白之后你才可以去和你的同事溝通；這個道理其實很簡單，發生頻率很低的問題可能重要但是不緊急，可以優先處理影響較大的問題，而低開發成本效果提升顯著的方案自然最受大家青睞。當你要和其他部門競爭開發資源的時候，不妨一試這個理論這個方法；或許它會讓你在眾多的競爭者中成為贏家~

最后，進行小測試或者做個小調研

我們可以進行小規模的可用性測試（灰度測試或者A/B test ）或者借助外力（例如用研同事或者是身邊的同事或者朋友）的幫助做個小調研；

先說一下灰度測試和A/Btest,很多網站（包括移動端和web端）你會發現他們很長時間都沒有大的頁面改版；其實并非是它們沒有做優化，反而是它們會進行很多灰度測試；例如Booking web端就有一套很完整的灰度測試框架，大到上線的新功能小到button顏色的變化、位置的變化都會進行灰度測試（我沒有實際驗證過，聽同事說的）；效果不好的功能或者優化不會上線面向用戶；

這個對于產品而言是最有力的證據，但是國內并沒有多少家公司會去搭建灰度測試或A/Btest的框架支持產品做這件事情；所以很多時候還是得另求他法；你猜對了可用性測試和用戶研究要登場了；

以前做交互設計師的時候，每當我無法確定方案好不好或者哪個方案更好的時候，我就會想起我們用研同事親愛的臉龐；然后屁顛屁顛的去尋求他們的幫助。當拿著用研的測試報告去和開發談case的時候簡直就像是身披盔甲的勇士，有一種以一敵百的氣勢和此戰必勝的決心~~然而很多創業公司初期可能并沒有用戶研究這樣的崗位配置，沒有關系你可以問一下自己身邊的同事或者朋友呀（甚至是你的那些開發哥哥弟弟們）；測試或調研的這些人中如果有半數以上的認為新方案比線上更好，那么這個結論同樣會幫助你打一個漂亮的翻身仗~

說來說去還有一種情況就是所有的方法都無法證明方案的好壞對錯，對待這些問題奉勸一句不必過多糾結，上線后密切關注數據及時修正便是極好的！最后想說一句：如果能用一杯奶茶就能解決的問題，以上所有方案都可飄過~