可用性測試就是通過觀察用戶使用產品完成典型任務，發現產品中存在的效率與滿意度相關問題的方法。那如何進行可用性測試呢？這里有一份全面的指南。

什么是可用性？

任何與人可以發生交互的產品都應該是可用的，就一般產品而言，可用性被定義為目標用戶可以輕松使用產品來實現特定目標。

ISO9241/11中的定義是：

一個產品可以被特定的用戶在特定的場景中，有效、高效并且滿意得達成特定目標的程度。

人機交互專家 Jakob Nielsen 將可用性框架的定義為：

• 可學習性：初次接觸這個設計時，用戶完成基本任務的難易程度？
• 效率：用戶了解了設計之后，能多快地完成任務？
• 可記憶性：當用戶一段時間沒有使用產品后，是否能輕松地恢復到之前的熟練程度？
• 錯誤：用戶犯了多少錯誤，錯誤嚴重程度如何？用戶能否從錯誤中輕易地復原？
• 滿意度：用戶對產品的主觀滿意度，這個設計讓用戶感覺如何？

什么是可用性測試？

可用性測試，大多用于網站或移動應用的設計評估，其實也可以用于智能硬件的完整體驗流程，通常會邀請目標受眾群體中的真實用戶，在特定場景下通過產品完成典型的任務。

在真實的使用過程中觀察用戶的實際操作情況，詳細記錄并分析用戶在使用產品中遇到的問題，目的是發現產品中存在的可用性問題，收集定性和定量數據幫助產品改進，并確定目標用戶對產品的滿意度。

簡單來說，可用性測試就是通過觀察用戶使用產品完成典型任務，發現產品中存在的效率與滿意度相關問題的方法。

為什么要進行可用性測試？

可用性測試是改善產品的極佳方式。

有時，我們并不是產品的目標用戶，很多需求和設計方案是產品設計人員自己想出來的，在討論方案的時候總是說：”用戶想要…” 、”我覺得…” 、”如果是我，我會…”，雖然設計時會依據一些經驗與設計法則，但這些都只是未經驗證的主觀猜測而已，無法準確的評估設計方案的優劣，這往往導致觀點對立，僵持不下。

所以為了了解真相（用戶到底會怎樣使用產品），我們要找到我們的目標用戶并向他們學習（觀察他們如何使用產品），這樣才能使團隊盡快對設計方案達成一致并積極改善產品。

通過可用性測試，我們可以：

• 了解真實用戶如何與產品進行交互并；
• 了解真實用戶是否能夠完成指定任務；
• 了解真實用戶完成指定任務需要多久；
• 了解真實用戶對產品與競品的滿意度；
• 確定改進產品可用性問題所需的修改；
• 定性分析可用性并查看是否符合目標；
• 讓設計和開發團隊在開發前發現問題。

可用性測試類型

可用性測試的類型（進行可用性研究的原因）有三種：

1. 探索性可用性測試：在發布新產品之前，探索性可用性測試可以確定新產品應包含哪些內容和功能，以滿足用戶的需求。在產品開發早期，探索性可用性測試可以評估初步設計或原型的有效性和可用性。
2. 評估性可用性測試：在發布前或發布后對最新版本的測試，通過評估性可用性測試向用戶介紹新設計，以確保其直觀使用并提供良好的用戶體驗。評估性可用性測試的目的是——確保在產品推出之前突出并修復任何潛在問題。
3. 比較性可用性測試：比較兩種或更多種產品或設計的可用性，并區分各自的優缺點，以確定哪種設計能提供最佳的用戶操作體驗。

紙原型測試來源：mediamatic.nl

可用性測試方法

產品可用性測試方法分為分析法和實驗法。

1. 分析法

讓產品可用性工程師及用戶界面設計師等專家，基于自身專業知識和經驗進行評價的一種方法。

特點：主觀、評價結果是假設的、時間少、費用少、評價范圍廣、設計初期也可以評價。

分析法常用于可用性檢查階段，常見的分析法包括但不限于：

專家評審：評審由精通設計可用性概念的專家進行，基于自身專業知識與經驗對產品進行審查。

啟發式評估：讓可用性專家判斷每個頁面及元素是否遵循已確立的可用性原則。

認知走查：設計師模擬用戶在使用產品過程中的每個操作步驟所遇到的問題，檢查用戶的任務目標和心理認知是否可以順利執行下一步操作？

針對每步操作提出四個問題：

1. 用戶是否知道自己要做什么？
2. 用戶在探索用戶界面的過程中是否注意到操作方法？
3. 用戶是否把自己的目的和正確的操作方法關聯到一起？
4. 用戶能否從系統的反饋中判斷出任務是否在順利進行？

通過回答每個操作步驟的問題，就能發現可用性問題。

多元走查：認知走查的變體，使用小組會議，其中用戶、開發人員和人為因素讓人們在場景中逐步討論操作流程中的每個交互頁面及元素。

一致性檢查：讓代表多個其他項目的設計人員檢查界面，以查看它是否以與他們自己的設計相同的方式進行操作。

2. 實驗法

收集真實的用戶使用數據，比較典型的是用戶測試法，問卷調查等方法也屬于此類。

特點：客觀、評價結果是事實、時間長、花費大、評價范圍較窄、為了做評價，必須準備原型。

