可用性測試是用研的入門必修課，也是用研最常用的方法之一。這篇文章總結了我在做可用性測試時踩過的一些坑，以及總結出來的一些實踐經驗。
研究設計
- 必須清晰地定義產品面向的不同角色，如果不同角色的知識背景和使用場景相差較大，就不要用同一類用戶去測試所有的任務。我們做的是一款ToB產品，面向的是企業用戶，很自然地，我們的用戶分為兩大陣營：管理層和基層員工。做可用性測試時，考慮到邀請管理層用戶成本高難度大，且這次測試中我們更關注的是基礎功能的可用性，所以邀請的用戶基本都是基層員工。但是我們仍然為這些基層用戶設置了一些屬于管理場景的任務，希望能夠從中挖掘到一些有價值的信息。結果可想而知：軟件本身就具有一定的復雜性，基層員工不熟悉企業管理，在做任務的過程中可能連相關概念都不太懂，任務完成率非常低。我們想了解在用戶自主試用和探索之后，對產品的印象和態度如何，但是大多數基層員工現實生活中并不會有去自主試用這些產品的動機，因此用戶表達的可能是自己假想的態度，不具有太大參考價值。更好的方式是在研究設計階段就清晰地區分開管理層和基層的不同場景，如果對這些功能設計都存在疑慮，就分別邀請管理層和基層，做兩場基于不同場景任務的可用性測試。
- 重視行為以及對行為的解釋，不要花太多時間去了解用戶態度。可用性測試是定性研究，樣本量比較小，從這樣小的樣本中得到的用戶態度并不具有推斷價值。而用戶的行為和認知的個體差異和測量誤差相對要小得多，因此結果要更加可靠一些。在我接到的調研需求中，就包含了“了解新用戶對產品的印象和態度”這一項，并且設計師也提了很多問題給我——對于他們不太確定的問題，他們希望知道用戶怎么想。光是詢問這些問題，我都能跟用戶做場一個小時的訪談了。把它們加到可用性測試中，會導致測試時間太長，影響了真正重要的任務測試過程；并且如果只是簡單詢問這些問題而不深入了解，得出的結論也確實沒有多大價值。
用戶招募
一定要為參與測試的用戶設定一個合理的標準，不要因為用戶難找、時間緊迫而降低標準。由于招募渠道有限，報名用戶不多；而我當時既要做好腳本設計的工作，又要同時篩選和預約用戶、預約會議室、調試設備，并盡可能快地開始測試，時間緊迫和人手不足讓我不得不降低用戶篩選標準，因為我沒有精力去拓展其他招募渠道，也沒有時間等待更多的用戶報名。這樣做的結果是招募到了一兩名確實不太適合的用戶，而這是在用戶篩選的過程中本可以避免的事情。建議在平常的工作中多拓展招募渠道、建立用戶庫，這樣以后再有比較緊急的測試任務時，可以相對輕松地完成用戶招募工作，避免只能通過降低標準來完成招募。
腳本設計
- 任務千萬不要太多，如果安排了一個半小時的時間，任務最好不要超過6個。任務太多會導致用戶非常累，也很難以較好的狀態去完成后面的測試任務。尤其是當我們沒有條件提供一個環境較好的會議室時，用戶在密閉空間中待的時間太久，非常容易疲憊和注意力分散。任務完成了稍多于一半的時候，我一般都會詢問用戶是否要休息一下。有的用戶會樂意休息一下喝口水，但有的用戶卻希望再堅持一下，以便盡快完成所有任務——盡管堅持的效果往往不會太好。
- 有些功能本身就很復雜，在短時間內讓用戶了解和學會操作，對用戶來說難度太大。功能的復雜性可能體現在概念體系或者業務邏輯上。如果是概念復雜，可以用學徒式的問題，多問一下“這是什么意思”，了解用戶難以理解的是哪些概念；業務邏輯的復雜可能會涉及到較多的前后文操作、多角色交互，短時間內要還原出這個生態并不容易，遇到這個問題可能意味著我們把任務設計得太大，適當做些拆分可能會更好。
- 設計任務時到底要不要去問對應的產品經理和設計師？前面提到了設計師向我提了很多想要從用戶那里驗證的想法，正是因為我去問了，才會收集到如此多讓我頭疼的問題——很多問題不適合放在可用性測試中問，所以又要告訴產品和設計師們這些問題解答不了。似乎怎么看都是一件很麻煩的事情。但其實，還是應該問，只是要換種問法。不應該問“對于這個功能，你有什么想了解的問題”，而應該問“哪些功能是更重要的”“你對哪些部分的設計比較不確信”。他們對產品更了解，因此只要問對了問題，對于任務設計總會有好處。
測試過程
- 測試過程使用哪些設備、錄屏錄像需要哪些工具和環境，必須有一套完整的解決方案。測試過程總會出現很多意外狀況，比如WiFi連不上，錄屏軟件沒反應等，出現了問題的話就會耽誤用戶的時間。之前的測試中就是狀況不斷，尤其是使用安卓手機的用戶，錄屏比較麻煩。針對這個問題我專門整理了一下可用性測試中常用的設備，制定了一套比較適用、成本也不太高的解決方案，感興趣的話可以看一下我的另一篇文章。
- 如何讓用戶think aloud？我一般會在開場白的時候說一下，希望用戶隨時將自己的想法講出來；在第一個任務開始之前，我也會強調一下這件事。遺憾的是，到目前為止還沒能成功讓用戶做到think aloud。這對用戶來說是一件不太自然的事情，因此比較難讓用戶抗拒強大阻力做到這點。我目前的一個想法是在任務開始之前給用戶一點時間去練習和習慣think aloud，讓用戶能有時間去適應這種狀態。
- 要合理分配任務時間。開場白的時間、每個任務的時間、測后訪談的時間都需要在腳本設計的過程就大概確定，如果在測試中發現某個階段占用的時間太長，就需要控制一下時間，避免影響后續的任務。
- 盡量減少使用的打印紙的數量。測試過程難免需要一些紙質材料，但是本著低碳環保的理念，打印的紙能少就少。
我在做測試的時候有一些打印紙的標配：測試腳本會打印兩份，一份是我主持的時候需要看的（我可能在上面對腳本做些注解和調整），一份是給幫忙做記錄的同事以及到場觀察的PM設計等人看的（不管他們有幾人）；任務卡片會打印一份，是給用戶看的；用戶登記和禮金簽收作為同一個表，打印一份；知情同意書需要讓用戶感到足夠正式，因此每個用戶打印一份（我克制住了自己正反面都打印的沖動）。
接下來是令我頭疼的部分，就是每個任務結束之后的評分表。一般一頁紙就可以搞定，但是如果每個用戶都打印一張感覺有些浪費。我一度使用在線問卷的方式，用我自己的手機打開問卷鏈接，需要評分的時候就拿給用戶，但效果不好，一是手機界面小看著比較費勁，二是這需要我在幾個頁面之間來回切換，增加了我（作為主持人）在測試期間的工作負荷。后來想到一個很好的方法：打印一張評分表就好了，然后準備一些條形便利貼，讓用戶直接把便利貼貼在自己選擇的選項上，測試結束后把用戶的評分錄入到電子表格中，打印紙就可以重復利用了。這個想法本來沒有什么高明之處，它主要的優點是：我可以順便讓用戶在條形便利貼上寫下自己打這個分數的理由，因為空間有限，就可以收集到一些非常言簡意賅的理由。
分析整理
- 選擇一個合適的模型對不同功能的可用性進行綜合評估，便于對功能進行橫向比較。比如，可以參考ISO對可用性的定義：可用性=有效性+效率+滿意度。有效性可以用任務的完成情況來度量，效率可以用任務完成時間來度量，滿意度可以用用戶評分來度量。這樣子可以形成任務的可用性水平矩陣，便于在不同任務之間進行比較。
-
測試發現的可用性問題需要有一個優先級評定標準。簡單地通過發現該問題的用戶數來判定問題優先級是不太合理的，建議使用樽本徹也的方法。對有效性、效率、滿意度三個指標分別給定三個等級， 并賦予不同的分值，對每個可用性問題，評估在每個指標上處于哪種嚴重等級，按照下圖的標準，評定問題的優先級：
樽本徹也建議的問題優先級評定標準
如果對以上提到的問題有更好的建議和解決辦法，歡迎指教。
