使用者體驗設計實例

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

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

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

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

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

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

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

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

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

results matching ""

    No results matching ""