實驗法常用于可用性測試階段（用戶測試階段），常見的實驗法包括但不限于：

• 卡片分類：通常用于測試分類或導航結構，讓用戶將一組寫有信息的卡片分組，并為其分配名稱或標簽?？ㄆ诸愑兄诹私庥脩羧绾慰创齼热菀约八麄內绾谓M織信息，從而決定在每個頁面放置什么，對于頁面或功能分類很有幫助。
• 面對面測試：由一個或多個觀察者在諸如會議室的固定環境中運行，或者與小團體或個人進行。要求用戶完成一組任務，觀察者可以隨時與他們交互以提出問題或進一步探究。
• 遠程測試：在遠程測試中，用戶在自己的環境中執行一系列任務，通過軟件記錄完成任務的過程，軟件自動記錄用戶的點擊位置和交互過程，并記錄他們在使用網站或應用程序時發生的關鍵事件以及用戶提交的反饋。這種類型的測試可以由主持人（使用網絡研討會或電話會議技術）完成，也可以作為自我測試。
• A / B測試：為網站或應用程序的界面或流程制作兩個（A/B）或多個（A/B/n）版本，在同一時間維度，分別讓組成成分相同（相似）的訪客群組隨機的訪問這些版本，收集各群組的用戶體驗數據和業務數據，最后分析評估出最好版本正式采用。
• 走廊測試：使用隨機的人來測試網站，而不是那些在測試網站方面訓練有素和經驗豐富的人。這種方法對于在開發過程中首次測試新網站特別有效。
• 紙張原型測試：創建一個粗糙的，甚至是手繪的界面圖形以用作設計的原型。讓用戶通過原型來執行任務，該方法能以極低的成本在編碼完成之前對設計進行測試。
• 問卷調查：問卷的優勢在于可以收集結構化的數據，且價格低廉，不需要檢測設備，結果反映了用戶的意見。

分析法與實驗法的主要區別在于：是否有用戶參與其中？

分析法的參與者是具備可用性知識的設計師與工程師；而實驗法的參與者是目標用戶或小白用戶。從某種程度而言，分析法和實驗法是一種互補的關系。

一般，在設計用戶測試時，先在可用性檢查階段通過分析法去排查可用性問題，把排查出的問題按重要程度排序，然后在可用性測試階段通過用戶測試去重點觀察和驗證。

分析法的最大缺點是：它得到只是分析者的假設或觀點，在團隊意見不一致時，并不能夠提出支持自己意見的有力證據。為了結束爭論，就只能通過實驗法。

接下來重點介紹分析法中的啟發式評估法與實驗法中的一對一用戶測試。

可用性測試實驗室 來源：u-sentric.com

啟發式評估

1. 啟發式評估簡介

因為專家評審過度依賴于自身的專業知識與經驗，為了得到一個更客觀的結果，Jakob Nielsen根據多年可用性工程的經驗創造了啟發式評估法。

啟發式評估使專家按照公認的可用性原則，來審查用戶界面中的可用性問題，然后通過一系列原則對它們進行分類和評分。Jakob Nielsen的十種啟發式評估原則（尼爾森十大交互定律）是行業中最常用的可用性評估原則。

除此之外，還有Gerhardt-Powals的認知工程原理、Weinschenk和 Barker的分類、ISO 9421 對話原則等。

2. 啟發式評估原則

Jakob Nielsen倡導的啟發式評估十原則內容如下：

1. 系統狀態的可見性：系統應該在合理的時間內做出適當的反饋，始終讓用戶了解正在發生的事情。
2. 系統與現實世界的匹配：系統應使用用戶的語言，用戶熟悉的詞語和概念，而不是系統導向的專業術語。遵循現實世界的慣例，使信息以自然和合乎邏輯的順序出現。
3. 用戶控制和自由：用戶有時會誤操作，要提供任何時候都能從當前狀態跳出來的出口，保證能夠及時取消或者再運行執行過的操作（支持撤消和重做）。
4. 一致性和標準化：不應讓用戶懷疑不同的詞語、情況或行為是否意味著同一件事。保證用戶在同樣的操作下得到相同的結果。
5. 預防錯誤：提前預防錯誤的發生，這種防患于未然的設計要比適當的錯誤提示更勝一籌。消除容易出錯的條件或檢查它們，并在用戶采取行動之前讓用戶再次確認是否進行該操作。
6. 識別而不是回憶： 通過使對象，動作和選項等可視化，從而最大限度地減少用戶的認知負擔，使用戶無需回憶，一看就懂。盡量不要讓用戶從當前對話切換到別的對話時還必須記住某些信息，系統的使用說明應該是可見的，或者適當時可以輕易地檢索。
7. 靈活性和效率：加速器功能（初次接觸的用戶看不到該功能）通?？梢蕴嵘龑＜矣脩舻牟僮餍?，從而使系統能夠迎合無經驗和有經驗的用戶，允許用戶能夠單獨調整會頻繁使用的操作。
8. 審美和極簡主義設計：對話不應包含無關或極少需要的信息，對話中的每條附加信息都會與關鍵信息形成競爭，并降低其相對可見度。
9. 幫助用戶識別，診斷和從錯誤中恢復：錯誤消息應以簡單的語言表示，精確地表明問題，并建設性地提出解決方案。
10. 幫助和文檔：即使系統在沒有幫助文檔的情況下也可以使用良好，但還是有必要提供幫助和文檔。這樣的信息應該易于搜索，針對用戶要執行任務列出具體步驟。

