最近在公司也主導了一次可用性測試，有一些實質性的收獲，趕緊給大家來分享下可用性測試的整個過程。我把整個測試流程分成前、中、后三個部分，對大家理解整個流程會清晰一些。

可用性測試是什么？

1. 國際標準 ISO

可用性的概念是指：“特定的用戶在特定的使用場景下，為了達到特定的目的而使用某些產品時，所感受到的有效性、效率及滿意度。”

根據 ISO 的定義，同時滿足了以上三個要素，才能稱得上是實現了產品的可用性。

然而，在實際操作中往往因為開發周期緊張而無法全部滿足，這時的解決方法是，首先解決有效性問題，然后在時間和成本都允許的情況下，盡量解決效率和滿意度的問題。

可用性測試的目的

可用性測試的目的一般就是這三個有效性+效率+用戶滿意度。

但是我們通常開發周期緊張的時候無法完全滿足這些需求，那這時候首先考慮的就是有效性問題。在時間和成本都允許的情況下再解決效率和滿意度。

而在這三點的基礎上我們當時還會有這三個問題：

• 預知風險、對抗風險
• 獲得一手信息
• 發現問題、甄別問題

因為工期緊，對接方多，經驗少，投入大 。所以還需要提前預知風險，我們設計師其實一直是對接處于后面一點的角色，想要看下用戶的真實反饋來驗收自己的產出，所以整個過程就是一個發現問題解決問題的過程。

可用性測試方式的選擇

一般可用性測試有兩種方案，我們團隊采取的是形成性的可用性測試方式。

1. 形成性

我們基于當前的資源很顯然選擇形成性的會方便很多

為什么要用形成性的可用性測試的方式呢？首先它只需要 3 到 5 名的用戶參與測試。然后測試的時間大概為兩個小時，當天其實就可以匯總出結果。而且我可以根據產品的迭代進行一個可用性測試的，整個的空間和資源的要求都比較寬泛。

2. 總結性（這種可以委托給乙方做）

了解一下總結性的可用性測試。這個主要是針對第三方或者是乙方公司，益普索、普華永道專門做市場調研的公司，針對你的這個用戶進行大量的投放，那這個成本就會很高了。

所以咱們在工作當中，如果設計師自發的話，還是建議這個形成性的可用性測試。

可用性測試的原則

可用性測試其實是我們請用戶來，然后觀察他們使用我們的產品。這里的使用不是指漫無目的的打開產品瀏覽，而是有針對性的對某一個或是某幾個流程進行使用。所有開始可用性測試的第一步就是“給用戶找點事情做”。

那給用戶怎么找點事做也是有講究的。

1. 劇本化任務

因此，我們需要把任務潤色成用戶一個實際的使用場景。例如，周末你在抖音看直播，逛到這個直播間，覺得主播的直播內容很有趣，你的賬戶里有 100 個抖幣，于是你決定給這個主播送禮物，預算大概是 99 抖幣左右。

如果像這樣以創造一個實際場景的方式告訴用戶任務，用戶就可以通過自己以往的經驗，帶著生活實感，更主動的使用產品。只有用戶更主動的使用，更主動的思考，可用性測試的流程才能進展的更加順利。而不是機械化的，布置任務完成任務的循環。

2.? 明確任務起點與目標

什么叫明確任務的起點和目標。

比如說這三個頁面。進了這個房間完之后他覺得這個劇本還不錯，想找一些朋友過來玩。任務目標喚起分享，分享好友。只要分享成功就可以。

3. 鎖定任務

任務二：房主

“進入房間后，一個人太過無聊，于是你決定分享房間以邀請一些好友進來。”

任務起點：劇本殺房間頁

任務目標：微信/QQ 對話窗口

4. 給任務設置約束條件

第一點

不要使用搜索（測試搜索的時候除外），如果使用搜索完成了測試目的，那么就會變成了搜索是否可用的測試。而測試不到實際的功能點。如果參與者忘記了這一點，并試圖使用搜索，你可以提示他們：測試中不希望使用此功能。

第二點

留在產品內，這一點一般不需要特別指出，只是遇到測試者試圖離開產品的時候，需要稍作提示。別忘了后續追問，用戶為何會想要離開產品。

第三點

不私下交流，因為我們要模擬線上環境，所以不可以私下交流，需要在線上房間內去交流。（不具備普適性）

測試前的準備

1. 招募用戶

尼爾森博士曾經提出“有 5 個人參加的用戶測試，即可發現 85% 的產品可用性問題。”大部分可用性測試的經驗是一次測試招募 3 名左右用戶。

用戶的數量

根據尼爾森說“有 5 個人參加的用戶測試，即可發現 85% 的產品可用性問題。”大部分可用性測試的經驗是一次測試招募 3 名左右用戶。鑒于我們產品的特殊性，一組的用戶定位 4-5 人，符合大多數用戶場景。

招募標準

專業用戶（4-5）

