易用性測試（Usability test）

文 / Maxxie （悠識 助理資訊架構師）

App / 網站 好不好，易用性測試見分曉！

前言

當你的團隊千辛萬苦完成了軟體、app 或網頁，滿心期待開放給大家使用，結果發現使用者一直不按下「結帳」、或者使用者用了反應太難用等等問題，當下只能穿著衣服改衣服，原來忙碌的團隊更加忙碌，新的專案因此受到耽擱。

但如果再發佈前，就能先掌握這些問題，免除發佈後修修改改的狀況呢？
易用性測試（Usability test），不但可以運用在產品發佈後的測試，也可以在研發時就先測試找出問題，但該怎麼做？

在這篇文章你可以暸解到：
1. 何謂易用性測試
2. 易用性測試的內涵與精神
3. 該如何施行易用性

易用性與易用性測試

據 ISO 9241 的標準定義，易用性（Usability）為產品本身在特定的情境（context）下為特定的使用者使用，其所具有之有效性（effectiveness）、效率（efficiency）與滿足（satisfaction）。簡言之，當你使用一項產品或服務，該產品 / 服務 是否有滿足使用者的目標（goal），使用情況是否為有效使用及有效率的，即為易用性（Usability）。

易用性測試（Usability test）即是測試上述三個面向之內容，檢視產品對於使用者的表現為何。

然而，在不同的產品上易用性的實際定義與測試，也將有所不同。如若是在電商網站上，使用者在易用性上，可能為「使用者是否能找到想要的商品」、「結帳流程簡便快速」等；而若是生產力工具，如筆記軟體，對使用者而言，「易於擷取畫面」或者「多種類的標示工具」，就可能會是易用性中的內容。

總言之，易用性會因使用者使用的產品不同，體現在實際操作的任務（task），但易用性的定義仍相同。

Usability 一詞在國內並沒有標準中文翻譯規範，從業人員習慣譯為「易用性」，在學術上則「使用性/易用性」兩者皆有人使用，本文依循行業習慣，採用「易用性」為中文翻譯。

易用性測試流程

一個簡單、完整的測試可以大致分為四個步驟，分別為「定義與設定」、「受測者招募」、「測試與觀察」、「結果分析」。依據規模與時程，測試中各步驟可隨之調整。

定義與設定

在測試前，先決定好本次測試內容的目標。兩種類別的易用性測試，「形構型測試」（formative）與「總結型測試」（summative），兩者差別在於施測的時機。形構型測試施測於產品完成前，依據施測的結果可以提供給設計者，作為產品設計或改善的參考；相反地，總結型測試施測於產品完成之後，除了獲得使用者反饋外，也可將其他相類似的產品予以測試，作為產品間互相比較的一途。

在前篇文章有介紹任務（task），使用者在產品中執行任務進而滿足目標。舉例來說，若使用者使用音樂串流 app，「找尋想要的音樂」，可視為其中之一個任務；而產品有提供甚麼任務，是設計者需考量的部分。在易用性測試中，即是以任務為測試單位；一個產品提供的任務眾多，在測試時需決定哪些任務為測試標的。

受測者招募

受測者將直接影響受測後的結果，因此在挑選上需要依照產品的目標使用族群為基準。此基準參雜眾多面向，可從基本的背景資料（性別、年齡、教育程度等）或 使用者能力下手，基準的設定越詳盡越能確保招募到符合的受測者。

至於受測者的數目多少最好？Thomas（2013）等人認為，6–8 位即足夠，大部分的易用性問題在前六位即可找到 ; 然而，如果受測者是有類別的，則每個類別至少要有 4 個。Nielsen（2000） 則認為，5 位受測者即可找出大部分的問題，但總體數目可以視有無類別而增減。

測試與觀察

測試的環境，可盡量挑選干擾較小之房間或環境，避免影響受測進行。施測進行前，應該先對受測者做整個測試的過程、目的的說明，並解釋測試後的數據、個人資料的處理方式。而紀錄受測者與產品互動的過程，如若以 app 測試，則可將測試時的 app 畫面予以錄影 ; 受測者的表情、手勢亦同，在最後與受測者討論時，可拿出來加以討論。

測試所使用的指標，也就是測試時執行任務時所用的測量標準，常用的如下 （Thomas, 2013 ; Jeff, 2016）：