3. 啟發式評估法的實施步驟

STEP 1：招募評價人員

Jakob Nielsen認為：一個人評價大約只能發現35%的問題，因此大概需要3~5人才能得到穩妥的結果，能夠勝任啟發式評估職位的人可以是用戶體驗設計師、交互設計師、UI設計師等。界面的原設計師是不適合評價界面的，因為評價結果可能會不夠客觀抑或是發現問題直接就進行修改而不會反饋。

STEP 2：制定評價計劃

評價產品的所有功能是比較困難的，所以要事先定好要評價界面的哪些部分，以及依據哪些原則進行評價（Gerhardt-Powals的認知工程原理、Weinschenk和 Barker的分類、ISO 9421 對話原則等）。

STEP 3：實施評價

最好對界面進行兩次評價：第一次檢查界面的流程是否正常，第二次詳細檢查各界面是否存在問題。評價人員之間應禁止相互討論，以避免評價結果被權威人士所影響。

STEP 4：召開評價人員會議

評價人員完成了各自的評價后，要集中開會以匯報評價結果，會議上描述問題的同時將界面顯示出來會更有效率。

啟發式評估的優點是：通過單獨評價和評價人員之間的討論這二次過濾，可以發現單獨一人不能發現的跨度較大的問題。

STEP 5：總結評價結果

匯總所有的評價結果后，就可以整合評價的問題列表了，可能會有一個問題存在多種表達方式，所以需要對問題列表進行適當的整理。

STEP6：輸出總結性報告

啟發式評估法的輸出成果就是產品可用性問題列表，但如果只給出列表，其他成員理解可能會比較困難，因此最好配上界面截圖、流程圖等輸出一份簡介的啟發式評估報告。

啟發式評估報告（HE報告）的內容主要包括：