1. 專業+置信度高（直播設計+產品）
2. 高玩(經常使用產品的用戶)

有競品使用經驗，不是產研開發同學（好處是因此目標用戶遇到的問題更有參考價值。或者目標用戶具備其他用戶不具備的專業知識。）

如果你希望嚴格按照目標用戶來招募測試用戶，你需要注意以下幾點：

• 根據測試目的來定，找出與測試目標有關的篩選維度
• 特別考慮用戶使用行為相關的特征，例如競品使用經驗，使用產品的目的，用戶活躍程度
• 挑選最核心的維度，轉化成用戶的招募條件，并盡量客觀化、具體化、可衡量
• 注意辨別用戶信息的真假-偽需求

自由招募：（5-6）

總不能因為無法招募到目標用戶而不進行可用性測試，對招募用戶的條件進行適當的放松，多進行幾輪可用性測試，顯然才是更聰明的做法。只要規定好測試任務就好。

招募渠道

1. 公司內部非本項目產研的同學
2. 社會招募

招募方式

「甄別問卷報名表」

群發內容：

聲探社試玩開始啦！想參加的同學可以掃碼填寫甄別問卷即可報名。

除了基本信息，還需要設定一些甄別條件，比如有無產品使用經驗、使用頻次等問題，便于給測試用戶分組測試。

2. 確定測試時間和環境

測試時間：

測試準備時間：建議為期 3 天。準備相關物料、場地、測試任務，和向上同步等。

用戶測試時間：建議為期 3-5 天。可短時間內容集中進行用戶測試，或在工作日穿插進行測試。

結果整理時間：建議為期 3 天。用于整理測試信息、落實產品迭代任務、撰寫總結報告等。

測試地點：

會議室（一人一間），提前預約會議室

拉群通知

開始前的最重要的意向就是把測試分組后的用戶拉到群里，通知大家時間、地點、需要準備的事項和物品。同步一下是否都能到場。

3. 測試物料

線下環境我這次準備了：

操作設備：取決于目標用戶群體主要使用的設備，自己的手機更新到軟件的最新版本。如果需要測試音樂相關的功能，需要準備耳機。

錄音設備：測試結束后需要進行詳細的信息整理，錄音資料可以幫助回憶溝通內容。可使用手機自帶錄音功能或專業錄音筆。錄音前必須告知用戶，在征得許可后方能進行錄音。

錄屏設備：工具型產品的操作過程中涉及很多細節，錄屏資料可以幫助工作人員進行問題定位。可使用電腦自帶錄屏功能，或錄屏工具。

記錄本和筆：測試過程中進行表格填寫時需要使用。

統計文檔：主要包括測試過程中需要填寫的表格。建議打印 n+2 套，n 是測試樣本數量，另外 2 套備用。

測試酬勞：具體可根據公司政策進行準備。

如果遠程測試，除了要準備這么多設備外，還需要準備遠程在線協作軟件。zoom、騰訊會議、飛書等。

4. 組織人員注意事項

積極發問+時刻觀察+及時記錄

用戶發出疑問的聲音或者微表情，然后這時候你就要提出你的問題啦，比如說你可以適當的問一些，你這是怎么啦？然后你在想什么？你是在哪一個步驟有什么疑惑嗎？那你為什么要這樣操作？但是切記注意語氣，保證親和力。還有不要揣度用戶行為并搶先給予提示。比如，“這個部分您似乎覺得很難理解”等等。

觀察人員盡量時刻觀察用戶和用戶操作界面。比如：誤操作了可以觀察用戶是否可以順利的返回測試頁面，以防遺漏一些細節。

保持中立

不回答，保持中立。鼓勵用戶表達對任務的看法，而不是直接提出意見。如果用戶不順利可以給予適當引導

適當干預

如果在測試過程中遇到無法進行的情況，或者測試進度拖慢的情況，可以適當的干預。

事后回顧

測試結束后，可以再次回顧過程中發現的問題。比如：參與者對于某些功能發表了看法，這時你可以層層挖掘，了解到底為何導致了他的這種看法。或者錯過了發問的時機，還有就是碰到了不善于表達的用戶，可能沒有及時表達觀點。“您剛才在 xx 頁面做了 xx 操作，能說一下為什么這么做嗎？”

需要特別注意的是，一定要在所有任務全部完成之后再使用回顧法進行提問。如果在任務執行過程中向用戶提問，很可能打斷用戶的操作，作為采訪人員我們絕對不可以干擾用戶對產品的使用過程。

正式測試

我們是 150 分鐘的測試，提前和測試者同步一下，按照大綱來進行測試流程，及時調整問題，維持好現場的順序，保留測試錄音就可以。

1. 開場介紹

打招呼，說明此次訪談目的

“您好，我是 XXX。今天這個訪談主要是為了了解您對我們聲探社的使用情況。測試的時間兩個半小時左右。希望大家能積極的發表意見”

