強調再強調,一定要先看過 Guideline 後再來做介面設計,卻被人嗤之以鼻,說不用看一樣可以產出啊幹嘛要花這種時間。

  1. 如果不是你的產品太簡單、就是都用內建元素或抄襲湊合了事。
  2. 你同事人太好,幫忙擦屁股了。
  3. 你同事程度跟你一樣,搞不清楚狀況。

別說很多 UI 高手們也老是跳脫 Guideline 設計啊,他們哪位不是對 Guideline 熟到可以朗朗上口到幾乎可以報頁碼的?不懂 Guideline 的就只能當美工用,連視覺設計都稱不上。

易用性

人家說情、理、法,法律是道德的最後底限,只要依法行事、頂多被嫌冷血,道德上仍然站得住腳。我認為 Guideline 也一樣,最優良的介面設計會顧及到使用者的情感、次一點的會用理論(或數據)去實證易用性,最後才是 Guideline,它是介面設計的最後底限。基本照 Guideline 設計,就算長得醜也不至於很難用。十大易用性原則中至少就有 3 點和 Guideline 有關。

一致性和標準 Consistency and standards

使用者不應該猜測不同的字彙、狀態、動作是不是代表同一件事。

比如使用者已經習慣用手指點擊 Table View 進入下一頁,在 List 上左右滑動會出現刪除控件,就別把使用滑鼠的習慣硬套到手持裝置上,像是點一下是選中、快速連點兩下是開啟某項程式…包準沒人搞得懂這款 App 要怎麼操作。

Interactivity and Feedback

預防錯誤 Error prevention

比起提供使用者明確易懂的錯誤訊息,更重要的是如何防止使用者發生錯誤。

防止錯誤有很大一部份可以靠照「使用者的習性做設計」來迴避。Guideline 就是個系統性、有條理、已經整理好的「使用者習性」。試想使用者老是按錯,會覺得是自己的操作問題還是這個 App 有問題?老是讓自己操作不順的 App 是否會降低信賴感?

辨識而非記憶 Recognition rather than recall

盡量減少使用者需要記憶的事情、行動以及可見的選項。

繼承上一點,如果非得要使用這個 App 操作不可,是否就得記住這個 App 特別(難用)的地方?大部份的情況下讓人有感的介面通常不會是個好介面,使用者在流暢操作下的介面往往一點感覺也沒有,等到卡住或不知怎麼使用時、介面易用性的問題就會冒出來。所以我一直覺得易用性跟保險套之間有很大的共通點:越無感越好。雖不至於一有狀況就是鬧出人命,但對介面有感通常常是易用性問題大條了的時候…

確保團隊合作順利

扣掉校長兼掃地撞鐘那樣子的分工,一個專案最最少也會有 PM、UI/UX、RD 三個人,表示一個專案會被切成三人份、各自有各自負責處理的專長範圍,必須討論溝通交流結合三人之力才能完成這份專案。只要是溝通就一定會有誤差,這個誤差就是成本,無論是時間或是人力。

統一口徑是很重要的事,Guideline 能確保你們談論的是同一件事。

PM:「這裡可以加一下點點點嗎?」
UI:「什麼點點點?更多的那個點點點?」
PM:「就是會放在圖片下面那個點點點。」
RD:「拜託那個是 Page Control 好不好…」

每次聽到這種對話,我想到 PowerPoint「強而有力的一個小點兒」,乾脆把 Page Control 叫「強而有力的三個小點兒」算了。

RD 的時程通常是被壓縮得最慘、突發狀況和意外以及客戶亂加功能下最可憐的犧牲品,包含和搞不清楚狀況的 UI 合作都會成為他們內心的痛。

RD:「這三小?131x245 尺寸的 @2x.png?你出 1x 檔給我看看啊!」
(圖片尺寸沒有 0.5px 的,退件重做!)

RD:「App Store 上架要用的 icon 最好有 112px 這種尺寸啦!」
(退件重做!)

RD:「Navigation Bar 高度哪來 100px?」
(退件重做!)

PM:「大爺您別玩啦,時程來不及了…」
UI:「是 RD 看我不順眼一直退我件啊!」
iOS RD:「給這垃圾我是可以用喔?」

Android RD:「你圖忘了點 9-patch 了。」
UI:「9-patch?那是什麼?可以吃嗎?」
Android RD:「…把圖切好給我就好,剩下我自己處理。」

以上還是真人真事,一個專案結束換下一個…新 UI 補進來接手,繼續輪迴無限退件地獄。搞的 RD 人人自危,急著學 Photoshop 怎麼修圖。

建立 Guideline

剛剛提到的都只是「跟隨」一份現有的 Guideline,公司若開發自有產品,就會需要自己的 Guideline。什麼色碼、尺寸、字體字級、間距…這都還可以算是 VI 的範圍。如果加上「策略」面的話…好吧先不提這麼抽象的,來講講為什麼要建立 Guideline 好了。

它能確保不管是誰接手都能有相同的產出,而不至於換個人處理就換了個長相。

也可以把它當成系統規格書、屬於文件的一種,條列式分章節,明確告訴你什麼可以做、什麼不能做、某種特定情況下該怎麼處理。書諸圖文要學習要教育總是比較省成本、上手快。不能老靠師徒純粹口耳相傳吧?萬一中途有人離職或出意外怎麼了,這門技藝不就失傳?

「你為什麼要這樣做?有什麼理由嗎?」
「我不知道耶,就、前面的人這樣做啊。」

恭喜你又跳入一個坑裡,這真是個仰頭無語問蒼天的好時機。

補充說明:讓大家好做事

通常 Guideline 裡有的,就表示 RD 有內建元素可以套,不用自己硬刻,就算拿別人寫好的套件模組、也是要修改一下才能用,多少會有 bug 。用內建的原生控件製作的 App 通常 Bug 會比較少,不只 PM 溝通方便、UI製作快速、RD Code 也好寫、QA 測試時 Bug 少他也省事。所以 Guideline 重不重要?當然重要啊!人力就是成本、時間就是金錢,UX 沒做好會扯多少人下水、多耗多少成本、多燒多少錢啊~

comments powered by Disqus