1. 出現問題的界面和位置，關鍵事件或問題出現在用戶界面的哪個位置？
2. 啟發式的名稱，引用了十個啟發式原則中的哪一個？
3. 被評價為否定或肯定的原因，解釋為什么界面會違反或符合該啟發式？
4. 問題的范圍，描述問題的范圍，是貫穿整個產品還是在某個界面？
5. 問題的嚴重程度(高/中/低），評估問題的嚴重程度。
6. 評定其嚴重程度的理由，給它高/中/低的原因。
7. 修復建議，對問題的改進建議。
8. 可能的權衡（為什么修復可能會不起作用），提及這些權衡可以增加報告的可信度。

啟發式評估問題列表的示例

4. 啟發式評估法的局限性

平心而論，啟發式方法是打算作為一種幫助新手從業者進行可用性檢驗的“腳手架”，因此它無論如何都無法與專家可用性檢驗方法相提并論。而且，只有專家才能通過可檢驗方法發現問題，而不是使用啟發式方法的都是專家。

啟發式評估法是由多位專家基于自身經驗和啟發式原則，對用戶界面進行的評判，因此勢必會發現很多問題。而且實施啟發式評估法需要多名專家在限定的幾天內進行作業，所需成本也較高。

所以應結合實際情況對啟發式評估做簡化，可以只由一兩名專家進行簡單審查，這種做法被成為啟發法。不過在不提供客觀的判斷標準，且檢驗人員數量又少的情況下，評估結果可能會被指責“這些問題只是檢驗人員的主觀想法而已”。

因為資源有限而導致不能進行正規的啟發式評估，而改為簡易的審查時，要注意：

1. 不應以個人偏好，而應以理論依據進行評價。
2. 評價的目的不是挑錯，更應給出合理建議。
3. 當團隊意見不一致時，與其爭論不如通過實驗得出結論。

用戶測試方法 來源：rainforestqa.com

用戶測試

1. 用戶測試簡介

用戶測試，可用性工程師與用戶進行一對一訪談（理想情況下，觀察者與使用者彼此不認識，以便收集更多客觀數據），其他成員在監聽室觀察整個訪談，而且用戶操作計算機時的界面和聲音，全程都被錄像。

可用性測試的基本內容是相同的：為用戶構建一個場景，讓用戶通過產品完成特定任務，在用戶執行任務的過程中觀察他們遇到的問題。

2. 用戶測試的常見方法

（1）發聲思考法

發聲思考法就是讓用戶一邊說出心里想的內容一邊操作，操作過程中用戶能夠說出“我覺得下面應該這樣操作…”。這樣我們就能夠把握用戶關注的是哪個部分、他是怎么想的、又采取了怎樣的操作等信息，這是一種能夠弄清楚為什么會導致不好結果的非常有效的評估方法。

發聲思考法觀察的重點：

• 用戶是否獨立完成了任務？若不能獨立完成任務，頁面存在有效性問題。
• 用戶達到目的的過程中，是否做了無效操作或不知所措？如果有，頁面存在效率問題。
• 用戶是否有不滿的情緒？如果有則頁面存在滿意度問題。

（2）回顧法

讓用戶操作完后回答問題的方法。

回顧法的限制：

• 很難回顧復雜的情況。
• 用戶會在事后為自己的行為找借口。
• 回顧發比較耗時。

（3）性能測試

性能測試一般會安排在項目前后實施，目的是設置目標數值、把握目標的完成程度和改善程度。

測試主要針對產品可用性三要素（有效性、效率、滿意度）的相關數據進行定量測試：

1. 有效性可以用任務完成率來表示：有幾成的用戶可以獨立完成任務是檢驗里最重要的一個性能指標，這里的任務完成指用戶正確的完成了任務。
2. 效率可以用任務完成時間來表示：界面時為了讓用戶完成任務而設計的，因此能夠在最短時間內讓用戶完成任務的界面才是優秀的界面，所以需要檢測用戶完成任務所花的時間。最好限制每個任務的時間，在限定時間內未能完成任務，就被當做任務未完成。
3. 滿意度可以用主觀評價來表示：任務完成后，可以就“難易程度”、“好感”、“是否有再次使用的意向”等問題向用戶提問，并設置5~10個等級讓用戶選擇。

測試方法：發聲法和回顧法這樣的用戶測試都是一對一的形式，但性能測試是定量測試，參與測試的人太少可信度太低，也不能用來說明問題。因此經常以集體測試的形式進行，每1~2名用戶配備一位監督者，制定測試內容、確認完成任務、檢測任務完成時間等。

數據統計處理較多的心理學實驗里，一般至少會收集20~30人的數據。而且所謂20人是目標用戶的人數，因此整體而言需要40~60人。

原則上講，一次性能測試會測試多個用戶界面。如果只測試一個用戶界面，那么即時最終得到了任務完成率和平均時間，這些數值的好壞也沒有一個標準。通過對比競爭產品，比較多套方案，或者對比改版前后的數據，就能進行客觀評價了。（在讓每個用戶使用多個界面時，使用順序應該不相同，這可以避免使用順序帶來的影響。）

性能測試的限制：當任務完成率只有20%時，團隊只知道這個任務的執行效率很低，但不知道用戶究竟是為什么沒能完成任務，因此會感覺無所適從。

發聲思考法可以解決這個問題，但實際操作過程中，只要采訪人員不提問，用戶就不會主動說話。如果提問的話，用戶又可能就會停下手上的動作進行說明，這樣一來測試完成任務的時間就沒意義了。

缺少發生思考的性能測試沒有任何意義，但如果同時實施這兩種方法，又需要很大預算。所以只要還未明確定量數據的必要性，就不應實施性能測試。我們沒必要把有限的資源浪費在定量數據的測試上。相反，反復進行的發生思考法這種只需幾個人參加的測試，可以更好的改善界面。

3. 用戶測試的實施步驟

STEP 1：設計任務

可用性評估是基于任務的，任務設計的優劣能直接影響測試結果的準確性。所以在招募用戶前，應先針對產品設計任務。比如：一個購物類APP設定的任務可以是：購買一件價格高于100元的T恤。

想要設計出合適的任務須注意以下幾點：

（1）選擇最核心的功能或操作流程作為任務

一個產品可以執行很多任務，不可能把所有任務都執行一次。所以應采用精益思維，把有限的資源放在最有價值的環節上，產品最核心的功能或操作流程往往是最頻繁被用戶使用的地方。

如果這里還存在可用性問題，那么就算改善了其他邊緣地帶的可用性問題，依然對產品整體體驗于事無補，所以設計的任務要以核心功能和操作流程為主。

（2）任務應符合常規操作流程

有時設計者會把自己想要用戶做的事當任務來測試，但實際用戶并不是按設計者想的流程去完成任務的。而且由于測試的任務較多，設計者為省事有時會把多個小任務合并為一個大任務，這樣做有時是可以的，但如果小任務之間的操作流程存在沖突，用戶測試的操作流程就是不合乎常規的。

也就是說，用戶實際在執行的任務在正常使用產品的時候，根本不會出現或極少出現，這樣的測試的結果準確性令人堪憂，且還會給參與測試的用戶造成困惑。

（3）為任務創建一個應用場景

簡短的場景描述會會對用戶執行任務有所幫助。比如：任務是“購買一件價格高于100元的T恤”，我們可以創建這樣一個場景——你的同事過生日了，你想挑一件一百多塊的T恤給他，請使用XX APP來完成T恤的購買。

這樣給了用戶一個執行任務的理由和目的，不會使任務變得突兀，而且用戶也會變得有代入感從而更好的理解并執行任務。注意場景描述里不要涉及用戶的直系親屬，沒人知道他們的經歷，以免引起用戶的情緒反應。

（4）明確任務的起點和終點

判斷用戶是否完成了任務的主要依據就是：用戶是否從起點（頁面A）到達了終點（頁面B）。

所以要清晰的定義，哪個頁面是起點？哪個頁面是終點？起點未必一定要是首頁，起點位置應根據具體場景來確定，畢竟并不是每個任務都是從首頁開始的。比如：任務是“購買一件價格高于100元的T恤”，那么起點頁面可以是APP的首頁，終點頁面就是付款成功頁面。

不過除了檢查是否到達終點，可能還要檢查一些關鍵信息，比如：用戶購買的T恤價格是否高于100元、用戶是否正確填寫了地址等。如果沒有，那么我們要搞清楚原因是什么？

（5）任務不應過于簡單

如果想測試用戶是否可以找到某功能，不要用類似“找到XX功能按鈕”這樣的描述，我們應該給用戶提供一個要處理的現實任務，而不只是定位功能的位置?！罢业酵丝罟δ馨粹o”應改為“購買一件T恤并退款?！?/p>

（6）避免提供線索和描述操作步驟

任務應給出具體目標，而不是操作步驟。

以買T恤的任務為例：如果告訴用戶“搜索T恤，然后選擇數量和顏色，填寫地址并確認訂單，最后進行支付”，那么用戶在執行任務時的思路可能是這樣的：找T恤、找數量選擇按鈕、找顏色選擇按鈕、找填寫地址的位置、找訂單確認按鈕、找支付按鈕，一個完整的核心任務就這樣被拆分成了多個確認功能按鈕位置的操作，引導性過強的任務失去了測試的意義。

這樣做會錯過用戶在任務中，執行到某一步驟時可能提供的寶貴反饋。因為用戶一開始可能并不知道會有這些操作步驟，可能會因一些額外的操作感到驚訝或煩惱。而且用戶在實際使用產品時，考慮的是使用目標，而不是具體的操作和功能。

因此，一定要避免提供線索和操作步驟給用戶。

STEP 2：招募用戶

（1）要根據資金預算和日程安排來招募用戶，并給予他們一些報酬（小禮物即可）

招募對象的選擇理論上應該是產品的典型目標用戶，但是仍然需要定義具體的用戶特征——即招募條件。

招募條件可以從早期市場調研階段中建立的用戶畫像中提取用戶特征，要盡可能的代表將來的真實用戶。如果目標用戶畫像分為幾類，那就要求招募的用戶中要包括所有類型的用戶。

被招募的用戶應具備使用產品執行任務的能力，比如：我們一定不會找電腦都不太會使用的人來體驗桌面軟件。

通常我會找兩類用戶來體驗產品：

• 一類是有同類型產品使用經驗的用戶；
• 另一類是完全沒使用過類似產品的用戶。

因為我的產品目標是降低同類產品的操作復雜度，讓小白用戶也能輕易上手，通過這兩種用戶可能會發現截然不同的問題。

（2）接下來要確認所要招募的用戶數量

Jakob Nielsen提出過一個法則：有5人參加的用戶測試，即可發現大多數（85%）的產品可用性問題，而且通常最嚴重的問題都是前幾名用戶發現的，隨著用戶數量的增多，發現的問題逐漸減少，被發現的問題數量與測試用戶的數量的關系如下圖所示。

但它也存在一些局限性，比如：它只能說明發現的問題的數量，但不能確認所發現問題的嚴重程度（還有很多局限性在此不一一列舉）。所以我們要根據我們的實際情況，來確定要招募的用戶的數量，查看每次測試的結果與迭代效果，看看是否值得投入更多資源來做可用性測試。

Resource: Nielsen Norman Group

（3）關于招募渠道

如果時間精力充裕，可以從網絡問卷和在市場調研階段的渠道，邀請外部用戶進行測試。反之，則可以充分利用身邊的資源——同事和朋友，但不要找項目組內部的成員，因為他們對產品過于了解，會影響測試結果的有效性。

STEP 3 ：準備工作

（1）測試地點與工具的準備

專業的用戶測試一般在實驗室內進行，實驗室有觀察室與操作室，測試人員與用戶在操作室進行可用性測試，其他團隊成員在觀察室中觀察，兩個房間之間通常由單面鏡隔開。

操作室內無法看到觀察室的情況，而觀察室能看到操作室的情況。通常觀察室中還需要配備電腦或投影儀，實時顯示操作室中正在被用戶操作的用戶界面。但絕大多數公司往往不具備這樣的條件的實驗，這時我們找一間安靜的會議室就可以了。

測試人員與用戶在會議室進行測試，如果是PC端軟件的測試，可在PC預安裝錄播或直播軟件，便于其他成員觀看用戶操作的流程與表情。如果是手機端軟件的測試，可以直接使用同屏功能，團隊其他成員直接在另外的PC上觀看用戶的操作即可。

推薦使用能同時錄制屏幕和用戶表情具備畫中畫功能的軟件，因為觀察用戶屏幕幫助我們了解用戶做了什么，觀察用戶表情可以了解用戶的情緒（困惑、惱怒等）。

總之，方法和工具有很多，只要不影響用戶測試并便于團隊成員觀察即可。

（2）任務相關資料的準備

要準備任務提示卡，一張用于記錄用戶要完成的任務的卡片，有些任務可能比較復雜，這樣可以更準確的傳達任務信息，且便于用戶主動查看。

還要為自己準備一份數據收集表格，用于收集任務相關數據，如任務是否完成、完成時間等，還要有用于記錄關鍵事件和在測試過程中觀察到的用戶體驗問題的表格，比如：設計可能存在的問題及原因等。

（3）相關文件的準備

更專業的用戶可用性測試，會與用戶簽署一些協議。

比如：

1. 用戶知情同意書，用于聲明用戶是自愿參加評估的并允許我們獲取和使用數據。
2. 可用性測試說明文件，簡單概述測試目的與對用戶的期望以及用戶要遵守的規則等。
3. 保密協議，防止用戶泄露產品信息。
4. 問卷與調查，充分了解用戶的背景。

有的測試可能還會用到培訓資料，比如：某些復雜的智能硬件，可能需要用戶先閱讀說明書后再執行任務，諸如此類在此不過多闡述。

（4）可用性測試劇本的準備

可用性測試劇本指我們從接觸用戶、開場白、開始測試、事后訪談、給予獎勵并送走用戶的整個過程中要執行的行為與臺詞的集合，測試人員通過執行劇本中的內容來推動可用性測試的進行。（別忘了準備報酬）

4. 可用性劇本示例

• 評測對象：XX購物APP。
• 招募條件：一二線城市90后，有在線購物的經歷。
• 參與者人數：5名。
• 測試時間：60分鐘。
• 酬勞：咖啡一盒。

（1）開場白（3分鐘），說明訪談目的和基本流程，簽訂錄像許可與保密協議等文件

常用話術：您好，我是XX購物APP的可用性工程師，很高興見到您。今天由我來和您做這次測試，這次測試的目的是測試我們的產品是否便于用戶使用，接下來會拜托您通過APP執行幾個任務，執行任務的過程我們需要通過攝像頭記錄下來，以便于我們的重復觀察與分析。還要麻煩您對本次測試的內容進行保密，如果沒有什么疑問，請您在這些協議上簽字，謝謝。

（2）事前訪談（5~10分鐘），了解用戶背景，也可通過問卷來獲取信息

常用話術：方便透露下您的年齡/職業嘛，說個范圍就可以，比如：20~30/某個行業。您是否有用過類似的在線購物產品？有的話，感覺怎么樣？感覺優點/缺點有哪些？如果沒有，您購物是通過什么方式呢？通過什么方式支付呢？

（3）測試說明（5分鐘），說明測試內容與用戶應遵循的相關規則。

常用話術：接下來請您使用我們的APP購買一件商品，任務的細節和背景都寫在這張卡片上了。需要強調的是：我們的APP只是一個初步版本，我們已經知道它存在一些體驗上的問題，想通過您的使用驗證這些問題，所以如果遇到了什么問題，都是產品設計的問題，操作失敗了也請不要放在心上。

在操作過程中，希望您能一邊操作一邊告訴我您要進行什么操作？您為什么要這么操作？您是怎么想的？這對我將非常有幫助。

最后，您在操作過程中最好不要向我提問，因為如果我告訴了您如何操作，我可能就無法找到產品中的問題了。所以如果您問我問題，我沒有答復您，還請見諒。

（4）觀察測試（30~40分鐘），觀察并記錄用戶在執行任務中遇到的問題

假設目標任務為——購買一件100元以上的T恤，起點為首頁，終點為付款成功頁。

常用話術：假設您的同事過生日了，您想送他一件100元以上的T恤，請使用這款APP進行購買。

（5）事后訪談（5~10分鐘），通過回顧法詢問用戶在執行任務中遇到的問題

常用話術：您剛才用這款APP進行了一次購物體驗，能談談您的感想嗎？

比如：覺得哪里比較好？哪里比較差？對比您之前使用過的同類APP感覺如何？如果要綜合評價這次購物體驗，您會給它打幾分呢？給之用過的同類產品打幾分呢？為了使產品體驗更好，您覺得我們有哪些需要改進的地方呢？

雖然主流觀點認為不該問用戶產品哪里需要改進，因為改進產品是設計者的事情，用戶給出的也只是基于自身經驗的主觀解決方案。但是如果針對用戶的答案，繼續深挖“為什么”，可能就會知道用戶真正想要的結果是什么。

（6）結束語（3分鐘），對用于表示感謝，并初始化實驗室準備測試下一位用戶

常用話術：今天的測試到此為止啦，感謝您的配合，這次測試的數據對我們非常有用，我們為您準備一盒咖啡以表謝意，請笑納哈。（接著送走用戶就好）

STEP 4：試點測試

試點測試可以理解成可用性測試之前的彩排，無論進行了多么周密的計劃，不實踐一下是不會發現計劃中的問題的，試點測試的目的就是對測試計劃進行測試，以便于發現測試計劃中的疏漏，及時修復，以免浪費測試資源。

試點測試的用戶一般找同事充當即可，但要保證測試的地點和相關資料都與實際測試時完全一致。

然后即可開始可用性測試的流程，要重點關注：

• 臺詞和任務卡片的設計，是否可以準確傳達信息？
• 臺詞和任務卡片是否透露了操作步驟，用戶是否很快的完成任務？
• 任務時間安排是否合理，用戶是否可以在規定時間內完成任務？
• 任務流程安排是否合理，用戶是否感到莫名其妙？

最后，根據試點測試中發現的問題，對測試計劃進行修復，完善測試計劃。

STEP 6：觀察&訪談

（1）邀請關鍵干系人觀察測試

建議邀請產品的核心研發、設計師、項目經理等來觀察測試，因為這樣可以是測試結果更有說服力。如果沒有這些人來觀察測試，測試結果得可信度對他們來說就大打折扣。因此，越多關鍵干系人觀察到了測試，越有利于后續產品優化方案的執行。

（2）不要干擾用戶執行任務

進入正式測試環節后，測試人員就不能像在事前訪談一樣不斷的像用戶提問了，用戶測試的主角是用戶，測試人員應安靜的觀察用戶的操作并記錄，不要干擾用戶執行任務。

當用戶對當前操作存在疑問時，比如：“我現在可以按這個按鈕嗎？”

測試人員不可以直接回答用戶應該如何操作，以及每個按鈕代表什么。也不可以無視用戶的問題，因為這樣可能會引起用戶的不滿情緒。

此時，最合適的方式應該是回復“您覺得應該是怎樣呢？是什么讓您覺得應該是這樣？您怎么想就怎么做，沒關系的?！卑褑栴}推回給用戶，并讓其有一定安全感，做錯了也沒關系。我們只負責告訴用戶“做什么”，至于“怎么做”這是要用戶通過操作反饋給我們的信息。

