如果想避免這類問題,可以在評審前先準備這四件事:

第一件事:找產品經理預溝通 產品經理產出設計需求,設計師在這基礎上進行設計任務,所以不管有無評審會,產品經理是都會負責這個需求到底的人,也會是對設計稿最關注的人之一,在評審會之前和產品經理預溝通設計稿可以先讓你和產品經理達成一致,會讓評審會高效,同時其他參與評審的同事有問題時,還可以讓產品經理來一起解答。
第二件事:編排評審順序和整理設計思路 「編排評審順序」相當于把評審節奏控制在你的手中,一切根據你制定的順序進行,一般情況下,可以這樣編排:
- 講解「設計思路」,讓大家先和你的思路對接起來,避免直接看到設計稿時每個人都從自己的角度出發。
- 展示「核心頁面的設計稿」,因為評審人數眾多,如果設計稿狀態很多,涉及到設計稿比較多,可以先把「核心頁面」貼出來,讓大家理解后沒有問題,再把余下狀態作為補充展示出來,不要一上來就一股腦兒的全部一張張展示出來,評審者有很大的可能性并不知道你在說哪個狀態,而讓你失去控制和節奏。

第三件事:預先考慮評審者可能提出的問題 如果能預先知道評審者會問什么問題?是不是就有時間準備好然后胸有成竹的去評審了?我整理了一些評審者可能會提出的問題,評審之前,大家可以對照這些問題自問自答一番,看下哪里還可以再調整下:
- 最后為什么考慮使用這個設計方案?
- 這個需求要解決什么問題?能不能一句話說清楚
- 之前已有的功能的數據是什么樣的?
- 我們的競爭對手是怎么做?有沒有同類型的設計?
- 這個新設計和我們之前設計不一樣,是怎么考慮的?能不能沿用之前的控件?
- 這些元素沒有對齊?是故意的還是粗心?
- 設計稿上面的內容是接近于真實的內容嗎?如果不是可以改成真實的看效果
- 為什么使用這些顏色,在平臺規范中沒有出現過?
- 產品PRD:當有疑問時可以拿出來給評審者查看
- 設計分析文檔:用來溝通關于行業內對于同類型功能的設計優缺點的分析
- 數據分析文檔:用來展示當前版本數據上的表現和問題,以及可以幫助進行下一步改善
- 功能邏輯圖:復雜功能可以使用圖形化表現功能邏輯,便于評審者理解
- 用戶路徑圖:通過用戶路徑講解全局性問題,結合交互設計稿進行具體說明
- 交互動效演示文檔:用來解釋一些比較復雜的交互過程
- 配色情緒版:用來解釋如何選擇當前配色的思路