在可用性測試中，如何做好任務評估模型與計量方式？

金蝶雲之家 用戶研究 員-鄭少娜：在 可用性測試 中，如何去評估測試的場景或流程呢？應該包含哪些維度？每個維度要如何測量？怎樣在不同的任務間做橫向對比？本文就此一一講述。

公司的產品最近發布了一個版本，上線了比較多的新功能。所以需要針對這些新功能做一輪 可用性測試 。

可用性測試算是用研的一個入門級技能，即使是從業年限不多的我也已經做過多次，基本的方法和流程都比較熟悉了。但是之前做過的可用性測試有個缺陷：沒有建立一個嚴謹、科學的任務評估模型。在可用性測試中如何去評估測試的場景或流程呢？應該包含哪些維度？每個維度要如何測量？怎樣在不同的任務間做橫向對比？

評估模型

iSO9241中對「可用性」的定義是：特定用戶在特定的使用場景中，為了達到特定目標而使用某產品時，所感受到的有效性、效率和滿意度。

也就是說，在定義好了用戶、場景和目標的前提下，可用性包含了下面三個維度：

• 有效性（Effectiveness）：用戶完成特定目標的正確和完整程度。
• 效率（Efficiency）：用戶完成特定目標的效率，與消耗的資源（如時間）成反比。
• 滿意度（Satisfaction）：用戶使用產品時感受到的主觀滿意程度。

良好的可用性必須能夠同時滿足有效性、效率和滿意度三個條件，但是這三個維度也有層次之分，一般來說，有效性問題>效率問題>滿意度問題。

在可用性測試中，僅僅了解每個功能的可用性水平還不夠。即使兩個功能的可用性水平一樣，若一個是產品的基本功能、一個是價值不大的邊緣功能，我們還是需要優先去優化價值更高的功能。也就是說，在評估一個任務時，除了可用性之外我們還需要考慮功能本身的價值。尤其是在上線了新功能，或者我們對待測功能的價值還不太確信的時候。

功能的價值可以簡單分為兩部分： 用戶價值和商業價值 。盡管有時候需要在商業價值和用戶價值之間權衡，但是作為一個體驗導向的產品，還是應該將用戶價值放在第一位。在用戶價值之上，若能夠滿足商業價值，則是更令人滿意的結果。

所以，在可用性測試中可以用下面這個模型來對測試的任務進行評估：

測量方法

在上述模型中，有效性、效率、滿意度都是常見的評估維度，有一些經驗方法可以參考，用戶價值也可以通過用戶評價獲得。而商業價值則需要根據產品的實際情況進行評估，並且這一般是既有的知識，不需要在可用性測試過程中收集這個數據。因此在可用性測試中我們需要收集的數據就只包含四個維度：有效性、效率、滿意度和用戶價值。

1.有效性

可以用任務的完成情況來評估有效性，這個數據通過觀察用戶的操作過程即可獲得。

任務完成情況的測量主要參考NNG的建議，將每個用戶的操作結果標記為失敗、部分完成或全部完成。

失敗：如果用戶認為自己完成不了而放棄了任務，或者超過了限定時間仍然無法完成任務，則標記為失敗。

需要對每個任務都設置一個限定時間。要求對功能非常熟悉的人（相關的產品、設計師都可以）按照任務提示進行操作，記錄完成操作所需的時間，稱為熟練用時。如果想要提高熟練用時的測量準確度，可以多找幾個熟手操作然後取其用時平均值。任務的限定時間根據熟練用時確定，一般是熟練用時的3-10倍，但是最高也不要超過10分鐘（沒有用戶會有耐心花10分鐘完成一個任務，如果真的需要這麽久，說明任務設計得太復雜了）。

可以根據任務的難度確定倍數，如果任務對於小白用戶來說確實很有難度，那麽可以適當延長任務限時；如果任務很簡單，或者其中包含一些輸入的操作，那麽可以適當減少任務限時（因為打字往往比較費時，而且對功能熟悉的人打字未必比用戶快）。

部分完成：用戶只完成了一部分的任務，沒有完成任務卡上的所有要求。比如，你希望用戶創建一個日程並邀請小王加入，用戶成功創建了日程但是卻不知道如何（或者忘了）邀請小王，這就是部分完成。之所以要區分「部分完成」這個類別，是因為它跟100%完成有差距，但是又不能與失敗混為一談。

完成：這個很容易理解，就是在限定時間內完成了任務卡上的所有要求。

最後，我們需要根據這些數據計算每個任務的成功率。NNG的建議算法是：任務成功率=(完全完成的用戶數+部分完成的用戶數*0.5)/用戶總數，即完全完成率+部分完成率的一半。

除了用完成、部分完成和失敗來評價任務完成情況外，還可以考慮另一種方式：順利完成、遇到障礙後完成、失敗。這是我之前使用的計分方式。這種方式下，以上所述的部分完成會被歸於失敗的類別（但如果用戶犯的是無傷大雅的錯誤，比如輸入錯誤，可以視為完成）。而成功完成的用戶會被細分為順利完成的和遇到障礙後完成的。之所以這樣區分是因為這兩種情況揭示了不同的可用水平——能讓用戶輕松地完成的功能可以說是相當易用的。

2.效率

效率可以用時間測量，對用戶的操作過程計時。