介紹一些試玩規則+簡單介紹我們測試流程（完成任務-評價任務-最后反饋）

“我們的測試流程主要是跟隨著測試任務進行。進行每個操作前，都會發布任務；完成任務之后，會發放相應的量表進行填寫，填寫完成之后再發布下一個任務；直到所有任務完成，填寫總結量表。

您的任何反應都對我們至關重要，請您在測試全程隨時表達，我們將會根據您實時的反應、填寫的量表進行整體性的評估。請大家記住，我們的目的就是希望大家提出問題。”

需要注意的是：

1. 測試流程時間有限，必要時我們會介入Push流程
2. 除了游戲環境內，玩家不能在現實中交流，需模擬線上環境
3. “希望您能一邊操作一邊把您心中所想的說出來，特別是您要怎么樣操作，為什么這樣操作，這些內容對我們來說非常重要，也非常具有參考價值”
4. “雖然您可以在訪談中進行提問，但由于我們想知道用戶的產品使用情況，因此可能不會馬上回答您的提問，事先對您進行說明一下，希望您諒解”

2. 簡單熱場

簡單熱場的目的：(活躍氣氛)，等待手機調試

詢問用戶背景以及產品使用情況；讓用戶在執行任務的過程中說出正在思考的內容（發聲思考法說明）

1. 確定用戶的手機型號，app版本號
2. “您使用產品的經驗有多久了？”
3. “您玩過幾次劇本殺，是線上還是線下的，有沒有什么體驗特別好的回憶能分享下嗎”
4. “一般玩什么類型的劇本殺”

3. 測試任務、觀察記錄

給出任務，用戶開始測試，完成任務之后可以停下來填寫用戶感受。

需求池（設計師）：

初始問題的積累，我和同事會根據二十一條可用性原則走查出我們當前的視覺和交互的問題。設置為任務。

任務設計（產品+設計）：

主要功能的流程，設計的原則參考第四點。

用戶體驗問題記錄表（組織人員）：

這個使用方法本來是讓用戶自己的記錄問題并打分，但考慮到用戶記錄的準確性和理解成本，就改成組織人員隨時記錄用戶提出的問題。之后統計起來會更清晰。

4. 任務評分

輔助工具：

這些使用順序為：需求池-任務后評估量表問卷-系統可用性量表-用戶體驗問題記錄表

任務后評估量表問卷（用戶）：

在一個任務結束或者多個任務結束之后，我們會給當前的任務打分，比如說任務 1，你覺得從 1 到 5 打一個分，5 是特別滿意，及時進行對任務的反饋，以防測試時間過長遺忘細節。

5. 事后訪談

如果發現訪談當時遺留問題，聯系被訪者可進行簡短詢問，感想、主觀評價、期望等

“今天請您使用了聲探社，請您談一談使用感受”

“如果要綜合評價今天的體驗，十分是滿分推薦，您給聲探社打幾分呢？為什么？”

（未達到滿意的情況）“假設現在我們要優化評分，您認為哪個部分應該最優先得到改善？”

系統可用性量表(用戶)：

這個是在整個測試完成之后，就讓他填寫打勾的去評價。我之前用的是翻譯版，會有用戶打分相斥的情況，建議搭配有講解的表單（1）。

整理結果數據分析

1. 歸類和分析問題

通過收集用戶體驗問題記錄表，進行小組會議討論，把問題總結歸類，并對所有問題做一個統一的規范分類。（例如可優化問題保留，不是體驗問題的舍棄）。

當問題總結歸類完成后，下一步需要引入「用戶體驗八陣圖」來對應相應頁面，讓我們能夠更直觀的了解到現有項目中精細到單個頁面中所面臨的用戶體驗設計問題，這樣一來，可以快速發現體驗問題最多的是哪個頁面？體驗問題最嚴重的是哪個頁面？體驗問題中哪個模塊的問題最多等。

系統可用性量表的使用方法

在填寫的時候發現了一個現象，本來互斥的問題但是用戶打分是一樣的，這就說明用戶沒有好好審題，或者沒有理解題目的意思，所以在第一場測試結束之后，更新了有講解的表單，或者在填寫問題的時候控制填寫題目的進度并講解。

2. 需求鑒別排列優先級

需求優化表（產品+設計）：

我們會將所有的問題記錄，然后把它去排到整個的需求池里邊，然后再分優先級組，這就是我們所有的這個測試的一個物料。

3. 撰寫報告

在得到結果和改版方向之后，可以把整個過程再次復盤一下，可以按照總分總的形式去梳理。同時報告一定要高度總結，高度概括，條理清晰。從發現問題 - 解決問題 - 過程中做得不到位的地方去梳理。以及可以附上優化之后的設計稿，和之后考慮設計的需求和設計方向。

參考文章： http://www.woshipm.com/pmd/3474767.html

歡迎關注作者微信公眾號：「七醬設計筆記」