提高UI設計專案的效率：觀念與溝通
編按：本文由作者授權，經本站編輯後刊出，原文刊登於此。
很多人總覺得設計師擁有最多的時間，但設計師本人卻反而覺得自己擁有的時間最少。
在我所開的設計課裡，常有同學詢問該如何提高專案中的設計速度；而除了目前和我一起工作的團隊外，筆者前陣子也在其他公司協助設計師訓練；我發現大家幾乎都有速度慢的問題。
如何提高設計的速度效率？在此分享一些我觀察到的常見問題和改善方式。當然，要注意的地方很多，本文著重在觀念和溝通，列出幾項設計師應該要注意的重點。
了解工程實作的基本原理
（業界NG率：接近 100%）
許多人認為創造力和邏輯是左右腦分開管轄的，設計師和工程師使用的是不同部分的能力；所以大家各安其分，做好自己的工作就好：我負責光鮮亮麗地畫圖，工程師就負責用超大聲的「同刻鍵盤」[footnote]一種刻意將按鍵上的印刷文字做得和底色很接近的鍵盤，有一批愛好者。[/footnote]，在黑色的螢幕上編寫外星文。
事實上，這種刻板印象不但不見得正確，而且除了阻礙你進步以外，可說一點用都沒有。
大家幾乎都聽過巴別塔的故事。造成溝通問題的原因很簡單：就是講不同的「語言」，而非思考方式不一樣。所以如果設計師懂工程實作原理，就能大幅減少與工程師的溝通障礙，能讓整個專案推動更加順暢。
至於設計師該懂哪些部分？很簡單，你不需要學會怎麼寫code，但你至少需要懂得：
正確稱呼UI元件
以iOS為例子，在Apple介面設計規範文件裡，每個畫面構成的元件都有正式的名稱，例如：
這個玩意兒叫做「Segmented Controls」，而不是「那個長得像膠囊的選單」。如果能夠使用正確術語來溝通，將能夠省下非常可觀的解釋時間。
如果你想了解得更多、更精確，建議你將前述的規範文件讀熟以後，再繼續研究UIKit Catalog。
有些效果就是做不出來、很難做、不該做
舉個最普遍的例子。自從iOS 7引入模糊效果的設計語言後，大家似乎都染上了高斯模糊的癮；但這效果非常耗費系統資源，就連iOS自己也到隔年iOS 8發表後，才心不甘情不願地開放使用UIBlurEffect API，免得第三方App自己硬幹一堆模糊效果，拖累系統效能。而在 Android上，官方根本沒有提供像iOS如此方便的API可用。
上面那段聽起來像外星語？翻譯成白話就是：許多設計師對於某些視覺效果在工程實作面的可行性沒有概念，也沒有考量到各種裝置的運算負荷能力，盲目設計大量讓開發者面有難色的效果。好不容易做出來了，結果發現算圖卡頓到無法忍受，又得回頭改設計稿，一來一回，時間都浪費掉了。
再舉Status Bar的例子，我看過太多設計師為了設計感而給Status Bar著上前景色，讓它變灰甚至變成彩色。開發者有意見時，設計師又指責開發者連這麼簡單的事都辦不到，鬧得彼此都不開心。其實Apple在文件裡寫得很清楚：這個東西你就只有黑或白色可選，在Status Bar的顏色上動手動腳，就是不該做的效果。
如果你是就讀設計科系的大學生或研究生，我會建議你選修計算機概論、資料結構等基礎課程，這些都會對UI設計非常有幫助。
嚴謹執行設計流程
（業界NG率：90%）
綜合之前和一些公司合作的過程，以及和朋友交換的意見，筆者發現許多團隊都會在設計流程上草率帶過，這看來省下一些時間，但對後續的專案開發會有不利的影響。
一般來說我會建議中小型專案採取以下流程來執行設計：
這個流程是容許微調的。我在Yahoo實習時常看到非常大型的設計流程，小團隊工作時，則多會採取上述較簡易的版本。
要如何微調呢？不要省略其中的步驟，但在上面綠色箭頭處可以減少迭代（Iterate）的次數，把時間省下來；這樣就會考驗到產品設計師、PM的經驗和gut feeling了。
有些講得一口好設計的人會不食人間煙火，一味地宣導要從使用者調查研究（User Research）、Persona開始做起，然後實作出許多個原型（Prototype）才開始讓開發者動手，後續再做數據分析等工作。
但實務上，小型專案花太多心力去做這些事，基本上就是缺乏成本效益概念，在使用者數量達到一定門檻前，能用來進行數據分析的母體小得可憐，並無統計的參考價值。因此，小型專案其實可以將功能拆分Release，先做出來，再觀察使用情形並修正細節。這樣雖然有一點危險，但和專案永無結束之日的慘狀相比，還是比較安全。
關於拆分Release，朋友阿川寫了篇不錯的文章，值得參考。
先以原生UI元件表意
(業界NG率：80%)
在設計wireframe的階段，主要目標是讓大家對於畫面上「有哪些物件」取得共識，而不是這些物件「該長什麼樣子」；那是mockup階段才要注重的。因此將wireframe畫得過於精美，是一件非常奇怪的事情，例如這樣：
來源：ui8.net
如果把wireframe畫得如此精美，馬上就有三個苦果：
浪費時間，徹底的浪費時間。
有彩色稿的外型構造，卻沒彩色稿的色彩系統輔佐，導致大家無法完整理解你「精心設計」的UI物件。
對設計沒概念的客戶、PM 或老闆，看到這樣的草稿，會忘記我們是在review畫面上有哪些物件，反而開始跟你檢討設計細節。常見的悲劇就等你真正開始做彩色稿時，他們才突然回神，告訴你之前有哪個功能忘記擺放上去。
其中第二點是本節的重點，在你的 wireframe 裡，應該使用系統原生的物件來構成畫面，例如：
上面是我製作的 Sketch UI 套件，可參考《如何使用iOS 10 UI Kit》一文。
請避免在非必要的狀況下，急著在wireframe裡畫一些從來沒有人看過的「創新 UI」。一個容易理解、直覺的設計，必須是所有細節相輔相成的；由於wireframe缺少顏色和動態效果，所以更不該冒險呈現特殊的物件外型。
也就是說，你的wireframe頂多做到這樣就該收手：
這樣的Wireframe，畫面上都是常見的App元件形式。大家看得懂畫面，就能專心探討畫面上的功能是否是產品所需。
少用代名詞
(業界NG率：60%)
要做到這個溝通技巧並不困難，但如果沒有人指出來，是很難自己發現這個毛病。
一件事情若要精確表達，就應該儘量減少語句中的「詮釋空間」。代名詞非常容易造成設計討論上的時間浪費，例如「這個」、「那個」之類的詞彙，在專業討論上應該減少使用。你應該使用本篇文章第一節所提到的精確名詞來表述，或是詳細描述你所指的外型。
好了，如果你是設計師，希望這篇文章能夠幫助你在設計的溝通討論上更加順暢、省時；如果你是 PM 或開發者，也可以順便學習、或將這篇文章轉給你的設計師參考。
也歡迎大家參考筆者的UX/UI 設計教學課程：課程網站、FB上的最新課程訊息。