（3）適當干預用戶的操作

用戶測試中最常用的方法就是發聲思考法，它要求用戶在進行操作的同時將所思所想大聲說出來，以便測試人員了解用戶的心理活動，以及用戶在每個操作流程中關注了哪些元素，如何看待這些元素？知道了這些才能更好的根據用戶心智模型來改進產品。

但在實際測試中，用戶很少會把自己所思所想直接說出來，有的是因為害羞；有的是因為感到不自在，難以做到。

這時就需要測試人員進行適當的干預，比如：您正在看什么呀？您現在想進行什么操作呀？這是否和您的預期一致呀？通過這類問題試探用戶的想法，并鼓勵其發生思考。

原則上，只要用戶操作的很順利就不需要人為干預，我們只在用戶碰到問題時進行干預，進而了解用戶遇到了什么問題。用戶的困惑除了發生思考，還可以從其肢體語言表達出來。比如：用戶皺眉、發出語氣詞、喘粗氣、清嗓子、撓頭、突然停下動作等，這都暗示了用戶在當前界面遇到了麻煩，所以測試人員應重點留意用戶的肢體語言。

但切忌幫助用戶進行預判斷和給予用戶提示，比如：“這個按鈕可能設計的不太合理…”。測試人員只負責觀察和記錄用戶的行為，不能引導用戶操作和幫助用戶判斷。

