設計師對設計評審（Design Review）想必都不陌生，從方式多樣的用戶/客戶評估（User/Customer Validation）到會議型的專家評估（Heuristic Evaluation），到項目導向式的Stakeholder Review，目的都是為了通過向不同的相關方咨詢，驗證，收集意見和問題，設計出符合用戶預期以及使用習慣的體驗，保證產品質量。同時，商業設計不是藝術品，除了為用戶提供一流的體驗之外，如何取得項目各方stakeholders的認同，吸收他們關於項目整體規劃，研發日程，技術限制等方面的意見，對推進設計的落地具有決定性的作用。
本文著重闡釋設計師如何有效地運用Stakeholder Review來確保企業產品設計的質量和落地。
設計師的難題：
就企業產品和其服務的用戶而言，企業產品設計師面臨多重挑戰。
用戶基數相對小，且難以在日常工作過程中觸達。比如微策略主要做的是服務於商務智能領域的數據分析產品，我們的用戶大多分佈在世界各地的大公司集團，很難實現頻繁的實地用戶訪談和可用性測試。
領域知識（Domain Knowledge) 專業性強，不容易建立起用戶同理心。
用戶需求跨度大。當不同的Persona都使用同一款產品用來工作時，他們的動機和使用場景可能大相徑庭。
對產品的精確性有較高期望。當用戶使用產品的目的是為了完成工作目標，這表示他期望得到的結果是精準無誤的。數據分析產品在這方面更是不得差池，這會關繫到商務決策的效率和正確。
好的設計評審是挑戰更是機會：
完善對用戶，需求，應用場景和優先級的理解
上文提到，企業產品用戶基數相對較小，也不容易找到訪談或者測試的對象。而類似產品經理這類具有豐富產品和客戶經驗的stakeholder的介入，能在方案的初期，也就是確定設計方向時，就給出關於應用場景，用戶JTBDs以及現有產品痛點的具體建議和評估。設計師的思路也被更大程度地打開了，能更好地看清楚目前的方案中，哪些符合了用戶的預期，哪些是欠缺考慮的，哪些需要重點突出地呈現，哪些只是edge case. 從而在後續設計可以較全面地作出改進。
獲得專業領域知識，以更好地理解用戶行為
對於專業知識要求較高的需求，在評審中，邀請一兩位領域專家（SME），站在高級用戶的角度，評估目前的設計是否符合他們的需求。在BI產品的設計中，有一類用戶是Admin，他們的主要工作是對整個環境，系統進行配置和監控，處理優化產品運行過程中出現的問題。這部分用戶通常是典型的工程師思維，一些看起來生澀的術語和表達，是他們的日常用語，很多高級功能，他們則傾向於直接敲命令行解鎖。在評審中，角色相近的專家更能代表此類用戶的意見。同時設計師也可以藉此機會向他們咨詢專業部分的知識。
互相啟發，找出問題
評審中大家意見不一致再正常不過了，在觀點鮮明，企圖說服對方的同時，也是一個不斷的被對方所啟發的過程，每個人的思維難免局限，換個角度來看自己的設計，更有利於發現問題。
多方同步溝通，透明高效
項目涉及多方stakeholders, 很多時候還是異地，花了很大力氣去溝通，往往和產品經理觀點一致以後，卻遭遇到來自開發團隊的技術局限。讓多方stakeholders在同一平臺上溝通，大家盡早把問題提出來討論，高效透明，即使無法當場達成一致，也能很好地整理出最需要改進的地方，在下一次的會議中或者郵件討論中，大家都能快速進入上下文。同時這也是很好的機會，讓大家順便溝通後續計劃以及明確接下來的action plan。
微策略UXD的設計評審流程介紹：
上圖是微策略UXD採用的設計和評審流程，評審部分總共分為A,B,C三個階段,每個階段的評審目的和對設計輸出的要求都不一樣。
初期評審 Design Review A（DRA)
在這個階段，評審的目的是確定設計方案的方向是否正確，是否符合商業需求以及滿足用戶的Jobs To Be Done。設計師在會上向stakeholders演示自己的用戶研究成果，設計思路和方案，更註重交互的workflow，而不是具體界面細節。其中Persona和用戶體驗地圖是的綜合使用是很有效的向非設計師的stakeholders展示用戶實際的目標，使用旅程和目前痛點的工具，使得整個分析和設計的展示過程故事化，更能喚起評審人員的同理心，對於站在用戶的角度思考問題，從而更好地理解設計方案很有幫助。
前期的設計往往會在既定需求基礎上，對整體的體驗進行考慮，這時會相對弱化對技術實現問題的考慮，避免過早地限制設計思路。同時為了節省前期投入，不在畫圖上浪費太多時間，對設計方案的要求是低保真即可。在這個階段的評審會上，我們也要求設計師提供可用性測試的計劃，以便在潛在方向確定後，能有的放矢地進行用戶驗證。
Peer review
設計師對DRA上得到的反饋進行修改，並開始詳細設計的過程中，還會找組里的其他設計師一起做Peer review，就關鍵的設計因素進行討論，以便在下一次的評審之前把更多的問題解決掉，使得方案更加完善。這在設計中也是非常常見的，每個設計師都會得到幫助，也能通過幫助他人得到成長。
中期評審 Design Review B(DRB)
DRB的目的是根據整體設計方案，按優先級確定細節設計，為開發做準備。在這個評審會前，設計師應該已經完成了所有的詳細設計，以及design specifications，並進行過至少一輪的可用性測試，把用戶的反饋作為評審的重要參考。在會上各方的stakeholders會針對設計方案的各方面細節進行討論和確認，同時項目經理會從項目開發的角度，對開發成本和可能存在的技術風險進行評估，對於那些成本太高或者實現有問題的方案，大家也能一起討論出一些替換方案。如果改動太大，設計師在線下修改後，會再進行一輪DRB。
這個會議還可以邀請Design Ops和文檔組的同事，他們會把新出現的Design Pattern和UI 控制項更新到UI Library里，以及確認界面上的文字是否符合母語用戶的習慣。
中期評審結束後，就完成了對項目的詳細定義，大家對即將開發的設計也有了非常具體的瞭解，產品經理會由此正式立項，項目經理開始著手開發測試的事宜。到這里設計師的主要工作完成了，但後續的跟進，以及調整也是必不可少的。
後期評審Design Review C(DRC)
DRC的目的是用流程保證開發過程中的設計落地。在產品開發進行到一定階段，設計的功能界面都穩定實現了以後，設計師會再進行一輪評審，目的是對照確認產品和設計之間的差距，如果產品按照設計稿實現了，但是實際效果卻並不好，一般是指UI，這時候需要對原有設計做進一步的調整。更多的時候是開發沒有按照設計來，那樣的話，這個檢查就很有必要了。我們會把發現的問題都記錄在開發的管理系統里，以此來能保證每個問題都得到妥善解決。
參與評審的stakeholders
這個評審流程的另一個關鍵因素是把各方的stakeholder都召集在一個評審會里進行同步溝通，目前我們要求評審會必須參與的人員主要有：主設計師，UX總監，項目上有相關性的設計師，產品經理，項目經理。
設計師的自我修養:
以上的流程，在經過一段時間的使用後，設計師們開始對如何更有效地利用評審會來快速推進設計進程有了一些心得，主要以下幾點：
設計的表述在評審時很重要，如何讓大家都聽懂你的分析和設計，並感到認同，減少誤會以及無效的意見。講故事是共情的好方法，在分析完persona以及用戶體驗地圖後，把用戶使用產品的過程用一個故事表達出來，這是也能保證設計的完整性。
以用戶為中心，用用研結果來佐證設計，在評審時能增加可信度，有利於大家對方案的認同。
用UX的原則影響stakeholders，避免個人主觀意見以及偏好占主導。久而久之，那些並非設計背景的stakeholders對可用性的原則也都會有所瞭解並在討論時應用，避免了“說不出所以然，但就是感覺不太好”這樣的反饋，意見會更明確和有指導意義。
評審會結束前，設計師應確認設計是否通過評審，如果是，會後在項目系統中把設計的狀態改為review complete，如果以後需求有變動，則必須在此基礎上再進行評審。如果大家對設計提出了意見，那就及時總結，並在會後用會議紀要的形式分發給參與的各方，作為修改和下一次評審的依據。
一個項目經過了三輪（可能會不止，實際操作中會存在DRA/DRB需要好幾次才能完全通過的情況），可以說各方的stakeholder都對項目的目標，用戶需求，詳細的設計方案以及開發難度，和實現情況有了非常深入的瞭解，大部分的信息不對稱, 疑問和不同的觀點，都在這個過程中被討論消化，達成了共識。這不但提高了設計的質量，也保證了後續開發落地的順利實現。