編輯導語：可用性測試是一種常用且高效的測試方法。本篇文章中作者結合實際經驗系統的總結了可用性測試的整個過程，感興趣的小伙伴們快來一起看看吧，希望對你有所幫助。

在我們在工作中你是否經常會遇到這些問題：

• 我們用戶覺得產品不好用？用的過程中會不會遇到問題？滿不滿意？
• 設計的過程中有一些糾結的地方，不知道實際用戶是怎么理解和怎么操作的？
• 產品開發出來后，想在上線前檢驗一下，產品是否靠譜適不適合上線？

今天將介紹一種常用的設計驗證方法——可用性測試。

通過今天的文章，系統的總結可用性測試的整個過程，一起來看看吧~

一、可用性測試是什么

可用性測試是一種常用且高效的測試方法，在我們交互工作中，我們需要去做一些簡單的可用性測試來檢驗設計的合理性。

作為用戶研究類型中的一種，它與產品以及研發結合最緊密，常用于我們產品上線前后。

它通過觀察有代表性的用戶， 完成產品的典型任務，從而找到產品可用性問題，并解決這些問題，目的是為了改善產品讓產品更容易使用。

在時間上它越早介入越好，通過可用性測試可以提前預判風險，避免上線后再修改。

在測試內容上我們不僅可以對低保真、高保真進行可用性測試。有時候為了獲得一手信息，我們還可以對競品進行測試。

二、可用性測試類型

可用性測試類型分為形成式以及總結式兩種。

1. 形成式

3-5名測試者的小樣本為主，只需要1-2小時左右的測試時間，其核心目的在于快速發現問題、優化問題。

2. 總結式

它與形成式不同的是，它的樣本量較大，通常在30人以上。作為定量的評估方式，一般大型第三方調研公司會經常使用。

在互聯網工作環境中，由于更多的是快速迭代的敏捷研發，因此在實際的工作中我們更多的時候使用以發現問題為主的形成式可用性測試方式，它可以更好的和我們產品的研發周期緊密結合。

三、可用性測試的使用場景

在我們日常工作中可用性測試主要用于發現以下四類場景。

1. 發現問題

產品在體驗過程中是否存在問題。

2. 檢驗目標

查看當前的設計是否滿足用戶的期望，滿足了設計目標。

例如我們在頁面中想通過設計引導用戶去使用某個功能？

那么他在實際的使用中是否會注意到這個引導以及是否去使用？

他們在使用這個功能的時候會不會遇到一些障礙？

3. 評估產品

評估用戶對產品的滿意度。例如公司想在產品內新增一個功能，正式開發前想先測試一下用戶是不是滿意，針對這種場景也是適合做可用性測試做的。

4. 理解用戶

可用性測試則可以幫我們設計師以及產品經理更深入更詳細更直接的去了解用戶，了解用戶的使用習慣以及用戶認知。

四、可用性測試的流程總覽

可用性測試是一個不斷循環的過程，大體分為5個階段：測試準備、測試預熱、正式測試、結果分析以及最后的優化方案階段。

1. 測試準備

準備充分的可用性測試可以獲得更好的效果。在測試準備期間，我們要完成7個步驟的準備。

1. 確定目標
2. 測試方案
3. 測試腳本
4. 招募用戶
5. 材料工具
6. 測試場地
7. 預測試

Tips：雖然需要準備的東西較多，但是這些弄好后，后續的流程會輕松很多。

1）確定目標

• 對整個產品還是只是對新增模塊做可用性評估？
• 改版方案對新老用戶會產生什么影響？
• 改版是否能達到預計目標？
• 設計的時候存在有爭議，想看下哪種解決方案更合理？
• 某個環節流失率較高，想看下是否是設計上的原因導致？
• 針對這需要拓展的特殊用戶，在設計上是否需要做出調整？

以預期目標為例，比如說這次改版是解決之前遺留的體驗問題，是針對某一類用戶群體做優化還是想讓用戶留意到它想突出的體驗重點是什么。

2）測試方案

測試方案里面包含了研究目的、關注點、用戶招募、經費預算、時間計算、調研人員這幾點。

研究目的：明確測試的目的及范圍，它決定了后面測試方案設計；

測試關注點：需要與設計師協商梳理測試要關注的問題，例如哪些功能及流程需要著重關注，在設計過程中有什么糾結和疑問的點；

用戶招募：我們招募的用戶有什么樣的要求，需要招幾個人，用戶的配比如何，通過什么渠道招募用戶；

經費預算：招募到的用戶給予什么樣的獎勵，這里涉及測試成本的一個預算；

時間計劃：對測試有一個初步的時間規劃，有了這個時間規劃就可以讓團隊內部成員在參與上進行對齊；

3）測試腳本

