坦白來說，剛開始實習/工作的時候，我一度對設計評審（本文主要指 UX 團隊內部評審）這件事兒感到過恐慌，完全不知道該說什么，如何引導聽眾思路得到建議等；也因此出現了一些語無倫次、或者只是沉默演示設計稿的情況。后來隨著評審次數的增多慢慢好轉，也看似能從評審中得到不少建議反饋，但在后續修改到設計稿細節、和項目組溝通的時候，卻常常發現這些建議反饋存在之前未考慮到的局限性，最終沒有實際轉化為方案落地。本文就寫寫我對自己做得還不夠好的地方的一些反思吧。

1.傳達限制條件不完整

我們知道交互設計需要在商業、用戶與技術三方面之間取得平衡，完全從純用戶角度出發得出的理想方案在商業產品設計中并不太現實。業務目標的沖突、技術框架的限制、甚至不同用戶角色目標之間的矛盾，都會影響到我們最終的設計方案，使其看起來體驗并不是那么完美順暢。

但是團隊里面每個設計師負責的具體業務不一樣，別人對這些限制條件的具體了解程度也不會有你來得深入，所以在評審會議上，他們可能會從更理想化的角度出發思考，給出和限制條件矛盾的思路、建議與解決方案。所以在講解自己的設計方案之前，也應當提前和項目組溝通清楚細節，把這些業務/技術上的沖突點清晰、全面地描述給團隊其他設計師。

比如描述限制條件的根本原因，大家共同判斷是否確實需要進行妥協，探討是否有已經實現的現成案例來證明限制不存在，是否有能取得更好平衡的方案等。像技術限制，是組件改動困難（牽一發而動全身）？是實現成本過高（投入產出的性價比不夠）？是影響速度等性能（實際用戶體驗不佳）？還是其他一些原因等；而如果只是簡單說一句「前端/開發說這個做不了」的話，并不是那么令人信服。

2.目標優先級引導不夠

對于平臺、協作型產品來說，業務目標與用戶目標沖突、不同類型用戶角色目標之間沖突，都是比較常見的事情，設計方案想讓所有相關方都達到最滿意并不現實。

所以在設計評審的時候，也應該引導大家聚焦在當前最重要最核心的目標上，而不是為一個偏離核心目標的體驗優化點糾結良久。比如一個內容型網站的業務目標是提升內容質量維持良性運轉，因此產生一系列監督機制的設計，但這些機制會讓一些用戶感到麻煩、不爽、有心理壓力，那么就需要在優先保證業務目標的基礎上再去探討怎么給用戶帶來更好的體驗；比如產品有多類用戶且用戶目標存在沖突，那就描述清楚哪些用戶是核心，哪些用戶次要一點，優先圍繞核心用戶的體驗探討解決方案。

3.用戶描述代入感不強

作為 B 端產品設計師，我之前和別人解釋目標用戶時都比較簡略，用詞類似「天貓商家」或者「業務方」這樣，可能對于負責類似用戶產品線的設計師來說理解起來還好，但整體給人的印象是很模糊的，不能很好地引導別人代入用戶視角來思考。比如常做 C 端產品設計的同學可能會建議一些普通用戶喜歡的趣味微交互動效、情感化設計等，但實際的產品目標用戶卻有可能并不關心這些，反而覺得過于花哨、影響了自己的工作效率等。

所以我覺得自己之前的那種解釋用戶的方式并不合格，在聽眾對這類用戶并沒有具象認知的時候，應該像設計文檔里一樣，和大家描繪更具體的目標用戶畫像、用戶使用產品的真實場景、面臨的痛點和關注的核心目標等，引導大家更好地代入核心目標用戶而非普通用戶或設計師的角度進行思考。

4.方案演示還原感不夠

在方案演示效果方面，可交互 Demo 的效果大多數時候是勝于靜態設計稿的。有時口干舌燥解釋上一大段某個交互流程中界面如何變化，別人還未必能準確理解；而如果拿一個接近真實效果的 Demo 出來演示具體的轉場過程，就可以在短短的時間內一目了然，大家也能理解得更準確。

不過靜態設計稿也有它自身的好處，比如呈現各種邊界場景更方便、注釋說明更清晰等，而可交互 Demo 如果想顧及到每一個細節場景會耗費非常高的時間成本，在緊張的實際工作中難以踐行。在時間允許的條件下，可以用效率更高的工具（如 Principle ）做一些關鍵轉場的 Demo 來輔助靜態設計稿說明演示，營造更好的場景還原感，幫助大家來準確理解感受設計方案的實際效果、給出更有針對性的建議。

5.私下溝通跟進不到位

設計評審的會議時間最長也就幾小時，在這么短的時間內得到的建議反饋，其實是有不少考慮不夠周到全面之處的，而這些往往要到具體修改方案的環節才發現。所以除了發起評審之外，私下找其他熟悉業務的有經驗設計師溝通探討也很重要，這樣得到的建議啟發也更加成熟和思慮周全。

本文由人人都是產品經理專欄作家 @鴻影 原創發布于人人都是產品經理?。未經許可，禁止轉載。