Gadget

目前仍無法透過加密連線存取這項內容。

Categories

工作態度 (1)    方法論 (5)    本土化 (9)    危機管理 (2)    死亡 (1)    自我成長 (1)    自我管理 (3)    決策管理 (1)    版本 (1)    社會 (2)    品管 (3)    風險管理 (1)    效能 問題 (1)    時間管理 (5)    專案 (10)    教育 (1)    產能 (1)    產業 (5)    軟體 (4)    測試 (10)    閒聊 (14)    溝通 (4)    道德 (1)    漫談 (23)    管理 (1)    機器翻譯 (1)    簡轉繁 (2)    翻譯 (8)    booksore (1)    Chinese (1)    Flash (1)    G11N (1)    I18N (3)    Industry (1)    L10N (8)    politics (1)    Project Management (6)    Revision (1)    Software (3)    Testing (4)    Time Management (1)    Translation (4)    UI Design (1)   

2010年10月20日

產品的易用性通常決定了他的成敗

一般來說,產品的易用性 (usability) 決定了他的成敗。排除特殊專門用途或是特殊冷門軟體不談,設計給一般廣大而普遍的使用者使用的軟體,如果在易用性上面表現不好,那麼這個軟體至少不會太成功。

程式設計師往往僅專注於達成軟體的功能設計需求,並確保該能運作正常,但多數的程式設計師往往不懂該產品。例如設計財會倉儲管理系統的程式設計師很少會懂財會或是倉儲,設計人事管理的設計師也不懂人事管理,因為這些領域往往過於專業,即使在團隊裡有系統設計師,有架構設計師,這兩個角色或多或少會在程式開發以及目標用戶之間扮演一些溝通的角色,但多半這兩個角色也不可能對軟體的目標領域有深入了解。

某一定程度的軟體的易用性,認真或是稍加投入的程式設計師還是可以達成一定程度的改善。舉例來說,當某個功能操作環節中有一個步驟要從清單中選取一個使用者自訂的項目類別,這個清單欄位被設計成10行高並且當選項超過10個時會出現垂直捲軸。稍加投入的設計師也許會發覺這個選項清單在多數的使用者一定時間的使用之後,選項多達百位數應該很常見,於是一定程度的增進快速選到想要的選項是必要的。例如在點選清單內任一選項後,快速輸入所想要選的選項值的前幾個字幕將會自動選取到符合的項目上,就類似檔案總管具備的特性那般。

然而,類似這種操作細節往往不會在功能設計需求上加以規範或多所著墨。系統設計師或是架構工程師往往也不管這些細節!如果不是開發團隊的主管乃至大老闆重視產品的易用性,有時即便某個程式設計師具有產品易用性的敏感度,大概也會因為專案時程的壓力而被迫妥協。

從另外的角度來看,程式開發團隊往往不容易發現產品的易用性相當糟糕。程式開發過程中,開發團隊確實會對程式進行單元測試與基本的功能整合測試,但多半是喂給程式很簡單的資料,或是經過特殊設計的資料,只為驗證經過程式運作後會得出預期的結果。例如錄製一個聲音檔,將這個聲音檔交給程式,程式自動將其轉檔成 MP3 格式,在轉檔前或是之後,為這 MP3 檔案加上標籤與自訂類別與評分,然後測試在播放界面打入類別字串,確認該檔案能被正確搜尋出來,然後結束。

很多時候產品易用性的意見反餽往往是品保測試部門提出較多,因為品保部門相較於開發部門而言較貼近使用者的角度,在產品測試時也較會由使用者的角度出發,來測試與驗證這個產品。如果測試時間充裕,品保部門多會建立較多且具有多元性的的資料,然後加以測試。其原意本非針對易用性進行測試,而是為了避免有任何疏漏未能測試到,但往往也同時發現易用性的問題。

嚴格來說,品保部門也不是合適的產品易用性檢驗單位。事實上易用性本身也是門學問,也有專家學者整理出來意用性的特質與特性。比方我們來想想,什麼叫做易用性? Donald A. Norman 提出產品的易用應具備:Easy to discover, easy to learn, easy to use。

我們可以回想看看自己周遭的各種產品,它們的易用性如何,即便我們已經很熟悉的產品,例如自己的手機或是家裡的飲水機。想想看你天天搭乘的捷運,模擬你第一次搭乘,當你在捷運站附近時,捷運站入口是不是容易辨識?走進捷運站後,買票怎麼買,找售票口還是找售票機?在售票機前,如果你完全不看上面的文字,只看符號,是否容易懂得怎樣購票?買到票了,前往驗票閘門,你是否容易知道怎樣驗票?(特別是台北捷運單程票改為硬幣式,這在國外也很少見)通過驗票口後,月台方向指示是否清楚?到了月台後,欲搭乘的車輛在那個方向的月台,是否容易辨識?

當模擬自己是個對該產品極度不熟也不具備相關背景知識時,就越容易發現該產品的易用性做的好不好。這就好比請個鄉下人初次進都市搭乘捷運那般,或是找個外國人首次訪台。當然經過一定的訓練,或是對易用性具備足夠的敏感度,就越不需要刻意做情境模擬,就能發現易用性的問題。

最後,產品的易用性為什麼決定了它的成敗?試想,即使你的產品沒有功能瑕疵,而且你的產品也大賣,但是使用者緊接著發現產品不易使用,即使看了說明書依舊感到迷惑,那麼就會有越來越多的使用者撥電話到你的公司詢問產品問題,你的員工或是客服人員就會忙著解答這些使用上的問題,並且問題的數量會隨著你產品賣越多而跟著增長。我想沒有人會認為需要為了使用 PDA 手機而報名一堂需要繳費的課程來學習它,這並不是像學一套複雜的 PhotoShop 一樣。如果你的產品目標是廣泛且龐大的使用者,那麼它就是要具備足夠的易用性。此外,如果一個產品的易用性太低,好比說你有很多很強大的功能,但是藏的很深,很多人不知道怎麼用,那麼大概多數的人會因為根本沒發覺那些功能而覺得你的產品並沒想像中那麼好,價格功能比偏低,這些顧客會逐漸的流失。

iPhone 為什麼賣的那麼好,裡頭很大的因素之一在於它的易用。我相信有相當比例的人買了 iPhone 回來,說明書根本沒打開過,或是僅翻了幾頁,從此就沒再見過說明書了。 HTC 為什麼賣的比其他 PDA 手機來的好,因為 HTC 也客製操作界面,大大改善 PDA 手機的操作方式與習慣,大幅提升產品的易用性。其他未經客製的 Windows Mobile 手機就失敗在於這微軟原廠內建的界面並不符合手機群 "Smart" 的期望,因為它原先的設計是給 PDA 用的,拿著觸控筆想像你在操作一台微型電腦,設計的角度並非從 "Smart Phone" 出發,因此很輕易的就被後起的 iPhone 與 Android 打敗。