（4）重點觀察和記錄用戶在什么界面說了什么做什么了

記錄這些客觀事實即可，不要帶著自己的觀點去觀察，比如：為了證明某個設計是對的/錯的，帶著尋找證據的心態去觀察可能會忽略一些信息，因為人們只看到自己想要看到的。

記?。何覀円涗浀氖强陀^事實，而不是自己基于客觀事實的推斷和分析?？赡芪覀兛吹接脩舻牟僮餍睦眈R上就有了一個推斷，這沒問題，但要區分出客觀事實和推斷。因為分析，是這個階段收集完數據之后在下一個階段應該做的事。記錄問題的同時，也要關注用戶操作流暢的地方，避免最后修改了不必修改的地方。（記錄的數據，是繪制用戶體驗地圖的關鍵）

（5）使用回顧法進行提問

有時，用戶測試中出現了問題，但出于某種原因我們不便于打斷用戶深入提問，或者用戶通過發生思考法遺漏了某些信息。這時，測試完成后，測試人員要對測試中發生的問題進行提問。

比如：“您剛才在XX界面停留了很久，能告訴我當時您在思考什么嗎？”這樣就能通過回顧法補全測試中遺漏的信息。

STEP 7：分析

（1）整理數據，判斷產品是否需要迭代

通過用戶測試，我要們判斷交互設計是否滿足了用戶體驗目標水平。分析數據的第一步是整理出測試結果，通常要繪制一份表格，表格內容通常包含：任務、用戶體驗目標、任務基準值、任務目標值、是否完成目標等信息。

