我們都知道可用性測試能夠幫助我們及時發現問題，讓我們做出更符合用戶需求的產品，也能讓自己的方案更有說服力。但你可能也聽說過一次完整的可用性測試所需要的成本也是不菲的，我們需要招募用戶、撰寫測試腳本、製作測試原型，還需要有記錄設備、有經驗的主持人、用戶獎品等。
專業完整的可用性測試固然能更好地發現問題，但也會消耗更多的時間和資源。就像《Don’t Make Me Think》作者說的那樣，做一次「打折」的可用性測試其實也能達到不錯的效果。最近我在做一個功能模塊的優化，已經出了新方案的原型，但是不太確定它能否很好地解決問題，就和產品經理商量一起組織一次簡單的可用性測試，發現收穫還蠻大的。
用這篇文章記錄一下這次可用性測試的過程，也算是自己的思考總結。
一、明確目的
無論是交互設計師還是產品經理，我們在做任何方案之前最重要的事情就是要明確目的。這次測試也不例外，我們希望能夠通過對被試者的行為分析來了解該設計方案是否比現有設計好，能不能夠解決問題，還有沒有優化空間。
二、準備原型
其實這一次想到要進行測試時，原型已經做好了。但為了達到更好的效果，我們又特別製作了一個高保真可交互的原型以供測試。在原型中我們都是儘量找來現有產品中的真實數據，以保證被試者有代入感。
三、招募用戶
一般可用性測試需要尋找產品的真實用戶，但這需要提前招募，還要預約時間，會比較久。因為公司平時都在使用自己的產品，所以我們就準備從其他各部門招募幾個同事來進行測試。這樣的話，可以節約很多時間。
不過需要注意的是，在邀請之前也需要和對方講清楚這次測試將會耗時多久，問他們有沒有時間，畢竟這會影響到對方的工作。
一般對於外部用戶，可用性測試是需要支付一定報酬或者獎勵的。這一次雖然我們邀請的是同事，也還是要給他們一些小禮物表示感謝，因為每個人的時間都是寶貴的。這一點在測試之前我沒有想到，還好產品經理準備了一些小禮物，當然也不用太貴重，一些零食什麼的就可以啦。
四、撰寫測試腳本
接下來就是撰寫測試腳本。由於我沒有經驗，撰寫的測試腳本很長，而且不符合真實場景，導致在測試時不是很順暢。因此我總結了兩條建議：
1. 控制任務數量
在進行任務設計時一定要控制好總量，太短得不到好的結果，太長會導致被試者失去耐心。這次測試我就犯了「任務設計過多」的錯，導致有幾個被試者在看到任務列表時就被嚇到了。
2. 任務應該符合真實場景
在進行任務設計時，應該保證這些任務是連貫的，符合真實場景的。我在設計任務時為了保證每一個點都能被測到，設計的任務沒有連貫性，也不符合真實使用場景，導致一些被試者看不懂任務。
五、正式測試
接下來就到了我們的重頭戲——正式測試，正式測試其實包括前中後三個階段。
1. 測試前
在測試之前，需要準備好兩臺電腦和一間安靜的會議室。一臺電腦做測試之用，提前安裝好錄屏軟件（推薦 ScreenFlow ，可以同時錄屏錄音），並將測試原型打開。另一臺電腦顯示測試任務，方便被試者瀏覽。
測試前人員分工也很重要，需要定義一名主持人和一名觀察者，主持人引導被試者進行測試，觀察者用紙筆記錄被試者的行為。大家一定要提前分工明確，以保證測試正常進行。
2. 測試中
測試中，主持人需要先簡短介紹測試背景，以及一些注意事項。需要注意的是，主持人在測試時不應該引導被試者，如果被試者問自己該如何操作，也應該告訴他先自己摸索，直到進行不下去時才可以適當說明。
主持人可以在測試時使用「發聲思考法」，發聲思考法是指：引導被試者一邊操作，一邊說出心裡的想法。這樣可以實時地瞭解被試者的真實想法，以免在最後訪談時被試者忘記了當時的想法。
3. 測試後
測試完成後，主持人和觀察者應該及時訪談被試者，瞭解他們的一些想法。此時觀察者也可以就自己記錄的內容進行提問，以便後面的分析。
六、分析輸出
在最後，我們應該將所有資料彙總，分析總結這其中遇到的一些問題。根據分析結果，總結出問題的重要性，進行方案優化。如果時間允許，甚至還可以使用優化的原型再做一次測試。
總結
這次測試我們儘量簡化，從原型製作到測試分析只用了三天左右的時間，但是發現了很多問題，收穫很大。對於這一次可用性測試，我還從中總結了以下幾點：
- 預測試不能省略，預測試能夠讓我們提前發現問題，讓正式測試更加流暢。
- 測試前一定要和被試者說明我們測的是產品的問題，而不是人，讓被試者放鬆下來。
- 當你的原型太過於高保真時，應該告訴被試者這只是原型，否則他們會當成真實產品。
- 除了獲得一個更好的設計方案，這也是一個和同事增進交流的機會。
閱讀更多 河北華信智原 的文章
