1.28.2011

簡單快速的可用性測試

可用性測試是改善產品的最佳方式之一,這一點,在內部已經是不爭的共識。只是由於用研人手總是不足,所以為了能讓各個部門的同事能更快速地展開一些研究和測試的工作,我們陸續整理了一些簡單的文檔和教程,並計劃通過集中的培訓來普及一些用戶體驗的方法。因此,要特別強調的是,本文所介紹的測試方法是簡單,非正式的,小樣本的,以發現嚴重問題為目的的。如果要深入了解測試的原理,方法,請參閱以下幾本書:
Handbook of usability testing

Usability testing and research

Measuring the user experience

在開始之前,我要強調,測試要盡早開始,並且只需要簡單的設備就可以進行。

什麼是可用性測試?

其實可用性測試並不複雜,簡單概括就是觀察用戶使用產品。如果稍微擴展一些,我們可以將其解釋為:通過觀察有代表性的用戶,完成產品的典型任務,而界定出可用性問題並解決這些問題。而目的呢,則是為了讓產品用起來更容易。



如何設計和進行可用性測試

根據上面的定義,我們在如何設計和進行可用性測試的部分將主要回答以下幾個問題:

l  如何設計任務

l  如何找用戶

l  如何進行測試

l  如何分析找到可用性問題

如何設計測試任務;

設計測試任務是可用性測試前期計劃的核心,我們建議最好在任務設計之後再確定用戶招募的標准,因為測試中涉及什麼樣的任務和你要描述的用戶操作經驗直接相關。確定了前者,後者也就更明確了。

在設計任務前,需要反複的問自己:

“我設計的測試任務是真的反應了用戶的實際目標麼(而並不是我認為用戶想要做的事)?”

在問了三次以上上面的問題,並且確定可以肯定的回答自己之後,就可以開始設計任務了。

通常的方法是:

a)     先列出一個任務清單,用簡單的短句來描述測試中涉及的任務——主要是給內部人員看的。由於是快速測試,因此,任務不宜過多,必須是重要的,核心的,你覺得可能會有問題的任務;

b)     在篩選完任務清單後,將任務變成場景——場景就是你要讀給用戶聽,或者要給用戶看的內容。因此必須要包含用戶的目標和動機——因為對用戶來說,你的功能並不重要,重要的是他們的目的以及他們完成目的的過程。這時候,你可以再問一次自己上面的問題。

c)      確定操作任務需要的條件:比如是不是需要一個新的賬號,是不是需要准備好必要的文件等等;

d)     預測試:預測試主要是為了發現任務設計的問題,可以找公司內的同事,利用午休時間快速完成

如何找用戶;

在利用各種資源找用戶之前,我們要首先明確,我們要找什麼樣的用戶來?

找什麼樣的人來?

以前,在測試計劃階段,我們和產品以及設計的同事溝通,他們對用戶的描述,往往是:25~30歲,上班族之類。但事實上,我們在測試中最關注的是用戶的操作行為,因此,在確定用戶甄別的標准時,們最應該關注的是產品使用經驗和使用行為,而不是人口統計學特征。關於這一內容更詳細的解釋,可以參看這篇文章。http://www.uie.com/events/uiconf/2008/articles/recruiting_participants/

找幾個人來?

一談到要找幾個人來測試,就不得不請出Nielsen的這張經典圖表。雖然學術界對於5個用戶究竟是否足夠有很多爭論。不過,從我們的實踐角度來看,只要在第一個階段界定的好,找到合適的人,那麼,5個用戶真的已經可以發現明顯的可用性問題了,當然,這裡要再一次強調,快速測試的目的是為了發現嚴重的問題而不是全部的問題。

此外,我們發現,在平時的測試中,在觀察前三個用戶測試時,單面鏡後的產品和設計人員往往精力集中,下筆如飛,但到了5個之後,新的信息越來越少,大家不是發呆,就是幹脆睡了(像圖中的兔子一樣)。所以,從工作狀態的角度講,5個以內的測試用戶,能夠保證大家精力集中,並且願意去觀察和傾聽。

如何找用戶?

在確定了甄別的標准和用戶的數目之後,找用戶就成了頭痛的問題。在這裡,我的建議就是,由於是快速測試,就嘗試用盡一切辦法,無論是找同事(同部門的同事就不要找了),朋友,朋友的朋友,網站論壇發廣告等等,只要快,並且在招募時,堅持要求,大家是可以“不擇手段”的。當然了,如果這時候能有一份平時就在維護的用戶列表就再好不過了。

如何進行測試

因為是快速的測試,主持人從用研人員變成了產品和設計人員自己。因此,在這裡要強調的是,在測試中不要試圖教用戶如何使用產品,也不要試圖向用戶推銷你的產品

主持人做什麼

記錄人員做什麼

無論是有條件實時觀察(有專門的體驗室或者工具),或者需要回看錄像來觀察,記錄時都要注意,記錄的重點不是用戶說了什麼,而是用戶如何使用。記住,在測試中,做了什麼比說了什麼更重要。當然,由於是為了發現嚴重問題而進行的測試,並且嚴重的問題總是顯而易見,因此,可以同時記錄問題,但不要急於討論問題的解決方案。因為馬上想到的方案或者用戶提出的方案並不一定是最好的,這個工作可以留待可以安靜思考或者大家討論時進行

如何分析找到可用性問題

在完成測試後,需要主持人和觀察人員趁着記憶猶新的時候快速地將有用的信息整理出來,可以采用便利貼,也可以專門空出一塊白板或者建立一個文檔。總之把用戶相關的操作,提出的問題,和我們自己發現的問題迅速地寫出來。但,不要快速下結論。

在所有測試完成後,整理已經有的便利貼,列表等,然後找出那些最嚴重的問題,快速地修複它們。在這一環節,重點是一再地明確,究竟那些問題才是最重要的,並且可以馬上修複的。這樣,測試的結果才是可執行的,而不是僅僅變成了一張存檔的問題列表而已。

0 留言:

發佈留言

您使用留言則表示同意及遵守使用條款及守則

建議: 為方便留言回覆,請不要用匿名方式 留言。