可用性測試:任務評估模型與計量方式

4 評論 15685 瀏覽 92 收藏 15 分鐘

在可用性測試中,如何去評估測試的場景或流程呢?應該包含哪些維度?每個維度要如何測量?怎樣在不同的任務間做橫向對比?本文作者將與你分享,enjoy~

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

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

在這次可用性測試的規(guī)劃階段,我花了些時間查閱資料,考慮合適的評估模型和方法。下面介紹最終使用的評估模型,拋磚引玉,如有更好的經(jīng)驗方法希望不吝賜教。

評估模型

ISO9241中對“可用性”的定義是:特定用戶在特定的使用場景中,為了達到特定目標而使用某產(chǎn)品時,所感受到的有效性、效率和滿意度。

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

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

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

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

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

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

測量方法

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

有效性

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

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

(1)失敗

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

需要對每個任務都設置一個限定時間。要求對功能非常熟悉的人(相關的產(chǎn)品、設計師都可以)按照任務提示進行操作,記錄完成操作所需的時間,稱為熟練用時。如果想要提高熟練用時的測量準確度,可以多找?guī)讉€熟手操作然后取其用時平均值。任務的限定時間根據(jù)熟練用時確定,一般是熟練用時的3-10倍,但是最高也不要超過10分鐘(沒有用戶會有耐心花10分鐘完成一個任務,如果真的需要這么久,說明任務設計得太復雜了)??梢愿鶕?jù)任務的難度確定倍數(shù),如果任務對于小白用戶來說確實很有難度,那么可以適當延長任務限時;如果任務很簡單,或者其中包含一些輸入的操作,那么可以適當減少任務限時(因為打字往往比較費時,而且對功能熟悉的人打字未必比用戶快)。

(2)部分完成

用戶只完成了一部分的任務,沒有完成任務卡上的所有要求。比如,你希望用戶創(chuàng)建一個日程并邀請小王加入,用戶成功創(chuàng)建了日程但是卻不知道如何(或者忘了)邀請小王,這就是部分完成。之所以要區(qū)分“部分完成”這個類別,是因為它跟100%完成有差距,但是又不能與失敗混為一談。

(3)完成

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

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

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

效率

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

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

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

在計算每個任務的效率水平的時候,可以用用戶的平均用時除以熟練用時所得的倍數(shù)表示(數(shù)值越大表示效率越低)。這是為了便于任務間的橫向比較,因為不同任務的復雜度不同,A任務平均用時1分鐘、B任務平均用時4分鐘,也不能說明A的操作效率比B高。通過平均用時/熟練用時的比值,可以知道新手與熟手之間的差距,從而了解因為系統(tǒng)的可用性及學習成本給用戶帶來的操作時間損耗。

滿意度

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

這里參考的是Jakob Nielsen使用的一個單題項七點量表,并根據(jù)需要對題目進行了修正:

用戶價值

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

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

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

任務橫向對比

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

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

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

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

可用性水平=Z(有效性)*0.5-Z(效率)*0.3+Z(滿意度)*0.2

(效率處用減號是因為其用時間測量,數(shù)值越大效率越低)

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

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

問題優(yōu)先級

除了上述的評估模型外,在可用性測試中我們還會發(fā)現(xiàn)很多可用性問題,這些問題大概是可用性測試產(chǎn)生的最重要的數(shù)據(jù)了。那么,這些可用性問題是否需要進行優(yōu)先級評估呢?

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

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

 

本文由 @cyan_zheng 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉載。

更多精彩內容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 橫向任務對比——而任務3的用戶價值最高,可用性水平居中。這里是不是舉錯例子了?

    來自廣東 回復
  2. 這篇方法論可用性很強,32個贊。最近項目要做α版本測試,正好拿來用一下。

    來自廣東 回復
  3. 對于樓主這篇文章要贊一個,可用性測試一般針對企業(yè)級產(chǎn)品用的比較多,畢竟用戶操作流暢度直接影響了他的工作效率,消費級的產(chǎn)品目前國內做的不是很多,即時做也只是類似用戶訪談,不會如此精確,一是缺乏專業(yè)訓練,二是時間成本較高,投入產(chǎn)出比不如用戶訪談或調研直接了當,大部分公司都沒有可用性測試,產(chǎn)品經(jīng)理疲于做版本迭代和開發(fā)撕逼,說起來都是淚。。。

    來自江蘇 回復
    1. 啊,那個大版本產(chǎn)品都要做可用性和易總性測試哇

      回復