Design Review 的正確打開方式
Design Review，中文翻譯可能是設計評審吧，是許多產品設計師在工作過程中必經的環節，不同的公司或許作法略有不同，在這邊我想跟大家聊聊我對於進行 Design Review 的一些技巧與心得。
Background
最近我們開始在部門內舉辦定期的 Design Review Meeting，為什麼是最近才開始呢？難道以前都沒有進行過 Design Review 的活動嗎？其實是有的。我們過去的作法是產品經理會根據專案的需求，個別安排會議與主管進行 Design Review。這種做法的好處是對於專案而言有更大的彈性，在討論過程中也比較不會有時間壓力。然而缺點是不同產品經理之間對於各自所負責的專案內容以及進度是不了解的，特別是我的部門根據不同的平台將微信以及 App/Web 進行了產品劃分，多數微信的 PM 是不太清楚 App/Web 這邊的情況，反之亦然。這也直接導致了有些需求及功能會在兩個不同平台之間被重複地拿出來討論，有些可以互相借鑑的資源往往要到快進入開發時才被告知，甚至是一些文案的定稿，本應只需要跑一次的流程卻審核了兩次，導致許多人力與時間資源上的浪費。為了讓部門內部的資訊更透明，讓專案的執行更有效率，我們決定從上個月開始固定每週兩次，一次一個小時的 Design Review。
This is how we roll
為了讓 Design Review 能夠順利的運作，我在前期為團隊成員做了一個簡單的 brief，內容包含：
- When：Project 在哪個時間點需要進行 Design Review？
- Who：哪些人需要參加 Design Review？各自扮演怎麼樣的角色？
- How：Design Review 如何進行？
以下是關於這些內容的詳細說明。
When
並不是所有的專案都需要進行 Design Review，也並非在任何時間點 PM 都需要進行 Design Review。Design Review 顧名思義就是對設計進行評審（好廢…），收集團隊成員的反饋來優化設計，幫助我們能夠及早發現設計上的不足並做出反應，如果 PM 手上的專案還處在前期 Planning 的階段，可想而知在這個時間點你可能只會有產品策略、簡單的 User Flow，或者很粗略的設計概念，因此我並不推薦在這個階段「過早地」進行 Design Review。又或者專案已經進入最終開發的環節，在這個階段「過晚地」進行 Design Review 意義也不大，因為大家對於設計上的反饋已經很難去影響到最終產品，頂多只會是細節上的微調。
我個人比較建議來參加 Design Review 的時間點是專案獲得 Approval 以後、正式進入開發之前。在這個階段的專案有比較大的調整空間，也正是最需要眾人的反饋來打磨一個好的用戶體驗的時候。此外我們並不會把所有關於設計的討論都侷限在一週兩次的 Design Review 中，如果專案已經經歷過一到兩次的 review，大方向上取得眾人的共識，關於細節方面的設計決策就可以透過個別的會議或者 Off-line 討論來取得最終 Approval。一來不僅為專案的設計審核提供彈性，也能夠避免等待 review 的專案過多而排不上的遺憾。
Who
一場 Design Review 必須到場的人員分別是主管（決策者）、要 review 專案的產品經理，以及負責該產品的設計師。除了這幾位之外其他部門內的成員都是可以選擇性地參加。試運行兩週左右看下來，多數同事對於 Design Review 都很有熱誠，參加的人數相當踴躍，我想除了因為新流程所帶來的新鮮感以外，在 Design Review 中去了解其他專案無論是產品策略、設計風格，甚至是簡報的架構，對每個人來說都是寶貴的學習機會。在會議當下的討論更有助於非設計專業的同事更了解產品設計的原則與邏輯，甚至是如何從產品需求轉化為具體設計方案的思考過程，從而逐漸具備分辨好的設計與不好的設計的能力。這也是當初我們選擇採用固定 Design Review 所期待發生的化學反應。
參加 Design Review 的人員也並非只是單純地聽簡報、看設計而已。其中有幾位關鍵角色肩負著特殊的任務：
- Facilitator：事前必須為 Design Review 建立一個時間表並在會議開始時負責掌控 Design Review 的節奏，提醒報告者需要加快速度或者以拋磚引玉的方式鼓勵聽眾發問。而在會議的最後需要為本次參與 Design Review 的項目做一個簡單的總結，並詢問報告者接下來將會採取哪些關鍵步驟來推動專案進行。建議由比較熟悉 Design Review 的人員擔任這個角色。
- Presenter：可能由專案經理或者設計師擔任，其任務是簡單地描述正在解決的問題是什麼並提出現在的設計或解決方案。如果時間允許的話，我建議為 Design Review 多準備一份簡報而不要直接打開設計軟體進行 Review，因為在參與多次 Design Review 之後我發現直接用設計軟體來進行簡報會沒有頁面的概念，而且需要經常地挪動畫面。不僅讓聽眾在提問時很難精確的把問題定位到特定的介面設計，也往往會造成觀看上的不適。如果真的沒有時間打開 Keynote 做簡報的話，其實也可以透過 Sketch 內建的原型製作工具來達到簡報的效果，我之前也寫過相關的文章，在下方有鏈結有興趣的話可以看看。
- Notetaker：顧名思義就是負責做筆記的人，因為報告者需要專注於提案以及回答問題，因此 Notetaker 的責任就是把大家對於設計的疑慮以及可能的對策記錄下來，特別是在 Design Review 中達成共識的設計決策，以幫助報告者能夠更精準的根據反饋來優化設計。我的建議是 Notetaker 可以學習把筆記寫成類似 Meeting Minutes 的條列式，這樣一來在會議結束之後就可以馬上把筆記用郵件發給每一個團隊成員，不僅省時間也可以作為日後如果有人對於已經討論且 align 過的設計產生疑慮時的一個強而有力的證據支持。
- Audience：除了以上的角色之外，其他所有參加 Design Review 的成員都是聽眾，聽眾首先必須了解專案的背景以及所想要解決的問題，其次就是要問很多很多很多的問題來幫助專案的負責人發現更多設計的可能性以及協助設計決策。
How
制定流程可以讓新舉措的推動有跡可循而變得容易，Design Review 也是如此。我在事前為 Design Review 建立了一個時間表單，任何需要 review 的項目都必須填寫這個表單來預約會議時間。一個小時的 Design Review 可以容納兩個項目，每個項目有 30 分鐘的時間進行簡報並獲取反饋。
初次參加 Design Review 的項目，產品經理需要在展示設計之前花五分鐘的時間跟大家 brief 項目的背景、業務目標、目標用戶、我們想要解決的問題以及這個項目的 KPI 為何。盡可能清晰且快速的讓聽眾能夠立即進入狀況，然後把大部分的時間留給 Design Review。
在 Design Review 剩下最後五分鐘時，Facilitator 會按鈴提醒，在這個時候報告者必須針對已經 review 過的設計和大家的意見作出暫時性的總結，確認我們是否有達成共識，或者在某些議題還有討論的空間。這點非常重要，因為往往在 Design Review 討論的太發散的時候，大家會忘記設計最初想要解決的問題是什麼？我們是為了什麼目標而進行這個項目？自己本以為達成共識的決定也有可能只是你的一廂情願。把大家拉回來並作出結論能夠避免「個人共識」的情況出現，重新聚焦回設計所要解決的問題。在這個基礎上來進行總結也可以避免關鍵的決策者，例如主管，在事後又回來 challendge 最終定稿的設計而造成不必要的爭論和時間浪費。
Conclusion
最後我稍微整理一下如何進行一場成功的 Design Review 的幾個要點
- 確立明確的角色：在一場設計評審中，每位參與者都有自己應當扮演的角色
- 團隊共識：確保每個人都明白並同意目前所要解決的問題
- Focus on Feedback, Not Criticism：專注於反饋，而不是批評，勇於表達設計提案中值得讚賞的部分
- Laptops and phones stay closed （最後也最難執行的重點）
希望這篇文章能夠幫助各位更加了解 Design Review 到底是什麼？Design Review 為何如此重要？我們又該如何設計一場高質量的 Design Review？另外也歡迎大家分享自己在工作中參與 Design Review 的經驗，或者任何對於文章內容的問題或反饋。
最後分享給大家在參加 Design Review 時需要時刻提醒自己的一句話
“Criticism passes judgment, critique poses questions.”
See y’all!
