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

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

葉光釗 - 吐納商業評論 | Tuna Business Review

曾任台灣微軟研究開發部副總經理、公共事業群技術長，是 IT 業界經歷長達二十年的老兵。對微軟全球技術的開發實務有深入了解，並有獨到見解。. "葉光釗" is published by 吐納商業評論 in 吐納商業評論 | Tuna Business Review

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

就我自己經驗的瞭解，倒不是微軟以前不重視、或是不投資源，而是早期設計的著重點太過偏向「介面和展示」（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個中文字之間，所以視覺反應並沒有想像中的劇烈。最後產品組成員一致決定改動就緒，新設計就這樣定稿出門了。

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