使用者體驗設計實例

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

先自首：講到輸入法，估計每個人都有一肚子怨氣。不過老實說，也許是自私的觀點，我並不覺得 M 社的開發不夠用心或是資源不夠，而是它有兩個超級門檻：第一｀只要它的準確度做不到100%，就是 0%；第二｀使用者操作的習慣性超級高，稍微一點點更動調整，不但馬上被發現，而且通常都會有負面反應。第二點尤其麻煩，這表示要在輸入法的操作做上大刀闊斧的改變·等同於 misson impossible。

這裡並不打算將所有輸入法的血淚史全寫出來，這樣可能二十個章節都寫不夠，而且會牽涉到 M 社的研發機密。我打算說明一下其中一個還算成功的體驗設計變動。

早期的輸入法，為了順應多數人看ㄅㄆㄇ符號的習慣，在組字的時候，ㄅㄆㄇ符號是垂直顯示在另一個長方形的小框框裡，它會隨著游標變換位置。這種模式我們內部稱為 near caret 模式，當初這樣設計有兩個目的：一是比較接近看ㄅㄆㄇ的習慣，二是在組字的時候已經輸入的文字位置不會動來動去。可是相對在工程上的缺點是，如果應用程式所傳的座標有問題，這個小方匡就會亂跳。這個問題困擾產品組很久，因為沒有一勞永逸地方案，只要有新產品，這裡的寫碼跟測試功夫都要重來一次；另外，就算我們把所有M社的產品都搞定了，永遠會有第三方沒有按規則來的app會出問題；對終端用戶來說，這肯定是輸入法的問題。

所以內部一直都在討論要改成 at caret 模式，就是把ㄅㄆㄇ符號顯示在游標當中，這樣的話不但沒有方匡亂跳的問題，由於處理方式就跟其他亞洲語言如日語｀韓語及簡體輸入一樣，測試功夫可以大幅減少跟簡化。但是就是改變太大了，尤其是上面提的第二個目的，一方面擔心使用者會分不清組字中以及組字完成的文字，而且在極端的情況中話讓長篇文字來來去去做劇烈的位置變化，所以遲遲沒有下這決定。

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

• 第一步：先做一個 prototype。
• 第二步：由設計工程師與體驗工程師鑑驗是否符合大部分的設計原則。其中其實有一些互動，反覆討論比較好的設計。
• 第三步：進行使用度測試(usability study and testing)，招募十幾位終端用戶實際使用新的體驗，由體驗工程師來驗證使用者的反應是否符合我們的預期。
• 第四步：檢驗目前手中有的遙測資料是否也符合新的使用模型。

當時台灣沒有體驗工程師，為此還特別從日本請來一位專家。在一連串的討論之後，產品組發覺焦點在於使用者所輸入的文字長度，經過一連串的實地測試，觀察到大部分的使用者花在網頁上的時間居多數，輸入的也都是短片語。最後，我們去整理所能搜集到的段落長度，約略在150-200個中文字。視覺反應並沒有想像中的劇烈。最後產品組成員一致決定改動就緒，就這樣定稿出門了。

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