如何讓一個未入行的產品經理放棄這條道路？答：那就帶他參加一次內部評審會吧；
如何讓一個剛入行的產品經理放棄這條道路？答：那就帶他再參加一次外部評審會吧~
對於許多產品經理來說，設計完原型，或許只是噩夢的起點......
內容回顧
之前的文章，我們主要總結了抽象的設計思想如何能更好地通過具象的原型表達出來，這裡只回顧一個核心觀點，因為這個觀點也是支撐我們設計評審的重要依據：
- 原型本身並沒有那麼重要，重要的是我們的設計思想；
- 但原型又是必要存在的，它是項目開發的標準和依據。
設計評審之劫
1. 現狀和原因
正如我們引言所述，設計評審，似乎是每一位產品經理成長過程中的必經之劫數。
對於需求階段抽象的文字概念，大家可能無法做出過多的爭論。於是各種意見，就猶如天雷滾滾一般，都集中在了可視化的原型之上，而原型的設計者自然也就成為了眾人抨擊的焦點，其慘烈之程度簡直不可描述~
究其原因，無非是感性的個人喜好以及理性的個人立場不同。
（1）感性的個人喜好
我們在本系列文章的第一篇中曾表達過一個觀點，評審會議上喋喋不休的爭論，是因為所有人都把設計方案當成是畫作，而從感性的角度來說，每個人又都有自己的喜好，因此討論無休無止，永遠都確定不了最好的方案。
（2）理性的個人立場
每個人也都有理性的一面，有時候理性的話語聽起來似乎都對，但大家就是無法達成共識，這是因為每個人所承擔的角色，以及所處的立場不同。
領導希望能夠早點上線；運營希望有足夠多的推廣空間，設計師注重產品是否美觀，開發人員則關注設計方案在技術上是否易於實現.....
我們可以看到，設計方案所面臨的“四面楚歌”之勢，而有時候設計方案本身並沒有什麼不好，但結果卻也只能是風蕭蕭兮易水寒了......
背後的邏輯
感性的個人喜好意味著大家並沒有理解原型承載的設計思想；
理性的個人立場意味著大家並沒有明確產品定位或設計目標。
2. 目的和意義
在探究如何才能成功渡劫之前，我們需要先了解設計評審的目的和意義，主要包括以下四個方面：
（1）檢驗目標
在需求分析以及設計規劃階段，我們確定了一系列的目標，而設計方案則是這些既定目標的產物。在設計評審階段，首先要檢驗的就是設計方案是否達成了最初確定的目標。
（2）發現問題
設計評審集中了各種各樣的角色，可以及時發現問題、規避風險。並且這個時候還沒有進入實際開發階段，設計方案的調整是相對容易的，節省的是整個團隊的成本。
（3）達成共識
設計評審需要讓所有相關人員熟悉整體設計理念和設計內容，確保大家的理解與設計方案是一致的。這樣才能順利進入下一個階段，避免交付之後的反覆溝通確認。
（4）建立口碑
從自身的角度來說，其實對於產品經理而言，設計評審也是一個建立口碑的過程。如果每一次評審都能夠有理有據地講述設計方案，體現專業素養，久而久之大家會不斷地提升對設計者的信任感，溝通也就會越來越順暢。
3. 方式和方法
如何才能在設計評審會中成功渡劫，這或許是大家最關心的問題，我們可以從會議前、會議中、會議後三個階段來進行總結。
（1）會議前：充分準備
總結起來，我們需要準備三方面的內容。
第一方面：各種設計依據
我們需要在會議開始之前，將用戶調研的結果、支撐的數據、競品分析的內容、需求分析階段制定的目標，等等，都準備充分。
另外，如果某些內容，由於不可抗力因素，並非按照自己初衷設計的，那最好把相關的“證據”也蒐集一下，例如客戶的要求，或者領導的命令，等等~
舉一個我實際工作過程中的例子，供大家參考。
就這樣一個首頁面，評審時有人給出了這樣的反饋：“可以把功能入口放上面，然後那些tab切換的內容，別讓用戶來回切，內容都拉出來平鋪展示就行了。”
然後呢，我陳述了自己的設計理念，陳述理念換回的結果就是這個界面保持原設計，不用更改~
“首頁之前那麼做，是因為考慮作為一個輔導員，在首頁最先關注的應該是正在執行任務的進度情況，而且按照我個人理解，根據這些任務的使用頻率，依次排列了簽到、通知、信息、活動報名。之所以用tab切換的形式，一方面是因為有些任務可能是空的，在當前不一定有，輔導員只需要看到上方的數字為0就可以了；還有一點，也是最重要的一點，就是因為想讓用戶一眼看到正在執行任務的所有情況，整體任務的進度以及功能入口，在一個手機屏幕內能夠展示的下。”
第二方面：多種可能方案
這裡所說的多種可能方案，並不是說需要我們把所有能夠想到的方案都呈現出來。而是說有時候確實存在兩種，或者兩種以上的設計方案各有利弊，我們也很糾結。
這個時候，就可以把這種“選擇題”拋給大家，讓大家共同確定一種最優解。
第三方面：重點人員，單獨確認
參與討論的人越多，意見發表的越多，就越難以得出結論。所以呢，越是重要的事情，越要儘可能少的人參與討論，這樣才能快速下定論。
這就需要我們在會議開始之前，先私下和一些有話語權的重點人員單獨溝通，並達成共識，而不是把所有問題都拋到會議上解決。
這樣可以大大提高會議的效率。當然，同樣關鍵的是，在評審的戰場上我們就有了戰友，而不至於孤軍奮戰~
（2）會議中：主導流程
正確的設計評審流程應該是這樣的：
設計方向可以將參會人員的思路都統一到一條線上，在產生分歧時，這個方向可以作為判斷的標準和依據。
設計分析是為了讓參會人員能夠明白設計方案的原委，而不至於把焦點集中在原型界面這種表象化的內容當中。
之後才是設計方案的展示，以及相關的探討。
對於會議討論，有這樣一句，所有人都應該竭力避免的經典語錄：“會而不議，議而不決，決而不行，行而不果！”
會議討論中偏離主題的情況簡直太常見了，有時候一個原型評審會議，說著說著又回到了需求邊界的探討當中，或者是直接跑到UI設計的層面當中了。
這就需要主持會議的我們具備一定的控場能力，會議開始前首先明確探討的主題和邊界，會議過程中則需要將偏離主題的討論及時拉回正軌。
（3）會議後：篩選意見
在會議中，我們會收集到大家表達出來的各種各樣的意見。等到會議後，我們就需要對意見進行篩選，而我們需要重點篩選的是那些客觀的、明確的、可以操作的反饋意見。
須知，作為產品設計者，我們一定要保持開放的心態，需要積極採納有價值的反饋，以及傾聽大家的意見，而不要過於捍衛自己的設計。
畢竟每個人提出的反饋意見，最根本的出發點，都是為了產品能夠更好。
產品上線之劫
內部的設計評審，確實能夠幫助我們發現以及規避很多問題，但交付設計方案，絕不是設計流程的結束。
我們的設計方案，是否能夠達成既定的目標，最終還是要經過用戶的檢驗。如果用戶不買單，那這個產品終究也只是個贗品。
在產品上線前後，我們需要使用一些方法來檢驗設計成果，以幫助我們的產品雛形成功渡劫。
此時可用的方法，總結起來有以下四種。
1. 可用性測試
這種方法常用於產品上線之前。
簡單地說，就是通過觀察用戶使用產品的情況，發現產品中存在問題的一種方式。
具體做法如下：
（1）在測試前，設計出幾個能反映出產品核心操作的任務；
（2）招募5名左右的用戶，這些用戶最好可以代表產品的真實用戶；
（3）在測試過程中，仔細觀察用戶對於典型任務的操作情況，記錄下發現的問題；
（4）在測試完成之後，對發現的問題進行分析，並進行優化。
可用性測試是一種定性分析的方法，樣本數量小，結果未必完全可靠，但可以瞭解用戶的真實想法。
2. A/B測試
這種方法也是常用於正式上線之前。
簡單來說就是比較A方案和B方案優劣的一種方法。為同一個目標設計兩種方案，一部分用戶使用A方案，一部分用戶使用B方案，最後通過用戶的使用情況，衡量哪個方案更優。
此種方法需要注意以下三個要點：
（1）設定衡量標準，比如PV、UV、點擊量、轉化率、跳出率、二次返回率等等；
（2）不同版本保持單一變量，不然很難確定結果不同的觸因；
（3）保證兩個版本同時測試。
由A/B測試衍生出來的，另外一種常見方法是灰度發佈。灰度發佈是一種平滑過渡的發佈方式，通過觀察用戶的反饋和數據，如果用戶的反應很好，可以逐步擴大範圍，直至全部升級。
這種方式其實我們是經常見到的，就比如現在的微信版本中，有很多人已經上線了“視頻號”的內容，而另一部分人則還沒有。
A/B測試是一種定量分析的方法，樣本數量大，結果較為客觀，但我們很難直接通過數據瞭解到背後的原因。
3. 用戶反饋
任何的產品，都應該保留用戶反饋的通道。比起任何依據理論的推測或者是漫無目的的假設，用戶的聲音才是我們最應該傾聽的。
但系統收集上來的用戶反饋往往是零散的，或者說是雜亂無章的，我們需要將這些內容整理分類，才能夠真正地發現產品中存在的問題。
我們可以從內容、功能、使用流程、設計、新功能建議和現有bug等幾個方面對問題進行歸納。
4. 產品數據
同樣在本系列的第一篇文章中，我們表達過這樣的觀點：
人的反饋是感性的，通過這種反饋得到的信息，有時候往往不可靠，而且最關鍵的是，有時候用戶並不知道自己所說的並非心中所想，這就是感性思維的特徵；但是數據是理性的，數據不會說謊，加入埋點技術，我們就可以客觀地分析問題所在了。
產品數據，是能夠幫助我們產品雛形渡劫的重要內容。
結語
到此為止，就是我們用戶體驗設計系列的全部內容了。我們用了四期的時間進行了總結，希望這些內容能夠為大家前行道路上帶來些許幫助。
最後再把這樣兩段話送給大家，希望與君共勉。
我們可以把產品的用戶體驗分為4個層級：
第1個層級是有用；
第2個層級是可用；
第3個層級是易用；
第4個層級是好用。
我們也可以把產品設計師分為3個等級：
第1個等級，平庸的設計師想的是完成需求；
第2個等級，優秀的設計師想的是儘自己所能把需求做到最好；
第3個等級，卓越的設計師則優先考慮，這個需求到底合不合理，值不值得去做，對產品有什麼幫助，用戶是否需要它，等等。
最後的最後，也祝願疫情能夠早日結束，“驚喜會在裂縫中結果，那一天，值得等待，那一眼，滿載星海”！
我要去繼續準備接下來的內容了，請給我一點時間，我會很快回來的。
閱讀更多 PMTalk產品經理社區 的文章