如下圖所示：

可用性測試數據整理表的示例

接著我們直接通過比較觀測結果和用戶體驗目標，就可以知道哪些用戶體驗目標已經達到、哪些沒有達到。如果體驗目標沒有達到且資源充足，那么產品就需要進行迭代。這時就要具體分析每個用戶體驗問題，并輸出解決方案。

（2）分析問題的影響程度

并非所有的問題都是平等的，一些問題會帶來負擔，用戶必須先處理才能繼續原來的問題。其他錯誤可能會帶來用戶的情緒問題，讓用戶重復操作，但不會引發新的問題。

了解問題的嚴重性，能幫助我們更好的對用戶體驗問題優先級進行排序，我們通過問題性質和問題發生頻率來確定問題的影響程度。

問題性質，一般要通過效果問題＞效率問題＞滿意度（或者速度＞錯誤＞滿意度）的順序來評價問題的性質。

效果相關問題導致用戶無法完成或幾乎無法完成任務，效率問題導致用戶做無用功，或過多思考、執行更多錯誤操作。滿意度問題導致用戶表達不滿意情緒，問題發生頻率，通過發現問題的人數來決定。

不管測試了多少人，我們用三個范圍來表示頻率：1個人、幾個人、所有人（幾乎所有人）。比如：10個人可能就被分為：1個人、2~7人、8~10人三個范圍。

然后我們基于問題性質和發生頻率建立一個表格，如下圖所示：

問題影響度分析表的示例

列代表問題發生頻率，行代表問題性質。把標記黃色的問題定義為必須要解決的問題，把標記綠色的問題標記為最好去解決的問題，把標記為藍色的問題標記為資源充沛的話，可以去解決的問題。資源總是有限的，不可能每個問題都去修復，我們必須通過分析問題的影響程度確定要修復的問題。

