編輯導語：當你設計好一款產品，你要如何去確認你的方案是否有用？這時候就要用到可用性測試，每個產品的迭代都需要進行可用性測試，可以說“可用性測試”是交互設計中進行驗證必不可少的環(huán)節(jié)，那如何進行可用性測試？這篇文章從可用性的測試出發(fā)，詳細地總結了可用性測試的整個過程。一起來看看吧。

最近在公司也主導了一次可用性測試，有一些實質性的收獲，趕緊給大家來分享下可用性測試的整個過程。

我把整個測試流程分成前、中、后、三個部分，對大家理解整個流程會清晰一些。

一、可用性測試是什么

1. 國際標準ISO

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

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

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

二、可用性測試的目的

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

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

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

• 預知風險、對抗風險
• 獲得一手信息
• 發(fā)現(xiàn)問題、甄別問題

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

三、可用性測試方式的選擇

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

1. 形成性

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

為什么要用形成性的可用性測試的方式呢？

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

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

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

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

四、可用性測試的原則

可用性測試其實是我們請用戶來，然后觀察他們使用我們的產品。這里的使用不是指漫無目的的打開產品瀏覽，而是有針對性的對某一個或是某幾個流程進行使用。

所有開始可用性測試的第一步就是“給用戶找點事情做”。

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

1. 劇本化任務

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

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

2. 明確任務起點與目標

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

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

3. 鎖定任務

• 任務二：房主“進入房間后，一個人太過無聊，于是你決定分享房間以邀請一些好友進來?！?/li>
• 任務起點：劇本殺房間頁
• 任務目標：微信/QQ對話窗口

4. 給任務設置約束條件

1. 不要使用搜索（測試搜索的時候除外）如果使用搜索完成了測試目的，那么就會變成了搜索是否可用的測試。而測試不到實際的功能點。如果參與者忘記了這一點，并試圖使用搜索，你可以提示他們：測試中不希望使用此功能。
2. 留在產品內，這一點一般不需要特別指出，只是遇到測試者試圖離開產品的時候，需要稍作提示。別忘了后續(xù)追問，用戶為何會想要離開產品。
3. 不私下交流，因為我們要模擬線上環(huán)境，所以不可以私下交流，需要在線上房間內去交流

五、測試前的準備

1. 招募用戶

尼爾森博士曾經提出“有5個人參加的用戶測試，即可發(fā)現(xiàn)85%的產品可用性問題?！贝蟛糠挚捎眯詼y試的經驗是一次測試招募3名左右用戶。

（1）用戶的數(shù)量

根據(jù)尼爾森說“有5個人參加的用戶測試，即可發(fā)現(xiàn)85%的產品可用性問題?！贝蟛糠挚捎眯詼y試的經驗是一次測試招募3名左右用戶。鑒于我們產品的特殊性，一組的用戶定位4-5人，符合大多數(shù)用戶場景。

（2）招募標準

專業(yè)用戶（4-5）：

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

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

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

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

自由招募（5-6）：

總不能為無法招募到目標用戶而不進行可用性測試，對招募用戶的條件進行適當?shù)姆潘桑噙M行幾輪可用性測試，顯然才是更聰明的做法。只要規(guī)定好測試任務就好。

（3）招募渠道

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

（4）招募方式

群發(fā)內容：

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

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

招募要求：

• 測評對象：選擇那些活潑開朗且溝通意愿強的參與者。在進行可用性測試的時候我們通常會希望被訪者能采用“發(fā)聲思考法”。
• 招募條件：有劇本殺的經驗（最好）
• 參與人數(shù)：12名
• 任務：15個
• 測試時間：100分鐘

2. 確定測試時間和環(huán)境

• 表單：系統(tǒng)可用性量表+用戶體驗問卷+任務評估量表
• 錄音筆

（1）測試時間

• 測試準備時間：建議為期3天。準備相關物料、場地、測試任務，和向上同步等。
• 用戶測試時間：建議為期3-5天?？啥虝r間內容集中進行用戶測試，或在工作日穿插進行測試。
• 結果整理時間：建議為期3天。用于整理測試信息、落實產品迭代任務、撰寫總結報告等。

