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

什么是可用性？

任何與人可以發(fā)生交互的產(chǎn)品都應(yīng)該是可用的，就一般產(chǎn)品而言，可用性被定義為目標用戶可以輕松使用產(chǎn)品來實現(xiàn)特定目標。

ISO9241/11中的定義是：

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

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

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

什么是可用性測試？

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

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

簡單來說，可用性測試就是通過觀察用戶使用產(chǎn)品完成典型任務(wù)，發(fā)現(xiàn)產(chǎn)品中存在的效率與滿意度相關(guān)問題的方法。

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

可用性測試是改善產(chǎn)品的極佳方式。

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

所以為了了解真相（用戶到底會怎樣使用產(chǎn)品），我們要找到我們的目標用戶并向他們學習（觀察他們?nèi)绾问褂卯a(chǎn)品），這樣才能使團隊盡快對設(shè)計方案達成一致并積極改善產(chǎn)品。

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

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

可用性測試類型

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

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

紙原型測試來源：mediamatic.nl

可用性測試方法

產(chǎn)品可用性測試方法分為分析法和實驗法。

1. 分析法

讓產(chǎn)品可用性工程師及用戶界面設(shè)計師等專家，基于自身專業(yè)知識和經(jīng)驗進行評價的一種方法。

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

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

專家評審：評審由精通設(shè)計可用性概念的專家進行，基于自身專業(yè)知識與經(jīng)驗對產(chǎn)品進行審查。

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

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

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

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

通過回答每個操作步驟的問題，就能發(fā)現(xiàn)可用性問題。

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

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

2. 實驗法

收集真實的用戶使用數(shù)據(jù)，比較典型的是用戶測試法，問卷調(diào)查等方法也屬于此類。

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

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

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

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

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

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

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

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

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

啟發(fā)式評估

1. 啟發(fā)式評估簡介

因為專家評審過度依賴于自身的專業(yè)知識與經(jīng)驗，為了得到一個更客觀的結(jié)果，Jakob Nielsen根據(jù)多年可用性工程的經(jīng)驗創(chuàng)造了啟發(fā)式評估法。

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

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

2. 啟發(fā)式評估原則

Jakob Nielsen倡導的啟發(fā)式評估十原則內(nèi)容如下：

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

3. 啟發(fā)式評估法的實施步驟

STEP 1：招募評價人員

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

STEP 2：制定評價計劃

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

STEP 3：實施評價

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

STEP 4：召開評價人員會議

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

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

STEP 5：總結(jié)評價結(jié)果

匯總所有的評價結(jié)果后，就可以整合評價的問題列表了，可能會有一個問題存在多種表達方式，所以需要對問題列表進行適當?shù)恼怼?/p>

STEP6：輸出總結(jié)性報告

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

啟發(fā)式評估報告（HE報告）的內(nèi)容主要包括：

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

啟發(fā)式評估問題列表的示例

4. 啟發(fā)式評估法的局限性

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

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

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

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

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

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

用戶測試

1. 用戶測試簡介

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

可用性測試的基本內(nèi)容是相同的：為用戶構(gòu)建一個場景，讓用戶通過產(chǎn)品完成特定任務(wù)，在用戶執(zhí)行任務(wù)的過程中觀察他們遇到的問題。

2. 用戶測試的常見方法

（1）發(fā)聲思考法

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

發(fā)聲思考法觀察的重點：

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

（2）回顧法

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

回顧法的限制：

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

（3）性能測試

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

測試主要針對產(chǎn)品可用性三要素（有效性、效率、滿意度）的相關(guān)數(shù)據(jù)進行定量測試：

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

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

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

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

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

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

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

3. 用戶測試的實施步驟

STEP 1：設(shè)計任務(wù)

可用性評估是基于任務(wù)的，任務(wù)設(shè)計的優(yōu)劣能直接影響測試結(jié)果的準確性。所以在招募用戶前，應(yīng)先針對產(chǎn)品設(shè)計任務(wù)。比如：一個購物類APP設(shè)定的任務(wù)可以是：購買一件價格高于100元的T恤。

想要設(shè)計出合適的任務(wù)須注意以下幾點：

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

一個產(chǎn)品可以執(zhí)行很多任務(wù)，不可能把所有任務(wù)都執(zhí)行一次。所以應(yīng)采用精益思維，把有限的資源放在最有價值的環(huán)節(jié)上，產(chǎn)品最核心的功能或操作流程往往是最頻繁被用戶使用的地方。

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

（2）任務(wù)應(yīng)符合常規(guī)操作流程

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

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

（3）為任務(wù)創(chuàng)建一個應(yīng)用場景

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

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

（4）明確任務(wù)的起點和終點

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

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

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

（5）任務(wù)不應(yīng)過于簡單

