18 November 2007

這是 usability 基本心得... 給我們 team 的成員,也和大家分享...

原則一:思考服務的對象

首先要先了解你的用戶是哪一種類型:若按用戶功力可分為 end user 和 power user。若按網頁使用頻率來分,可分為例行性作業和一次性作業。用例子說明好了,比方說大家熟悉的購物網站,包含產品瀏覽、購物車、下單等等功能。首先,這類網站的使用者功力大多屬於 end user,因此介面上越簡單越好 (即使你有很好的創意,也要小心發揮,因為 end user 可能會看不懂你新穎的介面)。若從使用頻率來看,產品瀏覽屬於例行性作業,下單則屬於一次性作業 (因為久久才下單一次)。因此產品瀏覽的網頁不能拖泥帶水,步驟要越少越好,不然用戶逛了老半天找不到想買的東西就跑掉了。另一方面,下單的網頁到是不怕步驟多,就怕使用者不會用,或是抗拒使用 (要付錢的地方總是會小心翼翼的)。所以一般下單都會設計成 wizard 的方式,一步一步導引使用者完成下單。

那如果是購物網站的後台呢?後台的使用者屬於 power user (可能一開始就是,或是之後會被訓練)。他每天的工作就是產品上架,處理訂單...等等例行性的作業。這樣的網頁以快速為最優先考量:可以運用 減少 popup、不用 wizard、多功能客製化元件、一頁內放多一點資訊、增設 hotkey... 等等技巧。總之讓用戶可以在最少的點擊、最少的思考完成他的工作就是了。

購物網站是大家熟悉的例子,大家都見多了。但是如果換個 domain 就要多花心思去了解了。比方說我的工作是服務醫院醫學相關的研究,涉及到的人員有護士、醫生、研究員、實驗室、計畫負責人...等等。服務內容則有病人收樣管理、實驗管理、秏材進銷存、問卷調查...等等。遇到這類不熟悉的 domain 時,記得談需求時要多尋問:分辨他在這個功能上屬於 end user 還是 power user?他多久用一次這個功能?每天用還是一個月用一次?先替這些用戶簡單歸個類,大方向捉對了,未來做出的網站用戶用的就順手。

原則二:第一頁要放用戶最想做,最常做的事

這個原則乍聽之下很自然、也很直覺... 但我們 team 的大多數成員 (包含我自己) 就是沒有辦法做到這一點。我們的專案多屬內部使用, 而開發部門並沒有設立專人設計網頁,所以從網頁設計到後端資料全都工程師自己來。工程師拿到案子,頭腦就開始直覺思考後端流程怎麼設計,然後由後端往前端推,網頁的流程就會和後端呈現一比一的關係。比方說要做一個管理稽核案的功能,有新增修改查詢等等功能。依典型的工程師思維,第一頁就做了個查詢案子的表單和新增案子的連結,下了查詢條件後再列出相關案子的網頁。這種 "第一頁" 也不能說工程師沒按需求來做... 只是剛進去時除了表單,就是一片空白,什麼都沒有。使用者一進來就得去想、得去回憶要下什麼查詢條件,才能找到他要的東西。這樣還真有點難用...

要提升 usability,就是去思考用戶最想做或是最常做的事,比方說,第一頁除了查詢表單之外,還列出他最近處理過的10個案子;或者,用戶比較關心那些稽核不過的案子,那一開始就先列出這些有問題的案子;或者,可以提供查詢條件 history 的功能,讓用戶可以調出最近下的查詢條件... 等等。決定要做那方面的事,要透過談需求時了解。而且,要注意很少有使用者會自覺得想到這一塊,必需由開發者主動尋問和了解使用者的作業才行。

原則三:重要的內容放在 1024x768 內

這個原則很基本,許多人都了解 (還不知道的人要打屁屁!)。問題是出在難遵守.... 開發人員通常都用很大的營幕、開高解析度、然後字型用的小小的,希望一次看多點資訊,方便開發。這樣的習慣長期下來,一不小心就會發生設計的網頁常常需要 scroll (甚至是左右 scroll)。除非你的網頁是設計給 power user,而且是配備比較好的營幕。不然開發時建議固定開個 1024x748 的 browser 來檢視網頁的呈現,比較符合一般使用者的畫面大小。(安裝 firefox 的 web developer plugin,然後大小設 1024x748 (不是 768,因為要扣掉 toobar和 menu 的高度)) 瀏覽器的大小有了,接下來就是將重要的內容、用戶最關心的事情,盡量放在網頁上半段,一般來說,左上角是人瀏覽的起點,從那裡開始最好。目的就是讓用戶最少的力氣找到他要的東西,而不是 scroll 老半天才看的到。