可以從用戶拿到任務卡開始計時，在用戶宣布自己已經完成、或者限定時間到了的時候即結束計時。不要等到用戶讀完任務卡、開始操作時才計時，因為有的用戶習慣讀完再操作，有的卻喜歡一邊讀一邊做。也不要在看到用戶完成了就結束計時，而要等用戶自己認為他已經完成了，因為用戶有時候會在做完操作之後去檢查自己的操作是否成功了，這也應該算作任務用時的一部分。

計時不需要太精確。手動計時存在幾秒鐘的誤差都算是正常的，而且用戶在操作過程中多說了句話、或者應用響應速度慢了些，這些都會影響任務的完成時間（並且很多影響因素跟可用性並沒有關系）。所以計時只要精確到秒就好了，提高記錄的精確度也沒有意義。

在計算每個任務的效率水平的時候，可以用用戶的平均用時除以熟練用時所得的倍數表示（數值越大表示效率越低）。

這是為了便於任務間的橫向比較，因為不同任務的復雜度不同，A任務平均用時1分鐘、B任務平均用時4分鐘，也不能說明A的操作效率比B高。通過平均用時/熟練用時的比值，可以知道新手與熟手之間的差距，從而了解因為系統的可用性及學習成本給用戶帶來的操作時間損耗。

3.滿意度

滿意度涉及到用戶的主觀評價，因此需要通過用戶自評量表來收集。

這裏參考的是Jakob Nielsen使用的一個單題項七點量表，並根據需要對題目進行了修正：

4.用戶價值

用戶價值是指用戶感知到的功能價值，也需要通過用戶的評價獲得。

因為我們做的是一款辦公軟件，所以通過詢問功能對工作的幫助來了解用戶價值：

滿意度和用戶價值都需要用戶評分，因此用戶在完成每個任務之後都會拿到同樣的兩個題目，要求對該任務做出評價。我會把不同任務的題目打印在同一張紙上，這樣用戶在評價時可以參考自己對前面的任務的評價來調整分數。

任務橫向對比

用有效性、效率、滿意度、用戶價值四個維度對任務進行評價後，我們可以根據這些數據對不同的任務做橫向對比，可以通過類似下方這樣的折線圖對比不同任務的情況。

比如從上面這個示例圖中，我們可以看到任務2的可用性水平是比較低的（有效性水平低、完成時間長、用戶滿意度低），但是它的用戶價值處於相對較高的水平；而任務3的用戶價值最高，可用性水平居中。

有效性、效率和滿意度都是用來評估可用性水平的。如果根據這三個數值計算出可用性水平，直接用可用性去做橫向對比，是否更方便呢？前文提到在可用性中，有效性問題>效率問題>滿意度問題，所以在計算可用性水平時它們應該有不同的權重；並且由於度量方式的不同，它們的量綱有較大差異（從上圖可以看出），需要做標準化處理。

因此，我們需要對有效性、效率、滿意度分別做標準化處理，然後按照5:3:2的權重計分（或者其他權重，按需調整）：

可用性水平=Z(有效性)*0.5-Z(效率)*0.3+Z(滿意度)*0.2（效率處用減號是因為其用時間測量，數值越大效率越低）

這樣我們得以在同個量綱上比較不同任務的可用性水平，結合對功能價值的評估，可以得出類似這樣的四象限圖：

這樣的象限圖不僅可以幫助我們比較測試的各個功能的情況，還能幫助確定體驗優化的優先級。功能價值高、可用性差的功能應該列入最高優先級，其次是功能價值較低、可用性差的功能。

問題優先級

除了上述的評估模型外，在可用性測試中我們還會發現很多可用性問題，這些問題大概是可用性測試產生的最重要的數據了。那麽，這些可用性問題是否需要進行優先級評估呢？

可用性問題當然是有優先級之分的，一個問題是影響了功能的有效性、效率還是滿意度，就決定了這個問題的優先級如何。我認為可以在每個任務之內按照這個標準對發現的可用性問題進行排序，但是不需要把所有任務發現的所有問題羅列出來去排列優先級。

優化可用性問題時應該以功能（即可用性測試中的任務）為單位，而不是以問題為單位——以問題為單位容易只見樹木不見森林，可能在修改了很多細節後仍然算不上好用。所以排列問題優先級時，也建議根據上面的四象限圖先確定功能的優先級，然後再去查看每個功能具體的可用性問題的優先級。

歡迎關註微信公眾號： 「UXD-Cloudhub」

「超專業！可用性測試指南大全」

• 《用戶調研新招式！如何進行可用性啟發式評估》
• 《零基礎也能學！超詳細的可用性測試方法經驗總結》
• 《移動可用性測試？分享一個你絕對不知道的新招（附教程）》

【優設網 原創文章 投稿郵箱：[email protected]】

================ 明星欄目推薦 ================

優優教程網： UiiiUiii.com 是優設旗下優質中文教程網站，分享了大量PS、AE、AI、C4D等中文教程，為零基礎設計愛好者也準備了貼心的 知識樹專欄 。開啟免費自學新篇章，按照我們的專欄一步步學習，一定可以迅速上手並制作出酷炫的視覺效果。

設計導航：國內人氣最高的設計網址導航，設計師必備：http://hao.uisdc.com

文章來源：