（2）測試地點

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

（3）拉群通知

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

3. 測試物料

線下環(huán)境我這次準備了：

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

• 錄音設備：測試結束后需要進行詳細的信息整理，錄音資料可以幫助回憶溝通內容?？墒褂檬謾C自帶錄音功能或專業(yè)錄音筆。錄音前必須告知用戶，在征得許可后方能進行錄音。

• 錄屏設備：工具型產品的操作過程中涉及很多細節(jié)，錄屏資料可以幫助工作人員進行問題定位?？墒褂秒娔X自帶錄屏功能，或錄屏工具。

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

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

• 測試酬勞：具體可根據(jù)公司政策進行準備。

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

4. 組織人員注意事項

（1）積極發(fā)問+時刻觀察+及時記錄

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

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

（2）保持中立

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

（3）適當干預

如果在測試過程中遇到無法進行的情況，或者測試進度拖慢的情況，可以適當?shù)母深A。

（4）事后回顧

測試結束后，可以再次回顧過程中發(fā)現(xiàn)的問題。比如：參與者對于某些功能發(fā)表了看法，這時你可以層層挖掘，了解到底為何導致了他的這種看法。

或者錯過了發(fā)問的時機，還有就是碰到了不善于表達的用戶，可能沒有及時表達觀點?！澳鷦偛旁趚x頁面做了xx操作，能說一下為什么這么做嗎？”

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

六、正式測試

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

1. 開場介紹

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

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

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

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

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

需要注意的是：

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

2. 簡單熱場

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

• 詢問用戶背景以及產品使用情況。
• 讓用戶在執(zhí)行任務的過程中說出正在思考的內容（發(fā)聲思考法說明）。
• 確定用戶的手機型號，app版本號。
• “您使用產品的經驗有多久了？”
• “您玩過幾次劇本殺，是線上還是線下的，有沒有什么特別體驗好的回憶能分享下嗎？”
• “一般玩什么類型的劇本殺”

3. 測試任務、觀察記錄

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

需求池（設計師）：

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

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

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

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

隨時記錄用戶提出的問題。

4. 任務評分

（1）輔助工具

這些使用順序和方法【需求池】-【任務后評估量表問卷】-【系統(tǒng)可用性量表】-【用戶體驗問題記錄表】。

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

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

5. 事后訪談

如果發(fā)現(xiàn)訪談當時遺留遺留問題，聯(lián)系被訪者可進行簡短詢問感想、主觀評價、期望等。

• “今天請您使用了聲探社，請您談一談使用感受”
• “如果要綜合評價今天的體驗，十分是滿分推薦，您給聲探社打幾分呢？為什么？”
• （未達到滿意的情況）“假設現(xiàn)在我們要優(yōu)化評分，您認為哪個部分應該最優(yōu)先得到改善？”

系統(tǒng)可用性量表（用戶）：

這個是在整個測試完成之后，就讓他填寫打勾的去評價的。

這個我之前用的是翻譯版，會有用戶打分相斥的情況，于是我整理出來了一份解釋版，給大家參考一下。

6. 信息收集

需求優(yōu)化表（產品+設計）：

我們會將所有的問題記錄表，然后把它去排到整個的需求池里邊，然后再分優(yōu)先級組，可以再和產品經理再分優(yōu)先級。

七、整理結果數(shù)據(jù)分析

1. 歸類和分析問題

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

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

2. 系統(tǒng)可用性量表

（1）系統(tǒng)可用性量表的使用方法

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

3. 撰寫報告

再得到結果和改版方向之后，可以把整個過程再次復盤一下，可以按照總分總的形式去梳理。同時報告一定要高度總結，高度概括，條理清晰。從發(fā)現(xiàn)問題 – 解決問題 – 過程中做的不到位的地方去梳理。

#專欄作家#

郝小七，微信公眾號：七醬設計筆記，人人都是產品經理專欄作家。蜻蜓FM高級UI設計師，5年工作經驗。專注于體驗設計，歡迎各位同學一起交流。

本文原創(chuàng)發(fā)布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自 pexels，基于 CC0 協(xié)議。