你所需要知道的關於 UI 檢討會議上的事

UI 設計師經過了多次的努力與前端工程師完成了初步的畫面切版，成品總算成功進入會議討論階段，但是你會發現，往往這又是一個辛苦階段的開始，因為不論是主管、行銷單位、業務單位、甚至連你的測試人員，往往都會提出些對畫面上「指指點點」的建議...

在會議上，你應該知道幾件事情：

• 請開會前將你的 設計依據 /設計方案 的說明文件準備好，這是說服參加會議者的第一步
• 請透過剛剛提到的兩個基礎文件，來支撐設計結果的主力，有個小秘訣，就是你可以利用較高知名度的競爭品來襯托你的設計依據，往往可以提高說服力，有了說服性的前文之後，要敘述你的設計內容時就會稍稍輕鬆些
• 設計內容說明時，你過程中經歷了多少需求分析 、設計思考草圖、與工程師來來回回的所有過程，請選擇重點與篩選出有代表性的設計圖給大家了解， 讓所有參與者都能了解並產生共識，但是記得要適量，一般來說，主要只展示導致設計稿有產生分支版本的畫面就好，太細太多大家不僅不想看，也會感覺是設計師在找藉口...
• 要避免會議上有人提出 ：「當初為何不....」這樣的言論，請設計師在思考過程中最好將大部分的可能性都想過一次！
• 參加會議的人，都很直觀的反映出你畫面設計上有哪些優點跟缺點的地方，但是他們心中也會呈現出他們經驗中「較好的使用經驗」的印象，所以，有時候提出的建議往往都是「好的建議」事項，雖然設計師當下或許不好受，但是記錄下來，會議後調整，往往可以獲得較好的設計成果！
• 當然，如果你跟開會者有不同的理解方向，請提出對應的「分析背景說明」與「專案背景說明」來支撐你的想法，因為光靠視覺效果要來說服其他人，恐怕會比較辛苦些...
• 如果已經進行過「使用者測試」初步階段的，可以提出「使用者行為調查」的分析資料，依據分析的分眾類別逐一說明。不過這階段我經驗也不多，畢竟在國外大型專案比較有機會接觸到這一塊，台灣廠商這部份大多是委外或是直接跳過的機會很高！並且注意，在成果上線前的 A/B TEST與 可用性測試，並且要及時進行用戶回饋與使用狀況分析
• 在會議上你可以再次提出「競品分析」「設計目標說明」的初步討論結果，幫自己的設計稿檢討範圍設下範圍，避免會議上過度氾濫的意見討論，展示設計說明方案後再引導到設計上的相關討論
• 討論中不用太在意主觀的回饋內容，只需要專注在明確且有思考的議題上 （客觀且明確的討論，不用迎合所有人的喜好）
• 最後就是堅守設計的創意：「在確保可用的前提下尋求更好的表現方式,」， 使用創意遵守規則與設計需求，但又不會受規則約束 （創新的本質）

不過，心平氣和的討論是相當重要的，不論會議上大家提出的建議是好是壞，重點是獲取必要的「共識」，因為一個畫面的好壞，往往是軟體呈現在用戶前最快被判定的結果，簡單的說，UI 設計工作就是整體團隊成果的門面，一個不恰當的 UI 設計，不論是東西如何被堆廣、工程師如何優化順暢度，一旦用起來不順手，軟體被批判很糟的機會就是比其他競爭產品高很多...

不管過去我經手過的網頁設計、APP、遊戲畫面等，這些畫面的 UI 往往都直接影響了使用者的感受，導致第一時間體驗軟體成果時的成敗關鍵，不論內容的好壞，從第一個畫面的互動體驗開始，使用者可以馬上感受到當初開發團隊投入了多少心血在這個成果上，但是這就是很多中小企業的軟體，往往很難提升軟體品質的主要原因，因為提供給 UI 設計的時間與資源相對是少了些...。上面提到的地方，希望對於大家有些幫助，有任何意見也歡迎回覆給我。