測試腳本，也就是給用戶找點事兒做。我們可以通過在旁邊觀察用戶結合提問獲得我們想要的信息。

在時間上，測試腳本可以預先標明用戶到達測試場地后我們進行的流程有哪些，這些流程究竟是什么以及每一個流程預估耗時多久。

除了時間安排外，我們還需測試腳本里面重要的測試場景任務環節的設計。

我們在前面已經收集了此次要關注的點以及還要測試的任務和范圍。

我們可以事先把要測試的任務給羅列，把任務融入一些場景后再給到用戶。

比如說我們會說，你最近因為工作的需要需要為該設備添加人臉照片，然后你通過我們這個人臉識別系統后臺去創建人臉庫并選擇合適的照片進行添加。

以這樣一種完整的任務描述給到用戶，用戶接到信息之后就可以完成這樣的任務。這個場景描述最好是圍繞用戶真實的使用場景以及體驗目的去描述。

在場景任務的設計中我們要注意以下幾點：

1. 重點關注主要任務：產品涉及的細節很多，我們要把重點放在產品的主要任務或者此次有改變的任務流程上。
2. 從用戶角度出發：我們在設置任務的時候要按照用戶真實的使用習慣依次往下，不要有著跳躍性或者虛出的任務。
3. 明確起點和終點：我們在設置任務的時候要對用戶的流程有一個預期，比如他這個任務從哪里開始，在體驗的過程中達到什么頁面或者完成什么操作，就算是任務結束了。
4. 場景化的描述：任務要有一個場景化的描述，給用戶描繪一個貼合實際的場景，讓他在完成任務的時候更加貼近真實感。

4）招募用戶

招募多少用戶合適？

• 以發現問題為目的的形成式可用性測試一般招募4-5人合適；
• 如果產品復雜，以及為了覆蓋不同的人群差異，我們可以拓展到10-15人；

去哪里招募我們的用戶？

• 公司內部沒有參與本項目的同學
• 公司產品用戶庫
• 官微、公眾號、門戶網站等
• 第三方渠道

發送通知：

在完成用戶招募后我們需要發送一個測試通知給到用戶，包含測試時間、地點以及測試設備。在用戶招募中，我們有以下幾點需要注意：

• 圍繞測試目的，找出與測試目標有關篩選維度；
• 考慮用戶使用行為相關的特征，例如競品使用情況，使用產品的目的，用戶活躍程度；
• 挑選最核心的維度，轉化為用戶招募的條件，招募的條件在描述的時候盡量客觀化，具體化，可衡量；
• 學會辨別真假的用戶信息；

5）材料工具

測試過程當中要用到的素材：低保真原型、高保真原型或者是線上已經可以使用的產品

• 操作設備：測試過程中用戶群體使用的設備
• 工具：包括測試中在測試過程中需要填寫的量表工具
• 設備：攝像機或者錄音筆用來記錄測試者在測試過程中的反應

6）測試場地

我們團隊一般在做可用性測試的時候基本上在普通會議室完成，在測試期間控制會議室的人數，以免給用戶造成一定壓力，保證他在測試過程中的平穩發揮。

7）預測試

在做好前面的準備環節后，盡量留有時間做一個預測試，確保證我們正式測試的順暢進行。預測試一般可以做這么幾件事情。

首先作為測試人員，要對自己的產品做一個走查，記錄可能出現的問題，記錄下這些問題后再正式的測試。

其次找身邊的人來做一下預測試，通過這個可以提前發現測試流程當中存在的不合理的地方，及時對這些問題做優化和調整。

2. 測試預熱

預熱流程分為暖場、開場介紹、簡單介紹、測前體驗這4個流程。

1）暖場

測試前的5-15分鐘之內，主持人首先要先暖場，緩和他緊張的情緒，拉近用戶與我們之間的距離，讓其保持放松的狀態。

2）開場介紹

主持人向用戶介紹一下我們此次的測試目的、規則以及整個流程的時間，向他承諾我們此次測試記錄的保密性。

與此同時鼓勵同學在測試過程中對思考進行發聲，這一步特別重要，要求我們的用戶一邊操作一邊講出當前正在思考什么，比如遇到的疑惑之類；

3）簡單訪談

主持人需要與用戶做一個簡單的訪談，主要是為了了解用戶的基本信息以及產品使用情況，例如使用使用產品的目的、日常的使用習慣，有沒有用過比較好的類似產品等。

這個簡單的訪談不單為后續數據分析做參考還決定了我們后續訪談環節的題目是否調整。

4）測前體驗

做完簡單的訪談后，我們可以讓用戶先隨意的瀏覽以及簡單使用一下這個產品，了解用戶對這個產品的初步印象如何，品牌心智是否傳達，這一步UI同學比較關注。

3. 正式測試

