需要注意的是,可用性測試中,問只是其中的一部分,觀察是另外一個重要的內容,所以測試腳本不僅僅要有問的問題,還有需要撰寫工作人員觀察的注意點。同時可以在撰寫完測試腳本的同時,把總結大綱也寫出來,方便后期總結的時候統一結果展示。
特別的,在設計的時候有疑惑的點,或者有爭議的點,在可用性測試也可以得到較好的驗證。
寫完測試腳本之后,可以和利益相關者(項目經理、產品經理、開發等)討論一下,請他們校驗一下測試腳本。
界面:
a)當前界面有什么?
b)每個東西用戶覺得是什么?
c)可以操作嗎?
d)用什么手勢操作方式?
e)操作之后會怎么樣?
f)界面顯示的內容足夠嗎,有沒有缺少什么東西?
流程:流程的測試就是根據任務來進行的。把產品的需求文檔羅列出來,然后給每個需求配上一個合適的場景,當然也會出現一個場景覆蓋多個需求的情況,這也是允許的。然后讓用戶在場景下去進行任務,觀察用戶,然后隨時提問用戶,隨時準備回答用戶的問題。
以上兩點適合所有的可用性測試,但是對于版本更新類的可用性測試,我們還需要了解這個更新對于用戶來說的接受度如何,所以需要增加一些對比性的問題:比如說:新舊版的操作流暢度、界面表達對比感受。
最后需要注意的是,一次可用性測試能涵蓋的范圍有限,所以要限制腳本問題的數量,以及對腳本的問題進行優先級的排序。
舉個例子,之前做過一個微信端的眾籌平臺。我就可以設定以下任務:
可用性測試的原型一般是高保真的Demo,可以用Prott,Flinto,proto,墨刀等來制作,制作力求真實還原應用的最終實現效果。制作高保真Demo是一件耗時耗力的工作,所以在制作的時候可以適當忽略一些動效、界面等。不過做出來的Demo最終也可以給開發參考,所以辛苦也是值得的。甚至于,可以請求開發人員制作原生的程序Demo(針對安卓平臺),程序Demo體驗會更加好。
當然,紙面模型也是另外一種非常好的工具。紙面模型需要把紙面模型都只做出來,然后把所有的彈出窗口、下拉菜單等控件也制作出來。然后設計師充當wizard of oz來輔助用戶完成任務。即用戶對著紙面模型來操作,然后設計師實時反饋用戶的操作。這樣子要求設計師非常熟悉測試的應用,同時,測試的時間也會大大增長。同時,動效作為設計的一環在這里無法表現出來,所以結果可能會不如高保真Demo來的好??傊饔欣?,根據實際情況來考慮。
測試環境是指測試的時候需要使用的記錄設備,通過把測試過程記錄下來可以更好地分析用戶的行為,特別是用戶自己都沒有覺察出來的一些東西。
首先,最最重要的一點是錄音,錄音一方面是在整理訪談記錄的時候可以幫助設計師回憶訪問的場景,然后填補一些缺失的筆記。另一方面,錄音也可以作為一種存檔的材料。同時,錄音也存在簡單、易操作、隱蔽等特點,使用錄音筆或者現在隨處可見的智能機即可完成錄音。所以強烈推薦進行可用性測試的時候一定至少要錄音。
錄音之外就是錄像,如果有錄像的話,錄音的步驟就可以省略。錄像主要是記錄用戶的表情和動作。有時候,用戶的表情和動作可以傳達很多東西,通過把這些信息記錄下來可以,設計師偶爾可以挖掘到一些閃光的設計點。
除此之外,用戶的屏幕記錄也是一種方式,通過用戶的屏幕、加上用戶操作的動作,表情,可以真實還原用戶的使用場景,方便后期的分析。
錄像和錄屏的操作比較難進行,主要的設備可以參考如下【5】,具體可以查看相關的鏈接:
·攝像機:記錄動作和部分表情
·眼動儀:可以追蹤眼球的焦點軌跡,不適合移動端
·鼠標軌跡記錄:記錄鼠標軌跡,只適用于PC端
·QuickTime (iOS):僅記錄屏幕
·Mobizen (Android):記錄屏幕、手勢
原文轉自:http://www.jianshu.com/p/7dc60d80a928