提高UI設計專案的效率:觀念與溝通

編按:本文由作者授權,經本站編輯後刊出,原文刊登於此

很多人總覺得設計師擁有最多的時間,但設計師本人卻反而覺得自己擁有的時間最少。

在我所開的設計課裡,常有同學詢問該如何提高專案中的設計速度;而除了目前和我一起工作的團隊外,筆者前陣子也在其他公司協助設計師訓練;我發現大家幾乎都有速度慢的問題。

如何提高設計的速度效率?在此分享一些我觀察到的常見問題和改善方式。當然,要注意的地方很多,本文著重在觀念和溝通,列出幾項設計師應該要注意的重點。

了解工程實作的基本原理

(業界NG率:接近 100%)

許多人認為創造力和邏輯是左右腦分開管轄的,設計師和工程師使用的是不同部分的能力;所以大家各安其分,做好自己的工作就好:我負責光鮮亮麗地畫圖,工程師就負責用超大聲的「同刻鍵盤」[footnote]一種刻意將按鍵上的印刷文字做得和底色很接近的鍵盤,有一批愛好者。[/footnote],在黑色的螢幕上編寫外星文。

事實上,這種刻板印象不但不見得正確,而且除了阻礙你進步以外,可說一點用都沒有。

大家幾乎都聽過巴別塔的故事。造成溝通問題的原因很簡單:就是講不同的「語言」,而非思考方式不一樣。所以如果設計師懂工程實作原理,就能大幅減少與工程師的溝通障礙,能讓整個專案推動更加順暢。

至於設計師該懂哪些部分?很簡單,你不需要學會怎麼寫code,但你至少需要懂得:

正確稱呼UI元件

以iOS為例子,在Apple介面設計規範文件裡,每個畫面構成的元件都有正式的名稱,例如:

1*7Z9YUnMsRXUPc-wPgKjSsw

這個玩意兒叫做「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%)

綜合之前和一些公司合作的過程,以及和朋友交換的意見,筆者發現許多團隊都會在設計流程上草率帶過,這看來省下一些時間,但對後續的專案開發會有不利的影響。

一般來說我會建議中小型專案採取以下流程來執行設計:

1*b6lT1jb0yDWqatohWSUBxg

這個流程是容許微調的。我在Yahoo實習時常看到非常大型的設計流程,小團隊工作時,則多會採取上述較簡易的版本。

要如何微調呢?不要省略其中的步驟,但在上面綠色箭頭處可以減少迭代(Iterate)的次數,把時間省下來;這樣就會考驗到產品設計師、PM的經驗和gut feeling了。

有些講得一口好設計的人會不食人間煙火,一味地宣導要從使用者調查研究(User Research)、Persona開始做起,然後實作出許多個原型(Prototype)才開始讓開發者動手,後續再做數據分析等工作。

但實務上,小型專案花太多心力去做這些事,基本上就是缺乏成本效益概念,在使用者數量達到一定門檻前,能用來進行數據分析的母體小得可憐,並無統計的參考價值。因此,小型專案其實可以將功能拆分Release,先做出來,再觀察使用情形並修正細節。這樣雖然有一點危險,但和專案永無結束之日的慘狀相比,還是比較安全。

關於拆分Release,朋友阿川寫了篇不錯的文章,值得參考。

先以原生UI元件表意

(業界NG率:80%)

在設計wireframe的階段,主要目標是讓大家對於畫面上「有哪些物件」取得共識,而不是這些物件「該長什麼樣子」;那是mockup階段才要注重的。因此將wireframe畫得過於精美,是一件非常奇怪的事情,例如這樣:

來源:ui8.net

來源:ui8.net

如果把wireframe畫得如此精美,馬上就有三個苦果:

  1. 浪費時間,徹底的浪費時間。

  2. 有彩色稿的外型構造,卻沒彩色稿的色彩系統輔佐,導致大家無法完整理解你「精心設計」的UI物件。

  3. 對設計沒概念的客戶、PM 或老闆,看到這樣的草稿,會忘記我們是在review畫面上有哪些物件,反而開始跟你檢討設計細節。常見的悲劇就等你真正開始做彩色稿時,他們才突然回神,告訴你之前有哪個功能忘記擺放上去。

其中第二點是本節的重點,在你的 wireframe 裡,應該使用系統原生的物件來構成畫面,例如:

上面是我製作的 Sketch UI 套件,可參考《如何使用iOS 10 UI Kit》一文。

上面是我製作的 Sketch UI 套件,可參考《如何使用iOS 10 UI Kit》一文。

請避免在非必要的狀況下,急著在wireframe裡畫一些從來沒有人看過的「創新 UI」。一個容易理解、直覺的設計,必須是所有細節相輔相成的;由於wireframe缺少顏色和動態效果,所以更不該冒險呈現特殊的物件外型。

也就是說,你的wireframe頂多做到這樣就該收手:

1*TjbqqWPAqcvIBJ9yme5M_g

這樣的Wireframe,畫面上都是常見的App元件形式。大家看得懂畫面,就能專心探討畫面上的功能是否是產品所需。

少用代名詞

(業界NG率:60%)

要做到這個溝通技巧並不困難,但如果沒有人指出來,是很難自己發現這個毛病。

一件事情若要精確表達,就應該儘量減少語句中的「詮釋空間」。代名詞非常容易造成設計討論上的時間浪費,例如「這個」、「那個」之類的詞彙,在專業討論上應該減少使用。你應該使用本篇文章第一節所提到的精確名詞來表述,或是詳細描述你所指的外型。

好了,如果你是設計師,希望這篇文章能夠幫助你在設計的溝通討論上更加順暢、省時;如果你是 PM 或開發者,也可以順便學習、或將這篇文章轉給你的設計師參考。

也歡迎大家參考筆者的UX/UI 設計教學課程:課程網站FB上的最新課程訊息