經過了測試前的預熱，我們就進入了正式的測試環節，這一環節大概會耗時30至50分鐘。主要流程有測試觀察、測完評分、測完訪談3類。

1）測試觀察

在整個測試環節中，需要注意測試者的行為、想法以及記錄現場的觀察。

行為：用戶操作的動作、每一步的步驟以及最后的操作結果，這幾個都是要去核心觀察和記錄；

想法：用戶邊操作邊發生思考時候說的話，這些往往代表了用戶的真實想法以及以及對產品的理解，它是后續分析以及整理時候的重要資料（例如：User1：以為從這邊進入是注冊人臉庫，我看阿里、華為他們的產品就是這么做的。User2：這個作為系統配置入口可以理解，但作為人臉庫注冊入口真不是很清楚。User3：這個沒想到是注冊人臉庫而不是添加人臉照片的，其他軟件中還真沒見到）；

現場觀察：記錄一些比較明顯的問題或者簡單的分析，雖然這個問題你可能不知道這個問題是什么，但可以記錄下當前的現象；

我們要鼓勵做：

• 在行為上，留意用戶在操作過程中有什么異常，比如錯誤操作或者操作遲疑，這些都需要我們后續進行追問。
• 在表達上，然后我們需要認真傾聽用戶說過的話，理解這些話的潛臺詞；
• 在情緒上，觀察用戶是否有焦躁等不滿狀況，假如用戶實在無法完成當前的任務，必要的時候我們也可以選擇讓他們停止當前的任務；

不要做：

• 避免因用戶犯錯或者操作過慢而表現出消極的反饋情緒，這樣會干擾用戶的操作；
• 避免直接教用戶如何使用產品；
• 避免針對用戶提出的問題直接回答我們自身的想法，例如有測試人員向測試者提問為什么這樣什么時，我們要引導用戶回答他是怎么理解的；
• 避免用戶在任務測試過程中去追問，而是應該等到任務結束后再進行；
• 避免用戶遇到困難的時候去提供幫助，而是應該適當的鼓勵；

在測試過程中我們有2關鍵點要注意：

1. 用戶有沒有獨立的完成這個任務，如果沒有則說明當前的任務流程存在問題；
2. 然后看他在完成任務的過程中有沒有表現出不滿，如果有不滿情緒則說明我們當前的設計存在很明顯的可用性問題；

2）測完評分

該環節分為多任務評分以及當前任務評分，借助量表的形式，鼓勵用戶在完成測試任務后對當前的體驗的滿意度按照1-5進行打分。

及時的打分可以讓用戶更好的對當前的任務進行反饋，避免因為時間過長導致的細節遺忘。

Tips：因為SUS計數用的是0-4個距離，為了讓總分是100，所以在計算SUS總分時，我們要乘以2.5，這樣的結果才是最終產品可用性得分。

3）測完訪談

在用戶測試完之后，我們可以與測試者溝通做一些簡單的訪談。

• 測試者操作時候的主觀感受；
• 測試者異常操作時，我們沒有及時詢問的問題，比如為什么先選中這個元素，而不是另外一個地方；
• 周圍觀察的產品團隊可能也會對他們所關心的問題做一些詢問；
• 量表評分問卷中，留意用戶在哪些項目打高分哪些項目打低分，并針對用戶打低分的選項追問其背后的原因；

4. 結果分析

結果分析越早越好！設計師當場就針對問題進行討論或修改，拿新的方案立即進行測試，快速迭代我們的產品，這樣的效果其實最好。我們的結果可以做以下3步。

第一步：將觀察到的可用性問題分類（例如位置、任務）

第二步：按照影響程度、頻率、持續性、產品這4個維度對其進行嚴重程度的界定

• 5分：問題非常嚴重，用戶幾乎無法找到解決方案，以至于最終放棄操作
• 4分：問題嚴重，用戶遇到困難，但是可以自己找到解決方案
• 3分：問題中等，用戶遇到了困難，但是可以快速適應
• 2分：問題輕微，用戶可以輕易解決
• 1分：問題很小，基本上不影響系統可用性，但為了系統的完善，可以修改

第三步：Excel結果記錄（撰寫報告）

• 陳述該產品整體可用性如何，有無重大問題；
• 截圖并標注出具體模塊、位置的可用性問題，讓看報告的人可以快速定位問題所在；
• 把可用性問題的嚴重程度進行按照優先級進行排列；
• 針對當前的可用性問題提出修改的方案和建議；

5. 優化建議

可用性測試的最后，我們要根據測試結果給出相對應的優化方案，把優化的問題做一個追蹤表格，問題匯總后，看在下一個版本中有沒有改善。

五、寫在最后

以上就是有可用性測試的一些總結，希望大家通過該方法更好的驗證設計方案的可行性。如有疑問歡迎一起探討，一起成長~

本文由 @江鳥的設計生活 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議