設計評審是連接前期構思和后期實施的關鍵環節，在需求的生命周期中有著里程牌式的意義。那如果將自己的設計方案講好呢？讓我們從作者這里學習一下吧~

一、設計評審的類型和目的

需求規模不同、所處階段不同，評審的目的就可能不同。按照目的來區分，工作中常見的設計評審，評審的類型大體有「方向評審」和「方案評審」兩類。

第1類：設計方向評審

一些規模大、復雜性高的設計需求，有必要在設計方案輸出前進行一輪方向評審，目的在于確?！叭绾螌⑹虑樽稣_”。評審的內容主要是基于需求背景的闡述、設計目標和競品方案的分析，草稿、線稿的繪制，確定大體的設計思路和方向，以確保在后續方案的設計中不要跑得太偏。

第2類：方案細節評審

這類評審在設計工作中最為常見，一般是在全部設計方案完成以后，目的在于確?！皩⑹虑樽稣_”。按照評審參與人的不同，評審的側重點又可以額分為兩種。

側重評估方案合理性

主要由設計經理、其他設計師參與，一般會簡單同步需求背景和設計依據，并將重點放在操作流程、界面設計上，對比討論不同方案的優缺點、發現當前方案中的細節問題，通過評審的方式完善設計方案。

側重評估方案可行性

一般由項目組的產品、開發、運營參與評審。此類評審一般會簡單同步設計分析過程，重點闡述方案設計細節，以幫助下游理解設計方案，在此基礎上討論方案可行性、提前暴露后期實現風險，確保項目正常開展。

二、評審前的準備工作

評審的形式一般是開會，而大家參會是有時間成本的，因此做好評審前的準備工作，就是對他人的時間負責。當然，組織評審的前提是能解的問題已經解了、要做的方案已經做了，評審是就自己發現不了的問題或決策不了的方案進行討論。在此基礎上，評審前一般需要進行如下準備。

1. 背景信息的補充完善

參與評審的人并不一定會了解需求背景，比如有時我們在前期溝通需求的時候，是和產品經理口頭聊的、有些數據資料我們是自己在報表中查的。因此評審前最好將這些材料簡單整理并同步給大家，幫助大家更好地理解需求背景和約束條件，更加高效地決策。

除了整理已有的資料外，有些需求的業務邏輯或交互流程非常復雜，當逐個去講頁面的時候大家容易可能不太容易理解。此類需求我們有必要簡單梳理下流程圖，以便參與評審的人能夠快速了解需求的全貌，定位評審的重點。

2. 設計方案的自檢

評審前首先需要確保的，就是不要存在很多“低級錯誤”。比如是否有錯別字、該對齊的元素是否存在沒對齊的問題、該和線上組件保持一致的地方是否有保持一致、是否存在字號太小看不清的情況等等。提前解決這些問題，不僅能提升評審的效率，而做不好，則不僅浪費大家的時間、也容易給人造成設計草率的印象。

3. 提前和上游同步方案

設計作為需求的承接者，評審的設計方案應該是要提前同步給上游的產品或運營人員。一則是因為業務方的訴求和也是評審的考量因素，而是可以避免方案評審通過了，但上游產品人員不認可的問題。

除了同步上游外，如果設計方案的難度大、復雜度高，也需要提前知會開發同學，以了解是否可以實現或存在何種風險。如果自己不是項目的主設計師，還應該和主設計師對齊方案，避免讓評審成為兩個人的會議。

4. 確定評審的時間節點

評審的時間節點一般在設計的后期、策劃定稿之前，不一定非得完全定稿再評。這是因為，一旦我們本著“這個方案定稿了”的態度去評審，就很難再接受他人的建議，從而將評審會變成宣講會，參會的人也會有一種“既然你都定了還叫我來干嘛”的困惑。

5. 邀約評審人

任何會議中，讓誰參與評審都是很重要的。拉了不相關的人來評審，浪費了對方的時間還達不到評審的效果?？傮w來說，評審要邀約的人，是對設計方案的整體、或細節有決策權的人。按照不同的評審目的，評審需要要求的人分為以下兩類：

1. 如果要評審“方案好不好”，更多是邀請對設計方案有決策權（如設計經理）、或相關業務經驗更豐富的同學參與。
2. 如果要評審“方案行不行”，則需要邀請開發工程師、產品或運營參與評審。

三、設計方案講解及評審

1. 講解設計稿的整體思路

講設計稿的時候，有的同學會一上來就講我做了一個某某落地頁、頁面頭部有哪些元素、點擊某個按鈕會打開某彈窗等。除非在坐的所有人都對這個需求非常了解，且知道你的設計過程，否則，一上來就講方案是一種典型的錯誤做法。

在大部分情況下，參加評審的人可能對需求背景和設計過程并不了解。因此，講解設計稿最好還是按照黃金圈法則去講，即：為什么做這個需求、要解決什么問題，再講自己采用了何種設計方法、具體怎么分析的，最后講具體方案是什么（詳細講解過程見下文）。

2. 講解設計稿時的具體順序

STEP1 需求背景介紹