（3）制作用戶體驗問題描述

以表格來維護用戶體驗問題的數據比較簡略，不利于其他人了解詳細情況和參考，所以我們需要對每個問題進行一些信息補充，讓用戶體驗問題的實例在數據分析中變得更有價值。

我們需要做的就是——了解每個問題及其產生的原因和可能的解決方案，將表示同一個用戶體驗問題的多個用戶體驗問題進行合并（肯定會有重復出現的問題），并認清各個問題之間潛在的關系。

一份用戶體驗問題描述通常包含如下信息：

• 問題概述：從用戶角度描述產品存在的問題，比如：“沒有返回按鈕”應描述為“用戶無法返回上一級頁面”。
• 用戶任務：提供問題發生的背景，幫助我們了解用戶想進行什么操作時發生了什么樣的問題。
• 用戶目標：一個任務可能會分為多個目標，用戶目標描述用戶具體為了達到什么目標時碰到的問題。
• 問題詳述：對用戶體驗問題詳細的描述，比如：用戶在什么頁面，進行了什么操作，界面發生了怎樣的交互等。
• 問題分析：從設計師角度對問題進行分析，比如：為什么產品沒有按用戶期待的方式運行？是什么導致了用戶無法完成任務或產生消極情緒？這樣的解釋會往往會為可行的問題解決方案提供線索。
• 解決方案：針對問題產生的原因提出可能的解決方案。

STEP 7：重新設計

通常來講，我們會針對每個問題，給出一個解決方案。但事實往往并非如此，問題和解決方案之間有時并不是一一對應關系。如果針對每個問題都給出解決方案，可能導致產品的復雜度提升。

有時，一個解決方案就能解決多個問題，這就需要我們對每個問題的聯系及其產生原因有深刻的洞察，若是能從根本解決問題，產品的品質會得到極大提升。

這需要我們跳出原有的一對一的思維，先從宏觀層面整體分析這些問題組，而不是孤立的一個個問題。在設計出解決方案后，還要對解決方案的成本和優先級等信息進行梳理，以便于更好的管理問題&解決方案信息表格，可以把這些用戶體驗問題與其解決方案當做產品需求來管理。

如下圖所示：

問題&解決方案信息表的示例

要注意的是：不要以為按照設計方案修復好，用戶體驗問題就已經解決了。解決方案也只是我們的假設而已，假設這個修復方案可以解決問題，所以為了驗證假設，我們要不斷的通過可用性測試來驗證新的方案。

這是一個貫穿產品開發過程持續循環的過程：不斷的發現問題-分析問題原因-修復問題-測試問題是否已得到解決。對設計進行修改可能會使用戶體驗變得更糟糕，所以設計時要考慮用戶體驗問題修復是否會造成新問題。

STEP 8：輸出可用性測試報告

可用性報告的價值在于：記錄評估過程，幫助組織內部了解測試過程和內容。為產品開發過程提供有價值的信息，開發團隊知道了問題所在才能更好的執行開發。

傳達信息，并說服干系人，可用性測試報告可以有理有據的告訴干系人，我們的結論并非憑空產生，便于資源的申請。除此之外，還可以傳遞評估結果，樹立用戶體驗意識等。

可用性報告的內容一般包括：

• 對產品的描述。
• 測試目標。
• 對參與者數量和畫像的描述。
• 測試時所執行的任務。
• 測試的實驗設計。
• 采用的評估方法。
• 采用的可用性度量指標和數據收集方法。
• 數據結果，包括圖形可視化的展現。
• 對問題的描述。
• 對產生問題原因的分析。
• 對問題的嚴重程度和影響范圍的評估。
• 建議的解決方案。

可用性測試常見問題

（1）可用性測試在設計過程中進行的太晚

如果你等到產品發布之前才想到可用性測試，你就沒有時間或金錢去修復任何問題 ，更糟糕的是你可能會以錯誤的方式，浪費大量精力開發可用性很差的產品。

其實，在整個產品研發周期內反復進行小規模的測試是最合適的，在產品完成初步原型時，就可以先進行可用性測試，快速發現問題，及時修改，避免上線后修改帶來的成本浪費。

（2）覺得可用性測試很專業，且要花費大量人力財力，所以干脆不做

因為收益無法量化，項目排期又比較緊張，所以總被忽略掉。其實可用性測試門檻很低，不必等產品做好才開始，不一定非要由專家來做，更不一定要求專業的設備。只要能有一個環境觀察用戶操作產品，或多或少都會發現一些可用性的問題。

其他小問題就不多闡述了，希望本文對讀者有所幫助。由于作者接觸可用性測試也沒有多久，文中難免有不足之處，有問題的地方和描述不清楚的地方，還望請讀者多多指正，感謝。

參考文獻

• 10 Usability Heuristics for User Interface Design
• Comparison of usability evaluation methods
• Reporting Usability Test Results
• Write Better Qualitative Usability Tasks: Top 10 Mistakes to Avoid
• Turn User Goals into Task Scenarios for Usability Testing
• Reporting Usability Test Results
• An Introduction To Website Usability Testing
• running-usability-tests
• 可用性測試(Usability Testing)小撇步
• 破繭成蝶
• UX權威指南
• 用戶體驗與可用性測試

本文由 @少穻 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖作者提供