酷播亮新聞
文章作者分享了關於交互設計評審中需要注意的一些事項，希望給你帶來些收穫。
在產品研發流程中，評審是很關鍵的一環，平時在公司工作涉及到的評審環節都包括了產品需求評審，交互設計評審，產品架構評審，視覺設計評審以及測試用例評審。
平時在工作過程中這些評審會議樓主都需要參加，自己往往主導的會議就是交互設計評審，今天就用一篇文章來聊聊交互設計評審我們應該注意的事情。
第一：什麼是交互設計評審
交互設計說明書是交互設計師的工作產物，是根據產品文字需求轉換成的可視化的原型，其中涵蓋了產品操作流程，具體的產品邏輯說明已經頁面佈局說明等
交互設計評審顧名思義就是召集整個產品的團隊包括產品技術研發視覺測試人員等對交互設計師的產品進行討論，從而達到對整個交互設計的統一認知，最後形成產品開發和視覺設計標準，可以說交互 設計方案的落地是整個產品雛形的最重要一環。
第二：交互設計評審中需要主要的點
評審會上，交互設計師是召集者也是主講者，是整個會議的牽頭人，所有的人都是聽從交互設計師的思路輸出從而對你的方案進行討論。
沒有經驗的交互設計師往往在評審的時候會被問的啞口無言不知道如何回答，這在會議上就尷尬了，個人認為在評審的時候我們需要做到以下的幾點，基本上就 能夠避免這種情況的發生。
1.會議前訂好會議室郵件通知，做好時間和地點的會議邀請，並把要評審的內容髮出來
作為會議的主導者提前訂好會議室定好時間是最基本的要求，做好會議邀請防止人員遺漏。 最重要的是要將評審的內容通過附件發出來，讓大家有一個大概的了解，這樣的話就會減少評審所浪費的時間。
樓主在每一次評審前都會拉著產品經理私下討論一遍，我們實現的是產品經理的需求，得到產品經理的認同是很重要的一環，所以說正式評審前，產品經理的確認是很重要的 。
2.保證交互設計說明書的完整性，包括流程圖和各個頁面的佈局說明
交互評審評審的就是你的設計方案，如何讓參會人員快速的了解你的設計意圖和產品功能是很重要的，所以在交互設計評審前我一般都會帶上需求文檔，在評審會議前簡單介紹 整個產品的流程，同時在評審某些界面的時候我會說明這些界面是要滿足什麼樣產品的功能。
另外，在評審之前交互設計師必須要考慮到所有的邏輯和細節，準備好數據和事實說明這樣就能夠保證你的方案更具有說服力。
當然一個產品功能的解決方案會有很多，每個參會人員都會有不同的解決方案，對於核心功能和頁面，樓主一般都會出兩套解決方案，提供方案讓大家去選擇總比大家發散想方案 好。
3.提前分好主次，將大部分的精力都放在主要功能和界面的講解上
會議時間是有限的，作為會議的主導者我們還是要把大的精力放在主要功能的介紹上，不要東說一點西說一點，保證自己的邏輯有主次才能保證聽會人員不會混亂。
4.反複檢查評審文檔，做到不出現低級錯誤和遺漏
低級錯誤很多，文字的錯別字在評審的時候肯定會被發現，例如登錄／登陸／賬戶／帳戶這些低級錯誤都會拉低你的專業性。
最重要的是要做到不遺漏，例如某個需求點忘記了進行設計，某些異常情況沒有涉及到／空頁面狀態忘記等這些都是要命的東西，產品可能只關心產品功能的實現，但是 測試人員每個點都是要測試的，測試包括太多的狀態。 所以說交互設計去研究測試人員的測試用例我覺得是很有必要的，你要搞清楚測試人員要比你想的多得多。
還有一種方案，建立交互設計自查表格也是防止遺漏的好方案： 如何建立交互設計自查表
5.把控主要方向，擱置爭議
時刻要記住會議是交互評審，不是技術評審也不是需求評審。 往往在交互評審會議上產品和技術討論起了技術實現的問題，這時候你就要及時的把他們給拉回來，防止出現思維發散。 對於大家都有爭議的點，完全可以先擱置爭議不在會上討論，會下思考方案後在進行召集談論。
最好會議記錄和討論結果和爭議點，最後發出根據會議討論的修改結果，讓大家進行確認，做到整個會議的閉環。
以上的幾點簡直是樓主血淚史所總結出來的經驗，目前在交互設計評審上樓主已經游刃有餘，不見得自己的方案是最好的方案，當時給大家講清楚自己的方式就是一個技術活了。
本文由 @張小明明 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議