1. 任務完成（task success） — 使用者是否有完成任務。透過有完成的受測者佔比，即是該任務的完成率。
2. 任務時間（task time）— 使用者完成任務所花費的時間。對大部分的產品來說，花費時間越短對使用者是正面的；然而對於一些產品並非如此，如遊戲、教育軟體等，時間越短的意義並非正面。
3. 任務錯誤（error） — 使用者執行任務時的非預期錯誤，如錯過、按錯按鈕，錯誤有時甚會導致任務的失敗。怎樣的情形算錯誤呢？只要是會導致任務在執行上，效率低、嚴重的損失、任務失敗，就可以算做任務錯誤。在處理錯誤時，必須了解導致錯誤的前因後果，以利改善。
4. 效率（efficiency） — 效率綜合了多個面向，對大部分的產品來說，效率代表使用者在越短的時間內完成任務，錯誤的發生也少。效率的計算，可 以 任務完成率 / 任務平均花費時間 之百分比來表達；如任務 B 任務完成率為 65，平均完成時間 1.5 分鐘，則任務 B 的效率為65/1.5，43%。除了以上的計算方式，使用者若在任務中耗費的步驟越少，亦能提升效率；如在電商中，購買商品所需要的步驟越少，則總體時間可減少、錯誤的發生也可避免。
5. 學習性（learnability）— 初學者從對產品不熟到上手，即為使用者的學習歷程，歷程的難易、快慢為學習性；學習性差對於剛使用產品的使用者，可能因為此障礙進而放棄使用。學習性常用的計算方式，可以前述任務時間、錯誤、完成等來做為計算；將受測者安排一定時間的多次測試，來檢視指標的變化。如以任務時間來看，將同一受測者執行同任務，第 1 次測試完成時間為 50 秒、隔一個月再測為 40、再一個月為 35；待受測者表現時間趨於穩定，即是該任務最大的程度表現。藉由改善產品並再檢測指標的變化，再來看是否在學習性上有提升。

在測試正式開始時，情境（Scenario）建立可讓使用者理解背景，讓任務的執行更加合理，情境的篇幅精簡扼要即可。閱讀完後接著為任務描述，任務應切合產品與情境的脈絡，不可指示使用者如何操作。以訂票網站來舉例，情境與任務指示如下：

＊情境建立

「你與朋友為了下週一的旅行已籌備已久，你們決定要搭乘台鐵前往目的地。預計在下午三點左右從台北出發前往高雄，為了能方便聊天，你們不希望座位分開來坐，並且能越快到達高雄越好。」

＊任務

「請預訂下禮拜一下午三點左右，台北至高雄的車票共四張」

然而在執行過程中，受測者可能會遇到疑惑障礙而無法操作，此時可決定是否該提供協助。對於受測者因碰到疑惑障礙而無法繼續任務，又可被稱為易用性問題（usability issue） ; 相較於上述以量化數值測量的指標，易用性問題為質性描述使用者執行上的問題。

結果分析

完成測試後，測量數值的意義因產品的不同而有不同。如果是以電子商務性質來看，讓消費者無障礙的購買商品，相信是電商網站的目標 ; 此時「任務完成」、「效率」、「任務錯誤」三個指摽的意義重要性不言而喻。要檢視哪些指標，端看產品本身的目標與性質而定 ; 有了指標的數值後，可以再進行產品調整再測試一次，並將前後版本的數值對照來看是否有進步。

在易用性問題的處理上，首先需定義問題從開始到結束為何，了解是什麼原因導致問題的發生，而問題的性質又是甚麼，是屬於導引、內容或功能? 接著以問題發生的頻率與嚴重程度，此兩指標來決定易用性問題的優先處理順序。

在易用性的定義之中有提到，滿足（satisfaction）也是其中之一的要素。使用者的滿足，來自於使用產品完的總體印象，因此在測量滿足通常為使用後再行施測。要注意的是，產品的比較需要其性質需一致，不同的產品來比較是無意義。(Brooke,1996)

SUS（System Usability Scale）量表，是目前較為人知及運用，來測量使用者滿足的五點量表，題目共有 10 題：

題目的分數計算，奇數題為正向題，將各題分數減一為最後分數，如若為 3 分計算結果為 2 分；偶數題為負向題，以 5 分減去該題分數為最後分數，如若為 4 分計算結果為 1 分。各題分數計算完畢後，將所有分數加總乘以 2.5，即得到總分。Jeff（2011） 指出，SUS 的平均分數為 68 分，因此可以將此分數作為產品及格分數。

結語

易用性測試提供設計者評估產品的途經，然而如果不知產品本身的功能與測試的目的，易用性測試的作用僅只是徒然。此外，易用性測試中，符合商業目標亦為重要；在執行測試前，應先諮詢其他利害關係人的目標需求，一併考量於測試之中。

參考資料：

1. Albert, W., & Tullis, T. (2013). Measuring the user experience: collecting, analyzing, and presenting usability metrics. Newnes.
2. Sauro, J., & Lewis, J. R. (2016). Quantifying the user experience: Practical statistics for user research. Morgan Kaufmann.
3.  Sauro, J. (2011). Sustisfied? little-known system usability scale facts. UX Magazine, 10(3), 2011–3.
4. Affairs, A. S. (2014, May 15). Running a Usability Test. Retrieved January 29, 2018, from https://www.usability.gov/how-to-and-tools/methods/running-usability-tests.html
5. Nielsen, J. (2000). Why you only need to test with 5 users.