軟體開發見聞錄#6:使用者體驗的設計原則/葉光釗

「體驗設計」這門學問,現在已經成了軟體設計的顯學,其中包含了不同的面向:流程設計、技術架構設計、使用者介面設計等等。在大家還沒有開始重視使用體驗的時代,許多事情只能從嘗試和錯誤中去學習,包括開發團隊也一樣。

針對跟使用者相關的設計觀念,在微軟的發展進程中,可不是一步就走到目前的成績的;曾經有一段很長的時間,還受到了很多批評。

就我自己經驗的瞭解,倒不是微軟以前不重視、或是不投資源,而是早期設計的著重點太過偏向「介面和展示」(user interface and representation)等等看得到的東西,而並沒有注意到背後其實有更深一層的原則。

從「介面」轉變成「體驗設計」觀念的轉捩點,是PM大神:Steven Sinofsky接手Windows 7的開發時,決定做一些根本的改變:他成立了獨立的使用者體驗與設計部門(這以往多半是PM兼任的工作),並且在開發流程中把必要的程序也加進去。

這個策略後來的影響很大:現在所有的產品組都跟進了這種開發模式,不像早期只有遊戲、或是硬體部門才有少數的設計資源。

在這些改變當中,最最重要的,是確立了一個基礎:開發啟動之前,團隊必須先訂定使用者體驗設計原則(Design Principles)。它的作用跟之前所提到的「端到端用戶體驗」很像,是用來協調跨領域設計上的協作。

Windows 7是第一個把這些原則白紙黑字寫下來的產品(微軟還保留了在PDC上的發表,請參閱前面的影片);這裡就容我自作主張,做一些介紹跟解釋:

  • Reduce concepts to increase confidence(少講概念,增加信心)

    盡量集中功能的進入點,增加使用者對功能的掌握程度。

  • Small things matter, good and bad(無論好壞,細節都很重要):

    細節的設計不能馬虎,因為這會影響整體的成敗。

  • Solve distractions, not discoverability(減少用戶分心,而非吸引用戶注意):

    重點是讓使用者一眼就知道如何使用功能,而非一昧增加功能的曝光度。

  • Time matters: build for people on the go(時間也很重要,要設計得讓忙的人也好用):

    如果確知使用者會在移動的環境中使用某個功能,盡可能減少操作的步驟及時間就是重點。

  • Value the full lifecycle of the experience(重視從頭到尾的整體體驗):

    不要只看片面的操作方便,要把整體經驗包含從「安裝」到「解除安裝」一起考慮進來。

  • Be great at look and do(看起來和用起來都好):

    軟題的視覺畫面必須和操作盡可能一致、而且要直覺。

由於篇幅的關係,可惜沒辦法舉實際的例子做仔細地說明,希望之後有機會能持續介紹和說明;另外,蠻建議大家花點時間看看前面提到的PDC影片,很精彩。

當然,微軟並不是從此在設計上就一帆風順,之後還是一路崎嶇坎坷(Windows 8 就又跌了一跤)。

但無論如何,沒有這個重要的基礎,就沒辦法持續累積能量和成果,進一步超越對手。筆者雖然已經離開,但看到前一陣子微軟交出的成績單,感覺還是蠻驕傲的。

使用者體驗設計實例:輸入法

最近有朋友反映,後來的幾篇理論講述偏多,有點偏離見聞錄的精神。想想是有道理,這裡就來用一個例子,來說明之前談的使用者體驗設計,是幾乎每個人都用到的輸入法。

先自首:講到輸入法,估計每個人都有一肚子怨氣。不過老實說,也許是自私的觀點,我並不覺得微軟的開發不夠用心、或是資源不夠,而是它有兩個超級門檻:

  1. 只要它的準確度做不到100%,就是0%;

  2. 使用者操作的習慣性超級高,只要稍微有一點點更動調整,不但馬上被發現,而且通常都會有負面反應。

第二點尤其麻煩,這表示要在輸入法的操作做上大刀闊斧的改變,等同於是不可能的任務。

這裡並不打算將所有輸入法的血淚史全寫出來,這樣可能二十篇都寫不夠,而且會牽涉到微軟的研發機密;所以,我打算講一個還算成功的體驗設計變動。

早期的輸入法,為了順應多數人看ㄅㄆㄇ符號的習慣,在組字的時候,ㄅㄆㄇ符號是垂直顯示在另一個長方形的小框框裡,並且會隨著游標變換位置。

這種模式我們內部稱為「near caret」模式。當初這樣設計有兩個目的:

  1. 比較接近看ㄅㄆㄇ的習慣;

  2. 在組字的時候,已經輸入的文字位置不會動來動去。

可是相對在工程上的缺點是,如果應用程式所傳的座標有問題,這個小方框就會亂跳。這個問題困擾了產品組很久,因為沒有一勞永逸的方案;只要有新產品,這裡的寫碼跟測試功夫都要重來一次。

另外,就算我們把所有微軟的產品都搞定了,永遠會有不按規則來的第三方app會出問題;而對終端用戶來說,這肯定是微軟輸入法的問題。

所以內部一直都在討論要改成「at caret」模式,就是把ㄅㄆㄇ符號顯示在游標當中。這樣的話,不但沒有方框亂跳的問題,而且由於處理方式就跟其他亞洲語言如日語、韓語、簡體中文輸入一樣,測試功夫可以大幅減少跟簡化。

但就是改變太大了,尤其是上面提的第二個目的:一方面擔心使用者會分不清組字中、以及組字完成的文字,而且在極端的情況中,會讓長篇文字來來去去做劇烈的位置變化,所以遲遲沒有下這決定。

最後,欠的債還是要還、該改的還是要改;所以我們在一次輸入法重要改版的時候下了這個決定,當時我們等於把大部分資源都賭在這個改動上。程式碼的改動其實並不多,主要都是設計更動的準備和驗證功夫;綜合來說,大概是以下的步驟:

  • 第一步:先做一個原型。

  • 第二步:由設計工程師與體驗工程師驗證是否符合大部分的設計原則。其實中間有不少工程師之間反覆討論「哪個設計比較好」的互動。

  • 第三步:進行適用度測試(usability study and testing),招募十幾位終端用戶實際使用,由體驗工程師驗證使用者的反應是否符合我們的預期。

  • 第四步:檢驗目前手中有的遙測資料是否也符合新的使用模型。

當時由於台灣沒有體驗工程師,為此還特別從日本請來一位專家。在一連串討論之後,產品組發覺焦點在於「使用者輸入的文字長度」;經過一連串實地測試,觀察到大部分使用者以花在網頁上的時間居多、輸入的也都是短片語。

最後,我們整理了所能搜集到的段落長度,發現約略都在在150-200個中文字之間,所以視覺反應並沒有想像中的劇烈。最後產品組成員一致決定改動就緒,新設計就這樣定稿出門了。

現在,應該多數使用者都已經適應、並且持續使用新的設計。對產品組而言,最好的消息就是「沒有消息」;經過這一次,我們才真正學到好的設計的精髓、以及應該付出的代價。