這部分主要是在回答“為什么做”的問題。一般可以從用戶側和業務側兩個方面來介紹，即“用戶為什么會有這個需求”以及“滿足這個需求能給產品帶來什么”。

一種常犯的錯誤是，介紹背景的時候只講上游的訴求，給人一種“我只是承接了個需求”的感覺。相反，我們應該更多講自己對需求的理解，從用戶視角去講解為什么用戶有這個需求、典型的需求場景等。

STEP2 簡單講解設計過程

實現需求的方案往往不會只有一種，設計最終給出的方案往往是根據設計目標、數據表現、規范約束、實現成本等方面綜合評估后的結果。為了讓評審的同學更快速地理解為什么是最終這個方案，有必要對設計的過程進行簡單介紹。當然，為了評審效率，我們沒必要一上來就講太多的過程，而是建議過程簡單過一下，如果對方案有疑問，再回過頭來補充討論過程即可。

STEP3 按照用戶的行為路徑講解方案

設計不只是畫幾個界面，而是利用界面來幫助用戶完成任務的過程。有些同學在講設計方案的時候容易忘記交代需求的具體場景，而是一上來就進入到：頁面有哪些元素，點擊哪些元素有什么反饋。這樣可能會給大家一個困惑：用戶怎么接觸到這個頁面的？要進來干嗎？也就難以代入用戶的需求和目標來評估方案。因此，我們在講的時候需要從用戶的使用路徑來，比如用戶會在哪些地方接觸到入口、進入頁面后的主要任務是什么。

在講解任務流程時，注意最好先講主要任務流程，再講分支流程。比如對于搜索來說其主要任務流程就是輸入點擊搜索icon→輸入搜索關鍵詞→瀏覽搜索結果→查看結果詳情，分支任務可能包括搜索歷史詞的管理、無痕模式的開啟等。

3. 應對意見和建議的方法

評審的目的就是要讓大家提出自己的見解，幫助我們發現自己方案中的問題和改進點，但我們面對他人的質疑都會本能地捍衛自己的方案，從而讓評審變成一種宣講。為了更好地應對他人的建議，我們可以訓練自己按照以下的順序來應對建議和意見。

• 聽懂對方：對方提出的是事實，還是觀點。該事實是否和方案有關、該觀點源自哪里？如果沒聽懂，可以重復并確認問題，再回應問題。
• 補充信息：是否有些背景信息或客觀條件的制約是參與評審的人不了解的？如果有可以同步給大家。
• 重申目標：如果討論較久，有時會導致大家忘記核心目標而深陷于細節，此時可以嘗試重審目標，以此來讓討論更加聚焦。

此外，在設計方案中有意見分歧很正常，甚至會出現各抒己見而難以決策的問題。如果出現這種情況，原則應該由在場的具有最高決策權的人拍板，或者會后進一步研究，避免在一個問題上浪費太多時間。

四、評審過程中的注意事項

1. 清楚說明評審的范圍

UI或視覺的設計，有些時候是針對頁面上的某一部分做的優化，因此評審的時候最好提前說明清楚具體優化了哪些，避免大家討論了半天，才發現不屬于本次優化范圍的情況發生。

2. 避免成為“快嘴王”

評審時被一堆眼睛盯著，大家會習慣性地緊張，一緊張就容易語速加快，以至于大家想說話都插不上嘴。但這樣不僅違背了評審的目的，也會讓參加評審的人無法或不敢提出想法。因此，我們一定要養成在講解中停頓的習慣，講完一個模塊稍作停頓，或征詢下他人是否有建議再繼續。

3. 給大家一個可以討論的“靶子”

有些需求比較復雜、操作流程也比較，對每一個步驟逐一討論沒有必要，這時評審人最好能在講的過程中強調下本次評審的重點或需要討論的地方。比如對比方案A和方案B的優缺點、流程上的改動點等，以便大家能快速聚焦于關鍵問題。

4. 控制問題的討論時間

評審組織者需要控制評審節奏以使評審盡量高效。一個具體的問題，討論一般在5分鐘內結束，比較重要的問題討論也不要超過10分鐘。時間過長的討論，不光已經提不出新的觀點和論據，還容易讓大家陷入情緒對峙，從而忽略了更重要的問題。

5. 記錄待解決的問題

需求規模越大，評審的意見就越多，因此我們要做好意見記錄。記錄時應善用在線協作工具（比如figma的評論），免得問題太多而被遺忘。需要會后解決的重要事項，也應該在有結論以后給相關方及時回復。

五、總結

本文圍繞著設計評審這一項目流程的重要環節，從如何做好評審前的準備工作、到如何講好設計方案、以及如何應對日常評審中出現的常見問題給出了若干建議，希望對大家講好設計方案有所幫助。

最后，雖然「評審」兩個字聽起來像是一種讓人壓力山大的審核，但我們更多應該將其視為一種「評估」，一種對方案優劣勢、方案上線風險的前期評估，這樣我們或許可以以更積極、更輕松的心態面對它，利用這種形式幫助我們更好地「做好設計」。