如果想測試用戶是否可以找到某功能，不要用類似“找到XX功能按鈕”這樣的描述，我們應(yīng)該給用戶提供一個要處理的現(xiàn)實任務(wù)，而不只是定位功能的位置。“找到退款功能按鈕”應(yīng)改為“購買一件T恤并退款?！?/p>

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

任務(wù)應(yīng)給出具體目標，而不是操作步驟。

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

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

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

STEP 2：招募用戶

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

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

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

被招募的用戶應(yīng)具備使用產(chǎn)品執(zhí)行任務(wù)的能力，比如：我們一定不會找電腦都不太會使用的人來體驗桌面軟件。

通常我會找兩類用戶來體驗產(chǎn)品：

• 一類是有同類型產(chǎn)品使用經(jīng)驗的用戶；
• 另一類是完全沒使用過類似產(chǎn)品的用戶。

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

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

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

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

Resource: Nielsen Norman Group

（3）關(guān)于招募渠道

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

STEP 3 ：準備工作

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

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

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

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

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

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

（2）任務(wù)相關(guān)資料的準備

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

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

（3）相關(guān)文件的準備

更專業(yè)的用戶可用性測試，會與用戶簽署一些協(xié)議。

比如：

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

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

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

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

4. 可用性劇本示例

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

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

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

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

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

（3）測試說明（5分鐘），說明測試內(nèi)容與用戶應(yīng)遵循的相關(guān)規(guī)則。

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

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

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

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

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

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

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

常用話術(shù)：您剛才用這款APP進行了一次購物體驗，能談?wù)勀母邢雴幔?/p>

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

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

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

常用話術(shù)：今天的測試到此為止啦，感謝您的配合，這次測試的數(shù)據(jù)對我們非常有用，我們?yōu)槟鷾蕚湟缓锌Х纫员碇x意，請笑納哈。（接著送走用戶就好）

STEP 4：試點測試

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

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

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

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

最后，根據(jù)試點測試中發(fā)現(xiàn)的問題，對測試計劃進行修復，完善測試計劃。

STEP 6：觀察&訪談

（1）邀請關(guān)鍵干系人觀察測試

建議邀請產(chǎn)品的核心研發(fā)、設(shè)計師、項目經(jīng)理等來觀察測試，因為這樣可以是測試結(jié)果更有說服力。如果沒有這些人來觀察測試，測試結(jié)果得可信度對他們來說就大打折扣。因此，越多關(guān)鍵干系人觀察到了測試，越有利于后續(xù)產(chǎn)品優(yōu)化方案的執(zhí)行。

（2）不要干擾用戶執(zhí)行任務(wù)

進入正式測試環(huán)節(jié)后，測試人員就不能像在事前訪談一樣不斷的像用戶提問了，用戶測試的主角是用戶，測試人員應(yīng)安靜的觀察用戶的操作并記錄，不要干擾用戶執(zhí)行任務(wù)。

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

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

此時，最合適的方式應(yīng)該是回復“您覺得應(yīng)該是怎樣呢？是什么讓您覺得應(yīng)該是這樣？您怎么想就怎么做，沒關(guān)系的。”把問題推回給用戶，并讓其有一定安全感，做錯了也沒關(guān)系。我們只負責告訴用戶“做什么”，至于“怎么做”這是要用戶通過操作反饋給我們的信息。

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

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

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

這時就需要測試人員進行適當?shù)母深A，比如：您正在看什么呀？您現(xiàn)在想進行什么操作呀？這是否和您的預期一致呀？通過這類問題試探用戶的想法，并鼓勵其發(fā)生思考。

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

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

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

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

記?。何覀円涗浀氖强陀^事實，而不是自己基于客觀事實的推斷和分析。可能我們看到用戶的操作心理馬上就有了一個推斷，這沒問題，但要區(qū)分出客觀事實和推斷。因為分析，是這個階段收集完數(shù)據(jù)之后在下一個階段應(yīng)該做的事。記錄問題的同時，也要關(guān)注用戶操作流暢的地方，避免最后修改了不必修改的地方。（記錄的數(shù)據(jù)，是繪制用戶體驗地圖的關(guān)鍵）

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

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

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

STEP 7：分析

（1）整理數(shù)據(jù)，判斷產(chǎn)品是否需要迭代

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

如下圖所示：

可用性測試數(shù)據(jù)整理表的示例

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

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

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

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

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

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

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

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

問題影響度分析表的示例

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

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

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

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

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

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

STEP 7：重新設(shè)計

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

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

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

如下圖所示：

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

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

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

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

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

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

可用性報告的內(nèi)容一般包括：

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

可用性測試常見問題

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

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

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

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

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

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

參考文獻

• 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權(quán)威指南
• 用戶體驗與可用性測試

本文由 @少穻 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖作者提供