Design Review 的正確打開方式. Design… | by Edison Chen | AAPD — As A Product Designer | Medium

最近我們開始在部門內舉辦定期的 Design Review Meeting，為什麼是最近才開始呢？難道以前都沒有進行過 Design Review 的活動嗎？其實是有的。我們過去的作法是產品經理會根據專案的需求，個別安排會議與主管進行 Design Review。這種做法的好處是對於專案而言有更大的彈性，在討論過程中也比較不會有時間壓力。然而缺點是不同產品經理之間對於各自所負責的專案內容以及進度是不了解的，特別是我的部門根據不同的平台將微信以及 App/Web 進行了產品劃分，多數微信的 PM 是不太清楚 App/Web 這邊的情況，反之亦然。這也直接導致了有些需求及功能會在兩個不同平台之間被重複地拿出來討論，有些可以互相借鑑的資源往往要到快進入開發時才被告知，甚至是一些文案的定稿，本應只需要跑一次的流程卻審核了兩次，導致許多人力與時間資源上的浪費。為了讓部門內部的資訊更透明，讓專案的執行更有效率，我們決定從上個月開始固定每週兩次，一次一個小時的 Design Review。 為了讓 Design Review 能夠順利的運作，我在前期為團隊成員做了一個簡單的 brief，內容包含： 以下是關於這些內容的詳細說明。 並不是所有的專案都需要進行 Design Review，也並非在任何時間點 PM 都需要進行 Design Review。Design Review 顧名思義就是對設計進行評審（好廢…），收集團隊成員的反饋來優化設計，幫助我們能夠及早發現設計上的不足並做出反應，如果 PM 手上的專案還處在前期 Planning 的階段，可想而知在這個時間點你可能只會有產品策略、簡單的 User Flow，或者很粗略的設計概念，因此我並不推薦在這個階段「過早地」進行 Design Review。又或者專案已經進入最終開發的環節，在這個階段「過晚地」進行 Design Review 意義也不大，因為大家對於設計上的反饋已經很難去影響到最終產品，頂多只會是細節上的微調。 我個人比較建議來參加 Design Review 的時間點是專案獲得 Approval 以後、正式進入開發之前。在這個階段的專案有比較大的調整空間，也正是最需要眾人的反饋來打磨一個好的用戶體驗的時候。此外我們並不會把所有關於設計的討論都侷限在一週兩次的 Design Review 中，如果專案已經經歷過一到兩

最近我們開始在部門內舉辦定期的 Design Review Meeting，為什麼是最近才開始呢？難道以前都沒有進行過 Design Review 的活動嗎？其實是有的。我們過去的作法是產品經理會根據專案的需求，個別安排會議與主管進行 Design Review。這種做法的好處是對於專案而言有更大的彈性，在討論過程中也比較不會有時間壓力。然而缺點是不同產品經理之間對於各自所負責的專案內容以及進度是不了解的，特別是我的部門根據不同的平台將微信以及 App/Web 進行了產品劃分，多數微信的 PM 是不太清楚 App/Web 這邊的情況，反之亦然。這也直接導致了有些需求及功能會在兩個不同平台之間被重複地拿出來討論，有些可以互相借鑑的資源往往要到快進入開發時才被告知，甚至是一些文案的定稿，本應只需要跑一次的流程卻審核了兩次，導致許多人力與時間資源上的浪費。為了讓部門內部的資訊更透明，讓專案的執行更有效率，我們決定從上個月開始固定每週兩次，一次一個小時的 Design Review。 為了讓 Design Review 能夠順利的運作，我在前期為團隊成員做了一個簡單的 brief，內容包含： 以下是關於這些內容的詳細說明。 並不是所有的專案都需要進行 Design Review，也並非在任何時間點 PM 都需要進行 Design Review。Design Review 顧名思義就是對設計