原則四:改變資料狀態用按鈕,瀏覽資料用連結

當你做的功能是 改變資料狀態時,網頁上要用按鈕來呈現。如果是資料間瀏覽,則用連結來呈現。什麼是改變資料狀態?比方說刪除資料、送出表單、移動位置、切換...等等功能。這些功能用按鈕比較洽當,因為按鈕有 "動作" 的感覺 (按下後再彈上)、有視覺上的 feedback。當然在 ajax 的風潮之下,按鈕漸漸越用越少了,不少地方開始用連結來替代。不過重點還是一樣,要有視覺上的 feedback,例如加些 animation, yellow fade out之類的都可以。

另一方面,瀏覽資料則一定是用連結,千萬不要用按鈕替代。這聽起來很白吃吧?但就是有新手會犯這種錯 (三年前我自個兒也常犯...)

原則五:慎防預覽頁面

當設計多步驟網頁時,例如結帳的功能,中間多半會夾一個預覽的頁面。預覽的網頁原本是好意,讓使用者可以再完成前,再確認、考慮一番。但偏偏很多用戶會把他當做 "已完成" 的網頁,造成常會有客戶來電,抱怨明明已經完成了,卻沒成交。為避免這類常犯的錯誤,建議預覽的畫面正上方要加上大剌剌的 "完成按鈕" (可用顏色/大小/字型來醒目) 提醒使用者,要按了才會生效。如果版面許可,可以再加上 process train (另一說法是 process funnel) 就是常見的按順序導引:(1) -> (2) -> (3) -> done,這樣就更穩了。現在 Ajax 技術發達,也可以考慮用 "即時預覽" 取代掉舊的換頁預覽,這樣既方便又不會出錯。

最後,我們來看一個客製元件提升 usability 的實際例子

需求:用戶需替病人的樣本做稽核 (有無漏收或誤收),一個稽核案約含 100 個病人。每個病人的稽核狀態分別為 未稽核、已稽核、稽核不過。

用戶 profile:用戶為稽核員,是內部的使用者,可以被訓練。因此屬 power user

使用頻率:約每週使用,一次約稽核數十人,屬例行性作業。

按上面的需求,如果用傳統的 html 元件設計,我們會得到:

上圖用表格的方式呈現 100 個病人資料。而最右邊稽核的狀態則採下拉式選單表示 (當然這裡也能用 Radio Button,但是三個選項會太寬,版面擠不下)。在下拉式選單中挑選欲變更的狀態時,背後會用 ajax 的方式直接更新後端的資料。一般來說寫到這樣已經算很方便了,最少用戶不用為了切換狀態而 submit 一個個的 html form。

雖然不錯,但是還有兩個缺點:第一,每次切換下拉式選單都需要兩次的 click。第二,當 100 個 病人直直排下來,狀態用文字表示時,要分辨出 未稽核、已稽核 等狀態其實還蠻花的。

由於稽核員屬 power user,因此我們不一定要使用簡單的 html 基本元件,我們可以客製元件:

上圖稽核的狀態改用兩個圖示表示,兩個都是灰的表示尚未稽核,綠色表示已稽核,紅色則表示稽核不過。這樣一來,即使 table 上排滿滿了 100 個病人,也可以很快看出哪些病人還沒稽核,哪些是稽核有問題的。要切換狀態,只要在欲切換的圖示上點擊一次就行了 (有點類似常見的評比星星),而背後也是直接用 ajax 更新後端的資料。

當然,這樣的元件用戶第一次看到會傻眼... 無從下手,不過只要稍微 demo 一下,之後作業就很順暢囉。

至於要製作這樣的客製元件... 呃... 要看各位用什麼技術寫了... 用 Wicket 的話,一個幾十行的 .java 就搞定了,也不用寫什麼 javascript 或是 xml。其他的技術就得慢慢磨了吧... 採用容易寫客製元件的 framework 真的好處很多,寫元件不僅快又簡單,也讓你有更多的時間和精力花在構思更好的 usability 上。


回響

可以用 Tag <I>、<B>,程式碼請用 <PRE>