如何進行可用性測試和用戶研究？

12-25

想了解一下，各位的公司，或者各位所知道的別的公司，是如何進行可用性測試、用戶體驗測試的？

怎麼招募用戶？做訪談還是有更系統的測試辦法？

另外，比如一個新產品，想看看用戶的感興趣程度，是否可以有相應的測試方案呢？

多謝！

我最近做了一份《用戶體驗研究方法談》總結，可用性測試是用戶體驗研究中最常用的方法之一，有相當多的文章談到如何優化和具體實踐的經驗或分析方式。根據我的理解，將可用性測試分解為五個步驟：
1資源準備
2任務設計
3用戶招募
4測試執行
5報告呈現
並對應每個步驟講述了相應執行要點。

以上內容主要來自ucdchina《用戶研究》板塊的可用性測試相關文章總結，具體文章列表如下，感謝各位作者的分享。

分享一份最近總結的可用性測試方法匯總，全文如下：

之前總結過一版交互設計流程圖，主要是想給自己以後做設計梳理一下過程，但是那份流程裡面只有枝幹，並沒有枝葉，所以針對每個方法我都會撰寫一份方法總結，或者說指導，目的就是為以後實踐做準備。我期望的效果是，假如一個沒有接觸過該方法的人看到這份總結，可以按照這個總結一步步完成實驗。這就是我最大的目的。下面就是第一份總結《可用性測試方法總結》。

（預警：長文慎入！不過耐心看完肯定會有所收穫）

============分割線==================

1.可用性測試的過程

可用性測試的過程主要有七個步驟：測試前思考、製作測試原型、撰寫測試腳本、招募測試者、設置測試環境、預測師、正式測試以及測試結果統計分析。這七個步驟有些事可以並行的，有些是需要嚴格按照前後順序執行的。七個步驟組成的流程圖如下：

可用性測試過程

下面我就針對這七個步驟，談談具體要怎麼做。

2.測試前思考

不論是做哪個平台的可用性測試，比如PC端、移動端或者是WEB端的可用性測試，最最重要的就是要先理清楚一些基本問題。基本問題就是最經典的5W問題：

·為什麼要進行這個測試（why）？測試可以驗證一些設計中的疑惑，或者找出現有的界面、流程設計上的問題，具體問題要具體分析。

·什麼時候在哪裡做測試（when？where？）？時間一般是需要和測試者協調的；地點一般選擇在安靜的會議室即可，如果公司有專門的實驗室那就最好不過了。

·誰要作為測試者（who）？這裡可以在招募測試者會詳細討論，不過測試者一般是跟我們的persona接近的人，或者換個說法，測試者一般是我們的目標用戶。

·我們要測試什麼（what）？測試一些功能點，測試界面設計，測試流程設計，測試設計中有爭議、有疑問的地方。

當然這些問題其實都不太難，但是這些都是至關重要的問題。如果沒有經過這個步驟的思考，整個可用性測試做下來就會像無頭蒼蠅，沒有一個總的指導。

3.測試前期準備

在想清楚以上的問題之後，需要為可用性測試做一些準備工作。主要工作有：①招募測試者； ②撰寫測試腳本； ③製作測試原型。

這三個過程不分先後，條件允許的情況下（人力物力充足時）也可以同時進行。

3.1招募測試者

招募測試者算是可用性測試最重要的一個環節之一的，測試者是否合適直接關係到測試結果的好壞，測試結果直接關係到能否發現產品現有的問題。所以招募測試者是重中之重。理想的測試者是我們的目標用戶，所以可用性測試要努力尋找到目標用戶作為測試人員。尋找的途徑如下：

a)最簡便的，假如同事（非同部門）或者好友也是目標用戶，可以選用同事或者好友作為測試人員。

b)其次，大型公司都會有自己的用戶資料庫，可以從這個庫裡面尋找到測試人員。

c)又或者說，委託第三方機構幫忙尋找測試人員也是允許的，不過效果可能不如自己尋找的。

d)當然，現在的應用一般都會有自己的微博、微信、官網或者論壇，這些是非常好的尋找測試者的渠道。我們可以推送招募測試者的公告，讓用戶填寫一份調查之後，我們再篩選得到我們想要的測死者。公告中要註明獎勵，一般為小禮品的獎勵，保證對測試者有一定的吸引力，同時又不至於讓他們會為了這個禮物對個人信息造假。其次，對於測試者，我們需要進行一個篩選【3】。首先需要用戶填寫必要的個人信息：比如姓名、電話（郵箱）、空閑時間；然後根據調查選擇其他一些個人信息：性別、年齡、職業之後，最後留幾道問卷題目進行篩選。

篩選的維度主要有：

·平台。如果測試的產品與平台有關，比如是Android或者iOS，需要在這裡進行一個篩選。

·對產品的熟悉程度。比如我們想找一些初級用戶和一些高級用戶，可以選用「使用時間」這一項來衡量用戶對產品的熟悉程度。

3.2撰寫測試腳本

測試腳本的好壞直接關係到結果的好壞。在撰寫測試腳本之前，我們需要先確定一些結果分析的維度。一般的維度有：a)任務完成度b)致命錯誤c)非致命錯誤d)完成任務的時間e)主觀情緒f)偏好和建議。對於這些維度的解釋具看第文章的最後一部分「測試結果統計分析」。

由於分析的維度會關係到腳本的問題，所以在確定分析維度之後，我們可以對功能點進行任務分析。把所有需要測試的功能點列出來，對每個功能點進行任務設計。對於任務而言，用戶最主觀的感受就是兩個：界面和流程。所以測試腳本又可以從這兩個維度去細分。

需要注意的是，可用性測試中，問只是其中的一部分，觀察是另外一個重要的內容，所以測試腳本不僅僅要有問的問題，還有需要撰寫工作人員觀察的注意點。同時可以在撰寫完測試腳本的同時，把總結大綱也寫出來，方便後期總結的時候統一結果展示。

特別的，在設計的時候有疑惑的點，或者有爭議的點，在可用性測試也可以得到較好的驗證。

寫完測試腳本之後，可以和利益相關者（項目經理、產品經理、開發等）討論一下，請他們校驗一下測試腳本。

界面：

a)當前界面有什麼？

b)每個東西用戶覺得是什麼？

c)可以操作嗎？

d)用什麼手勢操作方式？

e)操作之後會怎麼樣？

f)界面顯示的內容足夠嗎，有沒有缺少什麼東西？

流程：流程的測試就是根據任務來進行的。把產品的需求文檔羅列出來，然後給每個需求配上一個合適的場景，當然也會出現一個場景覆蓋多個需求的情況，這也是允許的。然後讓用戶在場景下去進行任務，觀察用戶，然後隨時提問用戶，隨時準備回答用戶的問題。

以上兩點適合所有的可用性測試，但是對於版本更新類的可用性測試，我們還需要了解這個更新對於用戶來說的接受度如何，所以需要增加一些對比性的問題：比如說：新舊版的操作流暢度、界面表達對比感受。

最後需要注意的是，一次可用性測試能涵蓋的範圍有限，所以要限制腳本問題的數量，以及對腳本的問題進行優先順序的排序。

舉個例子，之前做過一個微信端的眾籌平台。我就可以設定以下任務：

測試腳本樣例
3.3製作測試原型

可用性測試的原型一般是高保真的Demo，可以用Prott，Flinto，proto，墨刀等來製作，製作力求真實還原應用的最終實現效果。製作高保真Demo是一件耗時耗力的工作，所以在製作的時候可以適當忽略一些動效、界面等。不過做出來的Demo最終也可以給開發參考，所以辛苦也是值得的。甚至於，可以請求開發人員製作原生的程序Demo（針對安卓平台），程序Demo體驗會更加好。

當然，紙面模型也是另外一種非常好的工具。紙面模型需要把紙面模型都只做出來，然後把所有的彈出窗口、下拉菜單等控制項也製作出來。然後設計師充當wizard of oz來輔助用戶完成任務。即用戶對著紙面模型來操作，然後設計師實時反饋用戶的操作。這樣子要求設計師非常熟悉測試的應用，同時，測試的時間也會大大增長。同時，動效作為設計的一環在這裡無法表現出來，所以結果可能會不如高保真Demo來的好。總之各有利弊，根據實際情況來考慮。

4.設置測試環境

測試環境是指測試的時候需要使用的記錄設備，通過把測試過程記錄下來可以更好地分析用戶的行為，特別是用戶自己都沒有覺察出來的一些東西。

首先，最最重要的一點是錄音，錄音一方面是在整理訪談記錄的時候可以幫助設計師回憶訪問的場景，然後填補一些缺失的筆記。另一方面，錄音也可以作為一種存檔的材料。同時，錄音也存在簡單、易操作、隱蔽等特點，使用錄音筆或者現在隨處可見的智能機即可完成錄音。所以強烈推薦進行可用性測試的時候一定至少要錄音。

錄音之外就是錄像，如果有錄像的話，錄音的步驟就可以省略。錄像主要是記錄用戶的表情和動作。有時候，用戶的表情和動作可以傳達很多東西，通過把這些信息記錄下來可以，設計師偶爾可以挖掘到一些閃光的設計點。

除此之外，用戶的屏幕記錄也是一種方式，通過用戶的屏幕、加上用戶操作的動作，表情，可以真實還原用戶的使用場景，方便後期的分析。

錄像和錄屏的操作比較難進行，主要的設備可以參考如下【5】，具體可以查看相關的鏈接：

·攝像機：記錄動作和部分表情

·眼動儀：可以追蹤眼球的焦點軌跡，不適合移動端

·滑鼠軌跡記錄：記錄滑鼠軌跡，只適用於PC端

·QuickTime (iOS)：僅記錄屏幕

·Mobizen (Android)：記錄屏幕、手勢

·Display Recorder (iOS)：手勢、聲音

·SCR (Android)：記錄屏幕、手勢、表情、聲音

·Magitest (iOS)：記錄屏幕、手勢、表情、聲音

·Mobizen +AirDroid (Android)：現場觀察並記錄手勢、表情、聲音

5.預測試

預測試是正式實施可用性測試前的一次模擬，模擬有助於發現問題，這時候邀請同事即可。把正式測試的流程走一遍，包括設配的調試、訪談切入、問題的提問、記錄者的記錄等，然後把記錄的錄音、視頻等放出來看看效果如何，效果不如意的時候再進行調整。

總之，預測試可以幫助發現問題，包括以下幾個方面的問題：

·設備的問題。舉個例子，錄音設備放置的位置會影響錄音的效果。

·測試腳本的問題。測試問題是否足夠清晰。

·訪談的切入以及問題的提問。

·記錄者的記錄。

發現問題之後去解決問題，才能使正式測試的時候達到更好的效果。

6.正式測試6.1事前接待

測試前的接待工作是測試人員對公司的第一印象，給測試人員留下一個好印象、一個好心情有利於可用性測試的進行。所以在這裡將一些注意點說一下。

首先，可以事先確認一下用戶的行程。遇到颳風、下雨、下雪等惡劣天氣的時候可以事先送上問候簡訊。

其次，遇上用戶遲到的情況下，也要保持克制。在遲到五分鐘到十分鐘之後再給用戶電話詢問情況，如果用戶因故取消測試，也要保持友好的態度。

在接到用戶之後，送上一杯溫水或者溫熱的飲料，然後讓用戶等待一下。最後可以有專門的人員先和用戶聊聊天，可以打聽一些事情。

6.2暖場介紹

正式開始之前有個暖場介紹。首先主持人做一下自我介紹，然後介紹一下測試的目的和時間，需要向用戶強調測試的對象是系統，希望用戶可以暢所欲言。如果有錄音或者錄像，需要向用戶告知會有此類行為，但是結果完全保密。最後還需要簽署保密協議。

6.3正式提問

正式提問分兩個部分：個人信息的小問題和可用性測試任務問題。

小問題主要是為了讓用戶有個適應的過程，可以迅速進入狀態。一般可以詢問產品使用習慣、產品偏好、上網情況等，之後的測試問題就是主要的可用性測試的問題。這裡需要把問題放入到場景中，讓用戶在場景中去完成任務。或者可以詢問用戶的使用習慣，然後引導到腳本中的問題。需要注意的是，不一定要按照腳本的順序提問，可以隨機應變，所以主持人要非常熟悉腳本的內容。除了詢問，聆聽之外，主持人還要觀察用戶的神情以及動作，遇上用戶有疑問的表情的時候可以適當穿插新的問題，但是盡量不要提供幫助，也不要指出用戶的錯誤或指責動作太慢，但是可以詢問用戶「為什麼這麼操作」，必要的時候可以選擇停止任務。

測試過程中還需要有一個記錄人員，記錄人員需要記錄：用戶做了什麼動作和步驟（重點）、用戶說了什麼、寫下自己的疑問（適當時候可以進行提問或者讓主持人提問）。

6.4結束感謝

測試結束之後，主持人可以問一下用戶的想法，同時讓記錄人員補充提問，所有問題結束之後，需要對用戶表示感謝。送上禮品並接受用戶的一些交通費報銷票據等。最後要把用戶送到公司門口。

7.測試結果統計分析

測試結束之後，如果有時間可以立馬進行整理，因為時間越短，整理出來的內容就越豐富。必要的時候，可以用錄音或者錄像來輔助。在撰寫測試腳本的時候還有一份總結大綱，根據大綱來整理內容。大綱要具備靈活性，可以記錄一下測試現場發現的新問題。

記得只是整理而已，每個測試結束都會有一份整理的資料。最後需要匯總多份可用性測試總結，最終出具一份可用性測試結果，根據這份結果進行相應的改進工作。

我們可以從如下幾個維度去分析我們的可用性測試【8】（維度之間可能有交叉）：

a)任務完成度。每個測試任務都對應一個目標，只有當用戶達到目標之後，我們才認為他們完成了任務。對於每個任務，用戶完成的情況如何？有多少用戶最終沒能完成任務？多少用戶需要在主持人提示下完成任務？多少人可以自行完成任務？這些都是很重要的指標

b)致命錯誤。嚴重錯誤指那些阻礙用戶完成任務的錯誤，這些錯誤非常重要，每一個都要得到足夠的重視。

c)非致命錯誤。非致命錯誤是指用戶能完成任務，但是某些地方會有一些阻滯，會停頓或者思考的錯誤。這些錯誤相對來說沒那麼重要，不過如果發生的次數較多，該類錯誤也需要得到重視。

d)完成任務的時間。每個任務需要完成多少時間，決定了交互設計流程和界面的設計是否足夠友好。

e)主觀情緒。用戶對於任務的主觀感受，比如是否足夠簡單，是否容易找到信息，可以讓用戶衡量一下。

f)偏好和建議。可以讓用戶說出產品中哪些地方很喜歡？哪些地方不喜歡？或者讓他們提一下建議。

【1】Adaptingyour usability testing practise for mobileAdapting your usability testing practise for mobile

【2】移動可用性測試(一):概述 – 騰訊ISUX–社交用戶體驗設計移動可用性測試 (一): 概述

【3】網易公司用戶訪談活動招募問卷網易公司用戶訪談活動招募問卷

【4】用戶訪談心得總結– 騰訊CDC用戶訪談心得總結

【5】移動可用性測試（三）：現場測試– 騰訊ISUX– 社交用戶體驗設計移動可用性測試（三）：現場測試

【6】用戶研究經驗談-采銅學心錄-博客大巴用戶研究經驗談

【7】簡單快速的可用性測試|網易用戶體驗設計中心簡單快速的可用性測試

【8】Planninga Usability Test http://Usability.gov http://www.usability.gov/how-to-and-tools/methods/planning-usability-testing.html

最後歡迎光臨我的簡書妖葉秋 - 簡書，不定期發布一些交互或者用研的經驗、心得或總結。

根據我之前實習的經驗，可用性測試的過程是這樣的：

包括三部分，時間安排，測試過程，總結思考。

1 時間安排

需要測試三個不同產品，每個產品的安卓端和iOS端都要測試，每個端需要測試5-8人。

星期一到星期五，工作內容為：撰寫3份腳本，A產品記錄模板，組長對測試人員進行培訓，確定測試對象並預約，進行預訪談。星期六至下周星期一，進行三天的測試。接著星期二至星期五撰寫A產品報告，及為B產品做準備，如此往複，直到三個產品測試結束。

2 測試過程

測試過程從測試前，測試中，報告撰寫三部分。

2.1測試前

2.1.1腳本

腳本包括開場白，場景設置，評分記錄，SUS量表填寫。

開場白的要點如下：告知測試對象，我們測試的目的是為了提高產品的使用體驗，而不是測試用戶的使用水平，幫助用戶放鬆。測試過程需要錄音錄像，但不作為其它目的，請用戶放心，並填寫同意書。主持人用於和測試對象的聊天話題，幫助預熱。

場景設置是腳本中最重要的內容。其實就是把測試任務改寫成簡短的日常生活的場景。測試任務是客戶提出的測試要點，比如搜索功能，我們就要根據日常生活進行改寫，比如，你的朋友推薦你看一部美劇《老友記》，你想找到並看一看。在場景中最好不要提到和操作任務有關的動作，讓用戶自己嘗試。一次測試4個場景左右，大約1個小時。前後四個場景要根據任務操作的連貫性進行排列。

評分記錄，是主持人用於記錄測試對象的完成情況，完成情況有3種，1代表完成，2代表多次嘗試完成，3代表失敗。以及用戶對產品相應任務的操作難易度和界面滿意度評分，7點評分。

SUS量表用於測試結束後，測試對象根據自己的使用過程對產品產生的大體印象，填寫量表。

2.1.2 錄入模板

錄入模板是用於方便記錄員記錄的Excel表格，以及後期報告的數據統計和圖表製作。兩個端的用戶訪談信息都記錄在一個Excel表格上，容易混亂，所以竟可能區別開不同的任務，還要提供較大空間記錄用戶的原話。

2.1.3 測試對象

測試的對象特點是客戶提出的，具體包括幾個要點，使用產品的時間，每日使用的次數，以及人口學特點。因為當時測試產品的特點，主要是在大學的論壇里發帖招募的，（大學生招的有點太多了），招募的方式，就是讓符合條件的用戶加到QQ群里，群主給他發一份問卷，主要是使用的時間之類的信息，然後進行篩選。通過的測試對象，電話聯繫，稍微聊聊，確定用戶的口頭表達能力，空餘時間，然後製作相應的時間表。最後做出一份測試對象的個人信息及時間安排表。

2.1.4 測試地點及設備

測試地點選擇一個空餘辦公室，設備有一台用於記錄的電腦，一台用於錄製用戶使用過程的電腦，裝有相應軟體的安卓手機和蘋果手機，在桌上準備好任務過程中使用的賬號，填寫的量表，及茶水。因為設備的原因，這次測試主持人和記錄人在同一個房間，記錄員的臉被電腦擋著。

2.1.5預測試

測試前一天，安排個時間進行預測試，主要用於準備和查找腳本的不足等問題。

2.2 測試中

測試前一天，需要再次電話聯繫，確定明天是否準時參加測試。測試前半小時，再次電話聯繫，確保找到測試地方及準時到達。

從接待用戶開始，就要給用戶留下一個輕鬆的印象，聊聊用戶的日常生活，找到點挖出和產品使用相關的經驗，打開用戶的話匣，主持人和用戶也建立起一個較好的開頭。在宣讀開場白的時候，最好能用較平常的口吻照著腳本讀，防止漏掉一些要點。任務測試過程中，注意觀察用戶的使用過程，哪裡疑惑了，哪裡停頓了，主要問話的方式，不要問出有預設的問題，同時還要根據時間把握進度，這部分是最關鍵的，也是我比較薄弱的地方。

記錄人員要集中注意力，用戶說的話還是相當多的，不知道這裡是記錄關鍵信息，還是記錄原話，如果後期有時間重新觀看錄像的話，記錄關鍵信息也是可以的。

測試結束後，記錄人員要和主持人交流下，看看有沒有遺落的地方，或者不理解用戶操作的地方。最後再留半個小時，用於休息，這樣不會上一場的測試影響下一場。

2.3 報告撰寫

在測試結束後，要立即對數據進行整理，整理出用戶提出的問題點，對問題點進行分類，屬於交互、功能、視覺、性能？同時對用戶的界面滿意度，任務難易度，任務完成情況，SUS量表，任務操作路徑進行數據統計，撰寫成報告。

3 總結思考

目前想到的主要有這些，寫的還是較為粗糙。在《妙手回春》中，Krug已經寫的很入門的方法了，《用戶體驗度量》中也就結果分析給出詳細的描述，《Handbook of Usability Testing》中理論較全。

在測試過程，主要還是和用戶真正訪談時，比較考驗經驗，如何啟發用戶說出他的想法，如何理解到用戶的真正想法，問問題時的表達方式，以及如何控制時間，都是我要進一步學習的地方。

可用性測試是用戶研究的一種類型，能夠在產品上線前發現一些可用性的問題，避免在產品設計上走彎路，那麼我們該如何做可用性測試呢？本文為你詳細講解！

一、什麼是可用性測試呢？

福特自從發現了用戶想更快的達到某地以後，發明了一輛汽車，但是他不知道自己的汽車設計的好不好，於是邀請幾個人來試駕，試駕的人在試駕的過程中不斷地給他提意見，座椅太高了、方便盤太死...,這個過程就是可用性測試。

邀請一批真實的具有代表性的用戶針對典型場景操作產品，並鼓勵他們在嘗試完成任務的時候出聲思考，可用性工作人員在一旁觀察、聆聽、記錄，從而發現產品中存在的可用性問題。它適應於產品前期設計開發、中期改進和後期維護完善的各個階段，是以用戶為中心設計思想的重要體現。

可用性測試的具體概念包含觀察、訪談和發聲

觀察：讓一群具有代表性的用戶對產品進行典型操作，同時觀察人員在一旁觀察，聆聽，做記錄。動作的起始位置、操作的流暢程度、面部表情的變化...
訪談：有的時候我們觀察用戶，並不一定能洞察用戶出現的問題，這個時候可以通過訪談的形式來詢問用戶的想法，比如：「您這麼操作是為了？這裡遇到什麼問題了？總體使用感受怎麼樣？」不要問用戶您覺得怎麼設計會更好用？…這種問題，不要讓用戶給你解決方案，用戶又不是產品經理。
發聲：鼓勵用戶訴說使用產品過程中的感受，讓用戶把遇到的問題和想吐槽的點說出來，用戶發聲的過程也是一個交流思考的過程。

這裡面有幾個關鍵辭彙：「一批、代表性用戶、觀察聆聽、記錄、訪談、發聲」。

二、為什麼要做可用性測試呢？

有沒有發現產品經理做久了，你去用其他產品的時候有些功能會很好找，但是你身邊不是做互聯網的朋友可能就無法輕易的找到某個功能，那是因為我們身處這個行業，經查使用互聯網產品，從而形成一種思維定式，認為這個功能理所當然該這樣設計，但是產品人員是專家用戶，用戶只是普通用戶，我們並不能代表大多數普通用戶的想法。

比如理財產品使用加息券這個場景，一位產品人員覺得用戶需要一個地方去領加息券產生的收益，結果在做可用性測試的時候，12個用戶中有11個用戶不知道怎麼操作，有的用戶覺得加息券產生的收益直接到我賬戶不就行了，幹嘛還讓我去領，多次一舉。

這就是區別，雖然我們是用戶，但並不是具有代表性的真實用戶。

三、可用性的幾個維度

測試對象

可用性測試測試的是產品不是用戶

一般情況下，對於不確定性因素高的產品，可以用紙上畫的原型或者勾畫的線框原型圖供用戶測試，避免改版浪費的人力、物力。

而對於基本確定產品可利用帶有交互設計的高保真原型進行測試，這樣的可用性測試涵蓋了交互設計和界面設計，測試的地方比較全面。

這樣的一種測試方式，既可以減少人力、物力、財力的浪費，又可以獲得比較全面的測試結果。

測試樣本

樣本個數：眾多研究表明，5個測試用戶就能發現85%的可用性問題，當然要錢多任性，也可以多找幾個。

樣本覆蓋：樣本要具有代表性，比如你可以根據用戶的使用習慣劃分出一般性用戶、習慣性用戶、重度使用用戶以及專家型用戶，當然種類細分越全面越好，選出的用戶具有代表性，測出來的問題才具有價值。

測試時間

可用性測試盡量早做，不要等到上線了才做，這個時候即使測出問題也來不及改了。

還有人覺得可用性測試很專業，必須要專業的實驗室、專業的錄像設備、專業的錄音器材才能做測試，其實這些都是誤區，當你和同事爭論按鈕怎麼擺放更好，無法統一意見的時候，叫個代表性用戶來給你們決斷，這不就是可用性測試？窮人有窮人的玩法，富人有富人的玩法，舉個不恰當的例子，窮人去嫖娼叫大保健，富人嫖娼那叫海天盛筵。

測試場所

測試場所分為實驗室測試和現場測試。

實驗室測試

一間類似於辦公室的區域和一面單向玻璃的可監視房間組成，阿里，網易都有這類的專業的實驗室，有點類似於你看人民名義審訊犯人的地方，不建議實驗室設計成這種樣式，因為用戶覺得自己被監視會反感，而且在這種冰冷的環境中，會激起人類本能的防備心理，很難獲取用戶內心真實的想法，可以用那種圓桌會議室或者茶話間改成實驗室，即使要監視也不要用大面的玻璃牆，讓用戶感覺自己被監視。同時實驗室必須是一個安靜的空間，測試的用戶能夠全神貫注於任務的執行。

優點：由於現場環境比較嘈雜、分散用戶注意力的點比較多，實驗室測試一天能完成的事情，現場測試需要兩天，實驗室測試節省了大量的人力、物力、財力。

缺點：實驗室測試無法發現和現場測試一樣多的問題。因為用戶在實際使用中，肯定會被聲音或現場出現的其他因素所打斷，而實驗室的環境是安靜的，無法模擬出這些異常因素。

現場測試

現場的可用性測試不多見，大多數的可用性測試都是在實驗室完成的，這可能是因為數據的收集，如出聲思考、視頻記錄或者觀察記錄，這些在現場做比較困難。

近年來由於攜帶型錄像設備在近兩年快速發展，使得現場測試變得容易一些，可以在現場做一些小測試。

優點：相比於實驗室，現場測試更能模擬用戶真實的使用場景，能夠發現更多的可用性問題。

缺點：由於現場環境的不可預知性，現場測試仍然比實驗室測試更加耗時，需要測試的用戶和測試人員付出更大的努力，比較耗費人力、物力和財力。

最後，如果不是特別需要，實驗室測試能夠發現大部分問題，用實驗室測試就好。

總結：講清楚了什麼是可用性測試、為什麼進行可用性測試以及可用性測試的幾個維度，下篇給大家講可用性測試的具體操作，喜歡的小夥伴可關注微信公眾號：chanpinliu880 (也可加微信yw5201a1交流歐)

http://weixin.qq.com/r/xUi6ohPENE5LrVfB9x3X (二維碼自動識別)

可用性測試在所有的方法裡面，應該是用的最廣泛的一種方法，它從產品原型設計階段，到最後產品上市都可以採用。

作為從業10年的老兵，分享一下自己的一點心得吧：
1. 明確你的測試目標是什麼，和相關的人員討論，定下主要目標。
2. 準備測試原型或者產品，自己需要先認真研究，如果自己都不清楚原型或者產品，那是很難深入討論的。
3.準備測試的任務、討論題綱和實驗記錄模板。
4.準備招募要求，自己招人或者讓第三方招募，本人一般喜歡讓第三方招募。自已招募看似省錢，但是你要想想，在這中間浪費的時間，也都是金錢。200多年前亞當斯密就說過，分工促進了生產力的發展，提高了效率，所以第三方招最後總成本一定比你自己便宜。
5. 測試工作（如果自己招募，之前需要給用房發測試地點、參加測試的提醒等），盡量邀請相關決策參與人員觀摩測試過程，只有看見用戶如何掙扎，他們才會感同深受，比任何報告都有效。
6.數據分析，寫報告，提改進意見。
7. 溝通結果並保持跟蹤。

總之，作為一個用研人員，可以說入行門檻很低，但是要做的很，也非常不容易。

老鐵們都收藏去了，點個讚唄

————————————我是分割線——————

謝不邀，最近正好在研究可用性，便來答一下。

一.定義：產品在特定使用環境下為特定用戶用於特定用途時所具有的有效性（Effectiveness）、效率（Efficiency）和用戶滿意度（Satisfaction）。

1.有效性：

用戶完成特定任務和達到特定目標時所具有的正確和完整程度

2. 效率：

用戶完成任務的正確和完整程度與所使用資源（如時間）的比率

3. 滿意度：

用戶在使用產品過程中所感受到的主觀滿意和接受程度

可用性（Usability）是互動式產品/系統的重要質量指標，指的是產品對用戶來說有效、易學、高效、好記、少錯和令人滿意的程度。---- Jakob Nielsen

二、可用性屬性

1.易學性（Learnability）：系統應該容易學習，這樣用戶可以快速開始使用這個系統來完成某些工作。

2.效率（Efficiency）：系統的使用應該具有效率，一旦用戶學會使用系統後，就有可能提高生產率。

3.可記憶性（Memorability）：系統應該基於記憶，以便用戶離開一個系統一段時間之後能夠重新使用這個系統，而不用從頭開始。

4.錯誤率（Error）：系統應該具有低的錯誤率，使得用戶在使用系統的過程中就很少出錯，即使出錯也能夠迅速恢復。而且必須保證不會發生災難性錯誤。

5.滿意度（Satisfaction）：系統應該使用起來令人愉悅，讓用戶在使用時主觀上感到滿意並喜歡這個系統。

三、詳細介紹

1.易學性（Learnability）:

How easy is it for users to accomplish basic tasks the first time they encounter the design ?

度量方法：1. 完成特定任務的時間 2. 能否在特定時間內完成任務

2.效率（Efficiency）:

Once users have learned the design, how quickly can they perform tasks ?

度量方法：確定關於技能水平的某種定義，尋找一些具有這種技能水平的代表性用戶，度量這些用戶執行某些典型測試任務所用的時間。

3.可記憶性（Memorability）:

When users return to the design after a period of not using it, how easily can they reestablish proficiency?

度量方法：

1.對離開系統一段時間的臨時用戶進行測試，測量他們執行一些典型測試任務所用的時間。

2.對用戶進行記憶測試，在完成系統測試過程後，讓他們解釋各種命令的作用，或者講出完成特定事情的步驟名稱。用戶給出的正確答案的數目即為可記憶性的得分。

注意：和使用效率的不同之處在於測試用戶是臨時用戶（指斷斷續續地使用系統的人們，他們不像專業用戶那樣頻繁地使用系統）

4.錯誤率（Errors）:

How many errors do users make, how severe are these errors, and how easily can they recover from the errors?

度量方法：錯誤可定義為不能達到預期目標的任何操作，而測量系統的出錯率，就是統計用戶執行任務時所出現的這種操作的次數。

注意：有些錯誤可以被用戶立刻糾正，並不會產生其他後果，只不過稍稍降低了用戶的事務處理速度。一般沒有必要統計這種錯誤，因為他的影響已經包含在使用效率之中了。（「皮划艇」問題）

5.滿意度（Satisfaction）:

How pleasant is it to use the design?

度量方法：

1.主觀滿意度：通過調查問卷量表、用戶深入訪談等方式得到用戶的主觀評價。單個用戶的回答是主觀的；但當很多用戶的回答放在一起進行平均之後，得到的結論在某種程度上可視作滿意度的客觀度量。

2.客觀滿意度：通過用戶腦電圖、肌肉電、皮膚電反應、瞳孔擴張率、心率、血壓、血液中腎上腺素濃度、肌肉中的乳酸濃度等來評測用戶的壓力和舒適程度。

四、案例：圖標設計

測試對象：為某手機的GUI設計了N套不同的圖標，每套M個方案

測試目標：對每個圖標的易學習性、效率和滿意度進行測試

測試方法：？？？

1.易學習性：

1）每次向用戶展示一個圖標，讓用戶描述「你認為這是什麼意思？」的方法，測試每個圖標的直覺性。

2）向用戶展示一整套圖標，向用戶簡要描述其中一個圖標的名字和用途，讓用戶指出最匹配的圖標。

3）給用戶一整套圖標名字，讓用戶匹配圖標。

易學習性得分即為被正確描述或者命名的圖標所佔的比例。

2.效率：

1）對於通過參加學習測試已知圖標含義的用戶，給他們一個圖標的名字，告訴他們它可能會出現在計算機屏幕上，然後隨機地顯示圖標，如果是用戶要尋找的圖標，用戶就按「是」，如果是其他圖標，就按「否」。

2）給他們一個圖標的名字，向用戶呈現同時隨機分布的若干圖標，讓用戶點擊對應的那個。

兩個測試都進行計時，用戶的反應時間即為效率

3.主觀滿意度：

1）讓用戶根據圖標是否容易識別進行判斷，逐一打分，匯總後得分即為主觀滿意度。

2）針對M個圖標中的每一個，向用戶展示N個方案，讓用戶選擇傾向的那個，最終的用戶比例即為滿意度。

五、可用性研究方法

1.人物分析法（Task Analysis）

1）觀察人的行為

2）對任務進行分析

3）任務設計

動作分析就是把操作的動作元素記錄下來，分析動作的特點，構成操作活動的最小動作元素稱為動素（therblig）

動作元素

動作分析的方法

六、可用性評估流程

1.總述

1）任務流程分析

a.信息架構

b.最優流程分析

c.被使者流程

d.任務難易度評估

2）口語動作分析

3）錯誤操作分析

a.錯誤操作列表

b.錯誤種類統計

c.錯誤存在界面

d.界面問題分析

e.整體評估

4）問卷調查分析

a.5Es評估

b.改進建議

5）改進意見

6）結構化訪談分析

a.錯誤評級

b.問題嚴重程度

c.改進方案

d.風險評估

7）製作紙面原型

8）重複1-6

2.信息架構

3.層次化任務分析圖

4.最優流程

被試者的任務流程一般是

任務時間統計

任務難易度評估

用戶錯誤類型

1）基於界面的錯誤：需改進

界面設計不合理，不符合用戶的操作。

如：圖標、字體、按鈕、下拉列表、布局等設計問題

2）基於知識的錯誤：需分類對待

用戶由於沒有某種知識或經驗所產生的錯誤。

如：不知道星星圖標表示收藏，URL，缺乏專業背景知識等

3）基於規則的錯誤：無需改進

用戶在測試中由於不了解任務，導致沒有按照任務流程執行。

如：看錯任務書，任務理解錯誤等

4）基於系統的錯誤：需改進

因產品或平台自身的問題，導致用戶無法執行相關操作。Bug等

5）基於模式的錯誤：大多數需改進

用戶有自己的操作習慣和經驗模式，與產品不符。

如：滑鼠滾輪方向，向下和向右刷新，音量調節，手指縮放等

示例：

進行統計

5.啟發式評估 Heuristic Evaluation

啟發式評估是專家評審法的一種，就是讓幾個評審人員根據一些通用的可用性原則和自己的經驗來發現系統內潛在的可用性問題。

確定評估者人數，背景，培訓和篩選

1） Nielsen建議邀請3-5名評估者參與

2）評估人背景：

a.有可用性研究經驗以及界面（設計或交互）雙重背景的評估者最優

b.只有可用性研究背景的評估者

c.界面開發或研發人員

d. 原則上，不推薦邀請一般用戶參與評估

3.）評估人員的培訓和篩選

a. 該方法的易操作和易學性帶來的最大便利就是可以通過小項目培訓評估人員

b. 建議通過一定時間的培養，建立一個比較好的評估團隊

評估過程和注意事項

1）評估者最少要完整瀏覽或操作界面（被評估產品）兩遍；一遍重點評估流程；一遍重點評估各個細節

2）提醒或要求評估者對照基本的可用性原則以及他們的經驗和知識的檢查評估對象

3）確保3-5名評估者獨立開展評估工作，並由一人最終匯總各自提交的結果

4）如果有必要，評估者各自完成評估後，可以召集一個簡短的討論會

5）對已收集到的可用性問題進行較嚴格的評級，以便確定是否修正以及優先順序

考慮可選的測試方法，基於目標選擇並確定最合適的方法：

①焦點小組法——收集態度和意見，探討早期的想法和概念(Nielsen 1993)；

②調查法——測量受眾普遍關注的事情(Fink 2008)；

③訪談法——理解不能輕易觀察到的信息和過程(Kvale 1996; King and Horrocks 2010)；

④情景調查法——在工作環境中了解用戶和使用者的信息(Beyer and Holtzblatt 1998; Holtzblatt, Wendell et al. 2004)；

⑤卡片分類法——理解信息如何分類(Spencer and Warfel 2007)；

⑥可用性評估——測量並改善特定產品或界面的可用性(Rubin and Chisnell 2008; Krug 2010)；

⑦… …

6.制定測試計劃

1）介紹

目的：歡迎參與者；解釋測試的目的；確定同意書；告知參與者有攝像和觀察人員

2）背景調查

目的：建立良好的交流；收集興趣主題的語境；確認參與者的合適性；幫助觀察人員理解/識別參與者

3）測試部分概況

解釋測試步驟，幫助測試者成為好的參與者。內容包括：

a.測試目標，比如使產品更好用

b.將會執行的任務；

c.出聲思考（把想法說出來）

d.測試的是產品不是你（參與者）

e.產品是個原型（若可以）

f.不會影響主持人的心情

g.詢問有沒有問題等

4）完成任務

目的：識別出用戶完成主要任務遇到的困難

有效的場景：

a.涵蓋測試目標中描述的測試內容

b.有清晰的目標和成功的判斷標準

c.通過鼓勵用戶來測試假設等

5）測後調查

目的：

a.收集主觀反饋

b.跟蹤新的想法

c.尋找未來可能的應用場景

7.執行測試

當用戶執行任務時：

a.在測試中主持人不要試圖教用戶如何使用產品

b.不要以任何方式表現出用戶正在犯錯或操作太慢

c.要做到仔細的觀察、並認真聆聽用戶的建議

d.要識別用戶的情緒，必要的時候給於引導或選擇停止任務

e.用戶遇到困難時盡量不要提供幫助，可給予適當鼓勵

f.在用戶完成一個任務時可適當的提問「為什麼剛才這樣操作」，但盡量簡單

結構化訪談時：

a.按照既定的結構化訪談問題進行訪問

b.詢問那些在過程中想深入詢問但沒有詢問的問題

c.詢問在觀察的隊友關心的問題

測試後

a.及時整理數據，查看數據記錄人員的筆記，檢查錄音和錄像

b.回顧用戶的操作行為，記錄小組發現的問題（文檔、便利貼）

c.先組內分工，各自整理完用戶流程、口語動作分析、結構化訪談、問卷調查等客觀數據，再開會交流每位用戶的情況

d.所有成員共同完成用戶的錯誤列表分析，隨時討論，保證錯誤分類和初步改進意見的統一。由一人進行所有數據的匯總

e.完成數據分析後，成員開會討論改進方案，評估風險和問題

f.製作紙面原型

g.找到兩名被測用戶進行產品的改進後方案的紙面原型測試

h.分析數據，匯總結果

七、可用性問題等級

確定可用性問題嚴重程度：

1. 頻率：這是一個偶然發生還是會經常發生的問題

2. 影響：對用戶而言是一個比較容易克服，還是難以逾越的問題

3. 重複：只需要一次學習，用戶就能解決這個問題，還是用戶總會被這個問題困擾

PS：有的問題看起來用戶很容易克服，但是它造成的影響卻又有可能很嚴重。因此，最後還需要有一個人對所有問題的「市場風險」做一次整體評估。

問題嚴重程度的5級描述：

0：這根本不是一個可用性問題

1：錦上添花的問題。除非有多餘的時間或人力，否則不必修正

2：較小的問題：修正，但優先順序低

3：較大的問題：修正，並優先極高

4：可用性的災難：緊急，產品發布前必須解決

以上，便是可用性的大概情況，其實還有很多測試細節我沒有細講，因為別的答案已經說的比較清楚了。

還不快去點贊，寫了辣么多，快懷疑人生了！口亨！

可用性測試是一種操作性較強的迭代設計方法。關於迭代設計，還有一種說法叫「MVP"（Minimum Viable Product，最低可行產品），即快速推出產品，後續不斷改進。

這能有效地降低產品研發周期，快速佔領市場，快速獲得客戶反饋。

很多人對設計的誤解，認為設計師都是些不食人間煙火，深夜案頭苦思冥想閉門幾個月最終憋出來一個驚世設計方案，而當靈感枯竭時則頹廢懶散無所事事的人，

認為設計依賴於捉摸不定的靈感而無法進行項目時間管控。這種觀點更多地認為設計就是臨門一腳的結果。事實上，假如脫離了中場組織和調整，缺少了必要的控球倒腳，臨門一腳往往無果而終。

設計更多是過程，溝通過程。可用性測試提供了這樣一種簡單直接的溝通方式。通過這種方式獲得用戶反饋，並以此為設計依據迅速調整產品功能乃至產品方向。

如能秉持這種設計即溝通的理念，自然不會將可用性測試僅僅看做是一種無奈之選。

小到一個圖標的辨識，頁面導航，功能使用，大到某項業務的辦理，都可以拿來做可用性測試。

測試對象的選取也沒有過多要求，任何不相關的同事，朋友，甚至路人都可以被請來參加你的可用性測試。除了專業度很高的比如業務處理等，一般性的操作對是否具有真正用戶資質的要求並不高。

原因在於，可用性測試最大的作用是發現明顯的可用性問題（不要懷疑設計師的水平，有太多設計失敗案例是源於看起來簡單愚蠢之極的錯誤），而這些問題多數跟專業無關，只跟常識有關。

具體操作也很簡單，無需拘泥於測試地點，準備材料，等等，一張紙一枝筆足夠矣。
這裡操作關鍵的點在， 1. 場景代入，2. 觀察和傾聽。

場景代入是指讓被試者知道大概的背景，比如這個軟體功能是做什麼的，誰會是使用者等，但不告訴具體如何操作（有點小白鼠的意思）。

觀察，靠的不僅僅是眼睛，而是心。只有清楚自己要藉助測試得到什麼，才能不錯過轉瞬即逝的細節。這要求主試者本人對設計有較深的理解。

其他的工作則是為了確保可用性測試順利進行。比如前期需要邀請，需要準備任務清單，提問清單，需要記錄的設備工具，還有一點小意思。

但真正影響可用性測試質量的只取決於主試者自身的經驗和水平。

分享一篇 Nielson Norman Group 關於可用性研究規劃的文章：

1. 確定研究目標

研究目標的確定將決定採用哪些 UX 的調研方法。首先，詢問利益相關者，了解他們想要知道的信息，待解決的問題，關注和感興趣的範圍，確定調研的目的。

對於收集定性或定量的用戶行為數據，以及回答與設計相關問題，可用性研究非常適合（e.g.呈現的內容是否便於尋找和理解？用戶可否順利地完成任務？）。如果是為了收集用戶態度反饋，則可以考慮採用其他的調研方式。

同一次研究中不要設立多個目標，因為每增加一個額外的問題，對於其他的研究洞察質量就會下降。在和用戶有限的溝通時間內，充分利用每一次機會，專註於真正能夠實現產品 ROI （投資回報率）的研究目標。

2. 確定研究方式

根據不同的項目，可以選擇不同的研究方式：

實驗室 or 實地：在公司的可用性實驗室，還是實地研究？從便捷性的角度而言，大多一對一的可用性測試都在公司內的實驗室中進行。然而，如果用戶的環境因素對研究很關鍵，且實驗室無法模擬出用戶場景，那麼花費一些旅行的時間去實地研究也是值得的。

有主持 or 無主持：有主持研究可以讓參與用戶有機會闡述問題原委，獲得豐富的設計洞察和用戶開放式的評論資源。但另一方面，無主持研究的好處在於花費少，更快速，為無法參加的用戶提供更便捷的途徑。

面對面 or 遠程：一般來說，我們會推薦面對面的方式。當與用戶同處一室，交流的氣氛更親密，研究員更易覺察出細微的線索，比如身體語言。但有時也會受到預算、敏捷項目環境、或用戶無法前往等因素而選擇遠程研究。

3. 確定參與用戶數量

對於傳統的定性研究，我們通常會推薦 5 位用戶參與，以獲得最高的投資回報。如果研究超過 1 組目標用戶群，可根據每一類用戶群在經驗、態度上的重疊，調整為每一組用戶群 2-5 位用戶參與。

定量研究和眼動追蹤研究需要更大的樣本量才能輸出有意義的研究結論。預計參與用戶的數量至少要增加到 4 倍以上，在每一組目標用戶群中，需要至少 20-30 位用戶參與。

4. 用戶招募

好的設計洞察來源於真實用戶的反饋，招募用戶最基本的一條原則是：讓最具有代表性的用戶參與。首先從人口統計學特徵上甄別與研究相匹配的用戶（更好的是：與用戶畫像匹配），再通過了解用戶的態度、行為、目標來甄選。

「假用戶」（假裝或假想一個使用場景）可能會導致無效的研究結果。尤其當測試一些特殊的頁面，有豐富的內容或 B2B 頁面，必須招募符合研究對象的用戶參與。

5. 根據研究目標，撰寫測試任務

在可用性測試中，用戶需要在體驗的同時完成一系列任務。這些活動（或任務）通常是根據研究目標，以情景腳本的形式撰寫的。情景的描述可以從寬泛到具體，通常有以下兩種主要的類型：

探索型任務：開放式的任務，適於更寬泛的、研究導向的目標，可以有或沒有標準答案。這些任務是為了習得用戶是如何發現或查找信息的，並不適合定量的測試。

比如：當你想要為家人預定出遊行程，看一看網站提供的任何信息是否符合你的需求。

聚焦型任務：任務更具體、明確，通常都有一個正確答案或結束點。適用於定性和定量的測試。

比如：發現 Sunnyvale 公共圖書館的周六開放時間。

任務的撰寫非常重要，好的任務清晰明了，不會暗含任何會影響用戶行為的線索。模糊不清的任務會誤導用戶測試偏離研究重點。而含有明顯線索的任務，比如描述中有和頁面上相似的辭彙，那麼就不再是可用性研究了，而是字元匹配遊戲。

6. 進行試點研究（Pilot Study）

撰寫完測試任務之後，進行一次預測試來調整任務的措辭，預估每一個環節的任務量，確定各項任務的前後順序。試點研究還可以完善招募標準，確保招募正確的用戶參加測試。較早地發現測試問題好過於在正式環節中所有人都關注時出現問題。

7. 確定數據收集指標

收集指標的優先順序在定性可用性研究中並不高，因為參與的用戶數不多，收集的定量數據無法代表整個用戶群體，定性可用性研究主要是為了獲得設計洞察。但是，在其他定量研究，或是任務明確且有相當用戶數量的研究中，收集指標很重要。通常，可用性研究中的數據指標有：任務完成時間，用戶滿意度評分，任務成功率和失誤率。

如果要收集用戶的主觀數據指標（e.g. 任務的易操作性或滿意度，系統滿意度），可以在每一個任務完成後，或在整個測試環節結束後給出評分問卷即可。

8. 撰寫測試計劃

當已非常清楚將如何展開研究，以書面的形式撰寫一份測試計劃並分享給團隊。它將作為團隊內部的溝通工具，以及未來研究的備份。這份文件不需要很冗長，需包括以下幾個關鍵信息：

被測的產品（或網站）名稱
研究目標
流程：時間，日期，地點，形式
用戶參與信息
任務
評分表，問卷表
系統描述（e.g. 移動設備，桌面，電腦設置）

9. 動員團隊加入

可用性研究的一大益處在於可以推進團隊協作和支持。沒有什麼能比直接看到用戶如何回應設計界面更直觀、具有說服力。讓利益相關者一起來觀察有主持的測試環節可以幫助大家建立共識，削減溝通和撰寫文檔的時間。團隊有更多的時間用於設計，而非猜測和辯論。

動員利益相關者和團隊成員一起加入測試，要給他們充分的理由來參加。零食往往是一個很好的激勵因素！

如果團隊成員在不同的地域辦公，可以為他們提供遠程觀察以確保讓大家都參與進來。

——————————————
資料來源及進一步了解：

《如何規劃可用性測試》

英文原文鏈接：&

關於測試的幾個主要事實：

如果想建立一個優秀的網站，一定要測試

測試一個用戶比不做測試好一倍

在項目中，早點測試一位用戶好過最後測試50位用戶

人們對招募用戶代表的重要性估計過高

測試的關鍵不是要證明什麼或者反駁什麼，而是了解你的判斷力

測試是一個迭代的過程

沒有什麼比現場用戶的反應更重要

測試很重要！！！

測試過程中的常見問題：

用戶不清楚概念

他們就是不理解。他們看著網站或者頁面，要麼不知道他們說的是什麼，要麼他們以為自己知道，但是理解有誤。

他們找不到自己要找的字眼

這通常意味：1，你用來組織內容的分類不符合用戶的習慣，2，分類符合他們的習慣，但沒有使用他們期望的名字

內容太多了

有時候用戶要找的內容就在頁面上，但他們就是看不到。在這種情況下，需要：1，減少頁面上的整體干擾;2，把需要看到的內容設置的更加醒目，讓它們從可視層次結構中更加突出。

如何進行測試：

摘自：《Don『t make me think 》可用性測試部分

用戶研究的問題有點太大了，可用性測試（usability test）可以先說一說：
可用性測試的核心在於觀察用戶的行為(behavior),而不是用戶在想什麼（thinking）。因為用戶想的跟做的往往不一樣，或者說，用戶自己也不知道他在想什麼，借用汽車大亨亨利福特的話就是「如果我最初問消費者他們想要什麼，他們會告訴我"要一匹更快的馬」
所以可用性測試不是問用戶一系列問題，而是給予用戶一系列任務，讓他們去執行（perform）這些任務，而你，作為用戶體驗設計師，來觀察他們的行為。
如前面幾位知友所說，完整的可用性測試包括：
（1）招募志願者（2）找出你想要問的問題（3）將問題製作成任務清單（4）執行（5）分析評估數據。

其實每一項都有許多內容要注意，特別說下製作任務清單的注意事項吧：
1. 一張紙只放一個任務：這是為了防止用戶從相互關聯的任務中找到解決當前任務的線索。記住，你希望看到用戶在初次使用你的產品所出現的問題。同時這可以減少參與者的負擔，當參與者對當前任務不理解時也方便直接反饋
2.你對任務的描述中不能使用與產品界面上相同的用語。舉例，如果你想知道人們是怎樣使用app store的playlist功能時，不要描述任務說「創建一個playlist」,而應該說「將某一些歌曲編組，這樣可以方便你一起聽它們」在可用性測試中要時刻記住不要給參與者線索。因為用戶在實際使用你的產品時，沒有人會給他們線索，一切到要靠自己探索。
3.給自己準備一份任務記錄清單，應當包括任務、通過這一任務想達到的目的、觀察到的用戶行為等等，在觀察的過程中使用
4.任務描述需要不斷改進：如果你在測試過程中發現參與者不能理解某項任務,你需要改進這項任務的描述。雖然這樣很麻煩，但是一個任務描述一旦被修改好後，就可以在以後的實驗中持續使用。還是很值得的。

再說一下執行可用性測試的注意事項：
環境布置方面：
1.安靜，干擾少：不一定要請參與者去你的會議室，通常一個安靜的，可以與參與者發生互動的房間就可以了。小型會議室就不粗。同時注意要保持場所的整潔乾淨。注意不要使用那些需要參與者小心翼翼躡手躡腳的場所（如你父母的卧室）。
2.裝備要求：你並不需要一台高清攝像機，你只需要準備好你想要測試的系統，紙與筆就好。如果你還有其他的一起研究的同事，給你的測試設備裝一個屏幕共享軟體，讓你的同事可以看到用戶使用的情況，但是要注意，你應該讓你的同事在另一個房間觀察這些，而不是讓他們全部集中在參與者參加測試的房間（這樣會使得參與者更緊張）。
3.在真實情境中進行實驗：如果你希望在產品的真實使用情景（如火車上，街上）中進行測試，請確保在這之前你已經在辦公室進行過這些測試，積累了一些經驗。（因為真實情境往往比辦公室不可控，所以你需要提前演習）。

先寫這麼多吧，想到再補充

前段時間做過了一次針對全系統的可用性測試。因此寫了這篇文章作為個人對可用性測試的梳理和反思。可用性測試是一個體量很大的學科，僅僅從形式和平台兩個維度去分，就可以細分出十幾種不同的可用性測試，而每種不同的測試其研究方法還有相當大的不同。而且我相信，即使是同樣的一個目標，由不同的角色去設計和執行（比如諮詢公司的用研人員，某些公司專門的用研部門，或者業務線上的產品經理）也會有不同的方法和側重點，因此本文數千字的篇幅是不可能涵蓋可用性測試的方方面面的，甚至連作為某一種特定的可用性測試的工具書都不夠詳盡。這裡只是我作為一個業務部門裡的交互設計師，就我們採用的實驗室的可用性分析(usability lab studies)來談一談進行可用性測試的一些技巧和需要注意的點——總的來說，站在測試的大目標下，我們的每一個決定和方法都需要緊貼在目標上，每一個步驟都需要有合理的前因後果和清晰地邏輯。本文分為「可用性測試的時機」，「可用性測試的目標」，「以目標為導向的方案設計」和「測試的過程」四個部分。閱讀時間18分鐘。

可用性測試的時機

廣義的可用性分析是指讓用戶使用真實材料（包括真實的產品，模塊，頁面，原型，概念等）來探索其可用性的研究。包括了概念測試(concept testing)，實驗室的可用性分析(usability lab studies)，遠程的有指引可用性測試(moderated remote usability studies)，快速迭代的測試和評估(rapid iterative testing and evaluation)，眼動分析(eyetracking)等。我們將這些可用性測試的方法放到用戶研究方法的「定性—定量／態度-行為」坐標系中，我們發現各種可用性測試方法涵蓋了定性到定量的整個坐標軸，而在縱坐標軸上，可以看到可用性測試是偏向行為的。因此，不論是要對系統的可用性得到一個概括性的結論，還是要針對一個模塊的可用性進行精確的數據分析，我們都可以通過不同的測試方法來完成。然而不論是哪一種方法，可用性測試的核心都是建立在觀察上的。

那麼，我們應該在什麼時候去發起一次可用性測試？NNG的聯合創始人Jacob Nielsen列出了以下三個場景：

在迭代的過程中，特別是兩個迭代之間的時候。我們需要知道我們本期的設計是否解決了之前的問題，或者我們還需要繼續改進我們的設計方案。
數據不會騙人——對於競品的可用性分析，可用性測試得到的指標是非常有用的
在每一次新的發布之前，我們需要在腦海中有一個清晰的目標。當我們對現在的設計方案沒有很大的把握的時候，一次可用性測試可以告訴我們，新的版本是不是已經準備好發布了

總的來說，可用性測試最好是發生在整個設計周期里的研究階段（在連續迭代的過程中，研究可以被看作是一個設計周期的第一環，也可以是發布後的最後一環）在我們擁有一個真正的產品之前，我們需要知道一個方案是否可行，此時需要注意的是，我們需要平衡可用性測試材料的保真度。我們可以用一個盡量輕量級的原型來進行，這樣就可以儘快的對設計方案進行迭代；當然，它也要有足夠的細節來讓用戶明白我們到底做了一個什麼東西，並且能夠被帶入到我們預設的場景里。再就是在我們發布產品之後對於設計的評估和梳理，這個時候的可用性測試相當於一次低配版的田野觀察。

可用性測試的目標

這一部分我分兩點來說，第一是什麼是可用性以及我們是怎麼用可用性測試來衡量它的，第二是可用性測試是用來做什麼。

http://usability.gov為可用性給出的定義是「用戶與一個系統交互時體驗的質量」，而構成可用性的三個因素包括效度，效率和主觀滿意度。一般來說，我們通過以下的幾個維度來衡量系統的可用性：

設計的直觀性：產品的整體架構符合用戶的心智模型，換句話說，用戶可以輕鬆直觀的了解產品的結構，並利用導航系統在界面間清晰的移動
清晰性：界面元素表意清晰，交互方式和結果符合用戶的預期
可尋性：用戶可以快速準確的找到界面的關鍵信息
易學性：一個新用戶可以輕鬆的完成一個任務
使用的高效性：一個老用戶可以用系統高效的解決問題
可記憶性：在第一次訪問這個系統後，用戶可以記住足夠的內容來幫助他在以後使用的時候可以高效的使用
發生錯誤的頻率和嚴重性：用戶在使用系統時發生錯誤的頻率，這些錯誤的嚴重性，以及用戶能否修正這些錯誤
主觀滿意度：用戶在使用時的總體體驗，以及他們有多喜愛這個系統
……

那麼問題來了：我們是怎麼來衡量這些可用性指標的呢？我反思了我們之前做過的可用性測試，在所有的這些測試里，我們招募的都是從未使用過系統的目標用戶。這樣做的好處在於，上述的1-4點可以得到優質的結果。這樣的做法更適用於對設計概念和新功能的驗證，但是我們經常忽略的是——其實也是更難做的是——對舊功能的可用性測試。因為在平時的設計過程中，我意識到有的功能，即使是可用性很差，但是用戶在一段時間的使用後也可以正確的完成任務。或者是說，有的功能是為多次使用而設計的，這些功能模塊可能相當複雜或者有很長的操作路徑，特別是一些B端的產品，頁面的信息密度還相當的大，此時採用新用戶來進行可用性測試，不一定會得到準確的結論。

然而對於已有功能的可用性測試是必須而且重要的。舉例來說，我們有一個對對象進行批量操作的模塊，用戶需要對相似的對象進行多次的重複操作，此時的可用性就和上述的1-4點沒有多大關係了，而需要度量的是系統的效率和容錯性。此時就需要對可用性測試的思路進行一定的調整了，比如說，我們可以為我們的設計設定一個指標，來觀察我們的設計能否達到這個指標。比如，我們的目標是一個熟練的用戶可以在1分鐘內處理10個對象；在沒有辦法制定指標的時候，我們可以引入兩個方案的對比，從而選取更好的一個。當然，我們還需要隨時保持這樣一個意識，就是在具體的場景下，可用性測試是否是最好的方式，還是剛才那個例子，如果我們確定上面的1-4點都沒有問題，並且埋點數據的分析就可以回答現有的設計下用戶每分鐘處理對象的數量，那麼就沒有必要去進行一場可用性測試了。

所以最後就是關於可用性測試的使用場景，可用性測試主要有以下兩個作用：1. 衡量產品的可用性2. 定位產品問題及產生的原因。總的來說，可用性測試用於優化產品，但是不能告訴我們應該去做什麼需求，或者是用戶想要什麼。比如說，我的系統里有一張匯總用戶每日跑步詳情的月匯總表，可用性測試不會告訴我們用戶為什麼會去關心這張表，或者這張表會為系統帶來怎樣的價值——你需要通過一本叫做Hooked的書或者一些深度訪談來回答這些問題。請注意下面這個例子：可用性測試不回答用戶會去關心這張表裡的哪些欄位，只有在我們預設某一個欄位是重要的的時候，我們可以通過可用性測試來驗證我們的設計是否能讓用戶直觀的接受這個欄位信息。我們用數據埋點，點擊分析和問捲來了解產品里發生了什麼，用深度訪談來了解用戶的動機，態度，想法和體驗。而可用性測試的意義在於告訴我們一個問題為什麼發生。因此，我們不會去詢問用戶對這個產品的看法，而是將產品交給用戶，給他們布置一個任務，去觀察他們是如何與系統交互的，再通過這樣一些行為數據去了解系統中存在哪一些問題。比如說，我們通過埋點數據發現在一個複雜的註冊流程中的用戶資料上傳頁面存在巨大的跳出率，我們就需要可用性測試來告訴我們為什麼會有這樣的跳出發生，以及如何修正這個問題。

以目標為導向的方案設計

以目標為導向其實是我一直非常認可的一種設計思想，這種思想同樣也體現在了我的用戶研究上。這裡也分為兩個方面，一是和其他所有的用戶研究方法一樣，我們採用研究學習螺旋模型來規劃我們的可用性測試。這種模式的核心在於，研究的每一步都是建立在目標之上的；二是，我們方案里的每個行為都必須是有目的的——在我剛開始做用戶研究的時候，常犯的一個錯誤就是全套照搬別人的流程，然而在研究結束後的反思里才意識到，每一個行為都應該是有意義的，根據實際情況的不同，我們也需要對標準的流程進行修改或者補充。

設計了一個好的研究方案，就成功了一大半了。如上文所說，可用性測試的最大目的就是1. 研究用戶是否能順利的通過系統達成目的 2. 定位問題。第一點比較簡單，第二點稍微複雜一些。

先講第一點：在我們開始思考任何的方法和擬定任何的方案之前，我們需要先把本次測試的目標定清楚，在制定研究目標的時候，我建議根據上文列出的8個維度來思考（當然你也可以列出更多的維度）。比如，如果需要測試一個網站導航系統的可用性，那麼我更傾向於去關注系統的「設計的直觀性」，如果我需要測試一個新用戶是否能順利的預訂酒店，那麼我需要關注的可能就是系統的「清晰性」，「可尋性」和「易學性」。我們需要一個清晰的框架來幫助我們梳理我們的研究目的，這樣才能保證我們可以找到一個研究對象最關鍵的點，並且在後續的步驟中不會遺漏掉可能出現的問題。在這裡我們也可以看到，目標其實是和大小無關的：測試一整個預訂流程是否流暢是一個合理的目標，測試一個按鈕組的呈現方式是否足夠直觀也是一個合理的目標。

第二點就是定位問題，為了精準的定位到問題出現的原因，我的做法是將觀察的粒度拆得盡量細。而這樣的細分其實是分為兩個部分的：1. 通過關鍵假設將目標拆分為可以度量的條目 2. 在完成了任務的設計後，需要在任務流程里設置詳細的觀察點。

先說關鍵假設，其實假設是我們在做用戶研究的時候很容易忽略的一個步驟。這個步驟的含義是，我們在提出了目標之後，需要理清關於目標，我們（認為自己）已經知道的事情，我們預期用戶的行為是什麼，我們認為哪些地方會出現問題，以及我們可能會怎麼去解決這些問題。Frog的一個設計研究負責人Jon Freach提出，在研究的早期，假設可以幫助我們感知和思考我們需要去解決的問題，更好的選擇研究方案。

具體到我們的可用性測試來說，除了上述的作用，關鍵假設還可以為我們帶來這樣的價值：我們在第一步提出的目標其實是不能直接和具體的方法聯繫起來的，這個時候，關鍵假設可以幫助我們將目標拆分為更容易被翻譯成具體任務的條目。比如，我的目標是「測試用戶是否在酒店列表裡能找到合適的酒店」，我的關注點是頁面信息的「清晰性」，「可尋性」，那麼我的關鍵假設可能就是1. 用戶可以清晰的理解每條記錄里具體信息的意義 2. 我們提供的按價格，評分，星級的排序機制可以滿足用戶需求的 3. 用戶在尋找左側邊欄的篩選控制項時會遇到困難。那麼根據這樣一些假設，我們只要設計出可以全部覆蓋它們的任務流程，就可以很順利的達成目標了。

至此，我們已經走在了正確的道路上，我們的任務可以覆蓋我們目標可能存在的所有問題。現在再來回想一下我們在一場可用性測試里的目的：精準的定位問題，以及挖掘問題發生的原因。那麼，我們還需要一些方法來將測試的過程更加的精細化。在這裡我採用了設置觀察點的方法，這種方法的機制是：盡量將頁面上可能的觸點羅列出來，而所有的觸點分為和任務主流程有關的觸點(A)和無關的觸點(B)。在用戶完成任務時，我們需要觀察所有的觸點，此時對A類觸點的觀察可以覆蓋到所有和測試目標有關的用戶行為，而對B類觸點的觀察可以覆蓋到系統里一些其他的可用性問題。在用戶完成任務後的復盤過程中，我們需要就關鍵的，以及剛才出現問題的觸點與用戶進行訪談，以便確認問題發生的原因。這個方法的意義在於，在訪談的過程中，觀察者可以帶著目的和清晰地條例去觀察用戶行為，在之後的復盤中，可以更加系統的去還原用戶的行為，特別是那些通過直接觀察沒有辦法得出結論的點。

打個比方，如下圖所示，還是預訂酒店的例子。我們的目標是測試酒店搜索結果頁對於一個新用戶的的可用性，用戶任務是在該頁面找到一家價格適中，位置靠近老城，評價優異，可供全家4人住宿的房間。在酒店信息頁，可能的A類觀察點就包括了展示酒店信息的所有卡片；卡片內的所有欄位，鏈接，標籤，圖標，按鈕；篩選控制項；排序控制項；地圖入口；切換瀏覽方式的控制項等。可能的B類觀察點就包括了重新搜索的控制項，該目的地其他日期的預定情況等。在一場真實的可用性測試中，我們需要知道完成任務的所有路徑，以及最高效的那些路徑，而用戶很有可能會採用一些更低效的路徑，我們需要去觀察用戶是如何做出這樣的選擇的，並且在測試完成之後的復盤中，我們需要去向用戶了解是如何去認知其他的路徑的。比如在這個例子中，如果用戶想要高效的找到合適的住宿，他可能需要採用地圖視圖，價格篩選器，以及按照用戶評分對列表進行排序。而在實際的操作中，用戶有可能不會用到這些組件，他們甚至可能會不對列表進行任何操作就直接在列表中逐項瀏覽。那麼在測試的過程中，我們就需要去留意用戶是怎樣選擇並使用了一個組件，在過程中是否有誤操作，猶豫等。在測試完成後，需要去詢問用戶「請問你注意到列表上方的排序控制項了嗎？」，「我注意到你剛才想要去點擊地圖，但是最後放棄了，這是為什麼呢？」，「你有沒有想過需要將可以住4人的酒店篩選出來呢？你覺得你應該怎樣去操作才能完成篩選呢？」等

在完成了目標，關鍵假設和觀察點的梳理後，我們就可以開始拿著我們的測試計劃開始準備材料，數據，腳本以及用戶招募了。但是在走進房間開始和用戶進行近距離接觸之前，我通常會建議團隊再做以下這件事情：對可用性測試的計劃本身進行一次測試。一是為了保證測試過程的流暢，二是為了再次檢查我們的測試方案是否已經足夠細緻和全面了。在這樣一個非正式的測試里，我們通常會邀請一個同事（被試者對系統的熟悉程度需要根據測試目的來定），並嚴格按照正式測試的環境和流程進行。在這個流程中，我們可以看到準備的材料和數據是否合理，能否覆蓋我們的測試目的；對於那些設計多平台多設備多埠的任務，我們需要去保證數據和流程的流轉可以正常的進行。在這樣的測試里，得到的關於可用性的結論是沒有太大參考意義的，但是我們可以通過走完一個完整的流程對之前列出的觀察點進行查漏補缺。

最後就是招募用戶的數量。根據Nielsen和Landauer的研究，可用性測試發現系統中問題數量與測試人數遵循以下公式：

P=N (1-(1- L ) n )

其中P為發現問題的數量，N是系統中存在問題的總量，L是通過研究單個用戶可以發現的用戶比例，根據經驗L的值一般被定義為31%。

此時我們可以繪製出P關於n的曲線，如下左圖所示。此外，Nielsen還給出了以下的一份數據：根據83例NNgroup最近進行過的可用性諮詢的案例分析可以得出下右圖的可用性問題數量——招募用戶數量的關係。我們可以看到，在招募5-8名用戶的時候，就足以暴露出系統中的大部分可用性問題了。而此時再測試更多的用戶，並不會為我們的洞察帶來明顯的提升。因此在我們的可用性測試中，我通常會遵循以下的原則——這也是其他定性用戶研究用戶招募的一個通用原則——至少對5名用戶進行測試，當測試完第五名用戶的時候，如果我們發現問題的分布足夠集中，或者是不再出現新的問題，那麼針對這個目標的可用性測試就可以結束了。如果此時還在暴露出新的問題，那麼我們就還需要繼續進行測試，直到不再暴露明顯的新問題為止。

測試的過程

關於測試的過程我就不在這裡詳細描寫一次可用性測試所有的步驟了，下面列出幾個我認為可以最大程度上提升研究質量的點。

不要試圖去消滅測試的「人為因素」

一次典型的實驗室環境的可用性測試包括了一把椅子，一張桌子，用戶坐在屏幕前完成任務，由錄像機和各種感測器來追蹤所有發生的事情——包括眼動，面部表情，身體語言等等。這樣做的目標就是試圖消滅掉試驗中的一切實驗因素。甚至有一些用研人員建議「不要和用戶說話」。雖然我完全同意傾聽多於說話的觀點，但是——即使我完全保持沉默，甚至是躲在另外一個房間，用戶總是會知道他們是正在被觀察著的，我不用做任何事情，我的身份就是一個觀察者，這個時候適得其反的事情就發生了

用戶會把我視作一個標杆或者權威，他們會用他們的答案和行為來取悅我
因為他們懼怕在我眼中顯得愚蠢，因此他們會懼怕犯錯
他們的行為模式會和自然狀態下截然不同，他們會使用一些前所未有的方式去和我們的產品交互

我們需要意識到的是，可用性測試對於用戶來說本來就是一件不自然的事情——包括馬上我要說的Think Out Loud——就像洗澡的時候突然有人拉開浴簾問我水溫如何一樣。因此，我認為消滅測試的「人為因素」是一件徒勞的事情，相反，我們應該向前一步，去接受實驗環境和現實不同的這個事實。去扮演一個友好的角色，我習慣於在正式的測試開始之前和用戶有一個簡短的寒暄，講兩個適當的段子，一些和用戶貼近的小問題，注意自己的語氣和身體語言——事實上，這樣的開場適合於所有的定性研究。總之，創造一個輕鬆的氛圍，讓自己看上去親和友好，向用戶傳達我們是多麼高興他可以幫助我們發現系統的問題。當用戶願意走出他的舒適區時，我們就可以得到更多有價值的信息了。

Think Out Loud測試後的復盤

測試的目的之一是挖掘出更多的信息，而用戶的操作只能展示出測試時所發生的事情的很小一部分，除了仔細的觀察之外，我們會要求用戶在使用時將自己的思考/決策過程說出來，包括

當進入這個頁面的時候，我首先注意到了哪些東西？
我認為這個頁面是做什麼用的
我下一步想做什麼？我覺得頁面上哪些元素可以幫助我？
當我完成某一操作後，我預期會有怎樣的反饋？那真實的反饋是怎樣的？
界面上有哪些元素是我不明白的？
我進行了誤操作，我應該怎麼消除這個錯誤？
……

這樣，我們就可以保證我們設置的觀察點得到了充分的覆蓋，並且可以幫助我們對界面以及產品結構進行更全面的洞察。當然，Think Out Loud是建立在第一條的基礎上的，只有當用戶在一個足夠放鬆和信任的狀態下，他才會保持一個說話的狀態。

在用戶完成任務之後，我們已經收集到了足夠多的信息，但是如何保證信息的精確性呢？我使用的方法是進行一次復盤。我們需要回顧用戶剛才的路徑和所有操作，去確認每一個決定的原因，以及用戶沒有說出來的東西，比如：

你為什麼要點擊多次撤銷，而不去點擊清空按鈕呢？
我注意到你將滑鼠移到了A按鈕上，但是最後又沒有點擊呢？
我注意到你在進行B操作的時候顯得有些焦躁，這是為什麼呢？
……

保證信息的完整和精確，我們就可以告訴用戶說今天你的測試已近完成了

對測試方案的迭代

如果我說「我需要在研究的過程中修改我的研究方案」，很多研究者心中的第一反應多半是WTF？我理解很多人將中途修改方案視為洪水猛獸，因為這和「得到一個客觀的結論」的目的似乎是相悖的。他們說你需要5名用戶去做一模一樣的任務，這樣才能得到一個有意義的結論。

我當然同意要想辦法得到更客觀的答案，但是這並不意味著我們的研究方案就自始至終一成不變的了。我們應該在保證目標和關鍵假設不變的前提下，在每一次測試之後，對我們的觀察點以及復盤時的問題進行迭代——這個習慣同樣適用於其他的定性用戶研究方法——因為我們的觀察點和問題的擬定都建立在我們對系統了解的基礎上，但是有的時候，用戶和我們設計的體驗是兩回事情，曾經有同事反饋說，自己設置的觀察點很多都沒有用上，而用戶的很多行為完全出乎了他的意料。打個比方，如果前兩個用戶在任務的最開始都統統選擇了一條我們預料之外的路徑，而我們都沒有在這條路徑上設置任何的觀察點與問題。那麼，如果我們不在後續的研究上加上「你為什麼會點擊這個入口」這樣的問題，那麼我們永遠也不會知道用戶這樣奇怪舉動背後的原因。

參考文獻

Usability Engineering, 1993, Jakob Nielsen
Qualitative Research Design, 1996, Maxwell, https://www.sagepub.com/sites/default/files/upm-binaries/5057_Maxwell_Chapter_5.pdf
UX Research Cheat Sheet, 2017, Susan Farrell, https://www.nngroup.com/articles/ux-research-cheat-sheet/
How Many Test Users in a Usability Study, 2012, Jakob Nielsen, https://www.nngroup.com/articles/how-many-test-users/
Why You Only Need to Test with 5 Users, 2000, Jakob Nielsen, https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
How Do I Do User Research, 2014, Katerena Kuksenok, https://medium.com/hci-design-at-uw/how-i-do-user-research-fabc89acc7c9
Don』t Listen to Users and 4 Other Myths About Usability Testing, 2016, Icon8, https://uxplanet.org/dont-listen-to-users-and-4-other-myths-about-usability-testing-a061a0b746b8
UX Design Process Best Practices, UXPin, https://www.uxpin.com/studio/ebooks/ux-design-process-documentation-best-practices/
The Guide to Usability Testing, UXPin, https://www.uxpin.com/studio/ebooks/guide-to-usability-testing/
A 5-Step Process For Conducting User Research, David Sherwin, 2013, https://www.smashingmagazine.com/2013/09/5-step-process-conducting-user-research/

貼一下《探索用戶體驗》裡面經典的使用性測試時間表

然後下面是自己看了幾本書總結的可用性測試中需要記錄的參數（定量、定性）

ucdchina 為何訪問不了了呢？

設計師做用戶測試中應注意的那些事兒為什麼做用戶可用性測試？

設計師的工作本身是為了解決問題的，那麼發現根本問題，並識別業務方（如產品、運營等）給出的問題是不是真正的問題就成為了我們的重要工作內容。聽到來自用戶的真實聲音，有利於提升設計價值。如果團隊中有專業的用研夥伴，且時間充足的話，交由他們進行固然不錯，之前我也請網校的用研同事幫忙進行過一輪用戶測試，發現了很多可用性問題，但測試執行耗時長，且來回溝通也耗費了彼此大量的精力。 而當資源不足，或者時間緊張時，由設計師自己發起並執行測試也有很多好處。

設計師自己可以進行敏捷測試，作為項目的主要參與者，交互設計師更清楚產品目前有哪些問題，以及一些線上問題發生的背景原因。發現新問題後可以通盤考慮並快速落地到新一輪迭代中。只要覺得有必要隨時可以發起一次用戶測試，這個對象甚至可以是你身邊的同學、同事。一次快捷的走廊測試也能幫助我們發現一些問題。而當產品進行了大的改版或功能調整後，邀請用戶進行一次較深入的測試和訪談則非常有必要。這裡分享一下我近期進行優學寶分期項目改版後，為了解其效果進行的一次測試感受（優學寶分期是為用戶購買較高額課程時，提供分期支付功能的產品）。下面分階段闡述在測試的前中後階段應注意的問題。

一、測試前：

1. 明確測試目的：

產品目前處於的階段會極大的影響測試方式。如果是已經有了完整流程，需要通過用戶測試了解其可用性，並發現可改進的點，那麼邀請用戶直接上手使用產品，並觀察提問則是一個好方法。而當產品處於新方案可行性探索階段時則需要不同的測試方式和時間投入。

測試前需明確產品本身的目標用戶群特徵和本次重點的測試重點，從而推導出需要招募的測試對象，測試人數、涉及到用戶的性別／使用經驗等的佔比情況。這裡注意要預留1~2個備選測試用戶。

2. 被試者招募準備：

為得到更有效的測試結果，招募到合適的被試者至關重要。用戶招募主要涉及以下幾個環節。

1）撰寫用戶招募文檔投放

說明招募的原因、人員特徵、報酬（明確說明是完成整個測試後可得到）等信息。發布到朋友圈／內網／各種有潛在被試者的群等，盡量精準的觸達你的目標被試者。

2）撰寫用戶招募的篩選問卷，幫你篩選掉不符合需求的被試者。

推薦使用「問卷星」編輯問卷。建議提前在本地撰寫問題，有時由於網頁不穩定，可能你辛苦編輯的問卷隨著一次頁面刷新或或者瀏覽器崩潰就付諸東流了。

3）如果有必要可以電話聯繫篩選過的用戶，再次確認其基本情況，並了解其表達能力等確定是否是適合的目標測試對象。

這裡附上《招募用戶信息記錄表》供參考

3. 誰是適合的被試者對象？

a. 內部用戶--核心目標用戶 + 其他利益相關者

首先我們的目標用戶是測試訪談的主要對象，只有觀察和了解產品的實際使用者才能讓設計更有針對性。

之前在天貓實習時，要做梳理一個運營搭建頁面用的控制項庫，通過主動找實際使用該平台的運營夥伴，了解他們的使用習慣和訴求，找到他們的共同點和特殊訴求，遇到的問題，然後加以整理總結，得到了便於提升工作效率的控制項選擇與搭建系統框架。並在完成框架搭建後又找到之前接受訪談的夥伴進行溝通，以確認結構是否有效滿足了他們的訴求。如果缺失了這一環節，那麼單純從上層得到的信息很可能是不完整的，直接由其推導得出的方案通常也不如進行過訪談來的合適。

【之前在天貓實習時，要做梳理一個運營搭建頁面用的控制項庫，通過主動找實際使用該平台的運營夥伴，了解他們的使用習慣和訴求，找到他們的共同點和特殊訴求，遇到的問題，然後加以整理總結，得到了便於提升工作效率的控制項選擇與搭建系統框架。並在完成框架搭建後又找到之前接受訪談的夥伴進行溝通，以確認結構是否有效滿足了他們的訴求。如果缺失了這一環節，那麼單純從上層得到的信息很可能是不完整的，直接由其推導得出的方案通常也不如進行過訪談來的合適。】

另外，作為連接上下游的交互設計師應該站在更廣的範圍分析和看待問題。測試中發現的問題有時不僅局限在用戶直接交互的產品上，也應主動發現產品服務其他環節的一些問題。很多時候單純改變產品界面或交互方式只能微弱地提升體驗，而當輻射影響從其他相應環節時，能得到更佳的問題解決方案。為此在測試階段也可以適當邀請幾位服務於產品的其他利益相關者進行測試訪談，如銷售、客服、後台支持系統等人員。

【如本次訪談時，招募用戶中有一名「課程銷售」，通過對他訪談，了解到他們對於產品的一些功能入口只知皮毛，而不了解細節，實際在引導用戶使用時，也只能簡單地根據自己的理解進行說明。想起了平時打客服電話時，一些客服如程式化般告訴我一些問題解決方案，但根本無法實質性的解決問題。很可能也是由於他們只了解一些特定的文檔和培訓中說明的信息。但由於自己沒有實際完整的體驗過，從而無法在遇到不同場景問題時，有效提供幫助。面對上述問題，我就會把發現的問題反饋給負責對接的運營夥伴，告知她可能需要在幫助文檔撰寫和進行客服培訓時補充強調哪些點，從而幫助用戶體驗的提升。】

b. 外部用戶

在招募外部用戶方面，我們還在進行探索，後期計劃通過用戶後台的數據，找到我們希望深入訪談了解的對象進行溝通。通過簡訊或公眾號發布測試鏈接的方式進行篩選，當然前提是不要讓用戶覺得隱私被窺探，或者生活被打擾。

4. 準備測試腳本其他相關問卷和材料

充分準備好測試訪談流程和預設問題。

二、測試中

1. 內容準備清單

環境準備--

不被打擾的測試環境
穩定的網路環境和技術支持

當產品還處在測試階段時，網路環境可能不穩定。為避免測試過程中出現產品不可正常使用的情況，無論是線上遠程測試還是當面測試，需要在每次測試前確認好測試版的可用情況，並請相關技術人員時時在線，並在出現問題時及時提供幫助。

內容準備--

用戶測試訪談腳本（備註好該用戶的基本信息）
測試記錄設備（當沒有完備的測試工具時，可以直接用一個手機支架架起手機，對準用戶測試的手機手勢進行記錄）
需用戶填寫的其他材料（按使用順序擺放好，避免遺漏）
測試用的用戶數據（涉及到用戶隱私信息時，可以先準備一套數據，消除用戶顧慮，也避免浪費測試時間）
測試問題記錄表（梳理出整個流程中各個節點，方便快速記錄問題點）

2. 其他注意點：

設備的存儲量一定要夠。避免出現測試過程中設備存儲量不夠而無法繼續記錄的尷尬。
最好是2個人一組，1主試 + 1觀察記錄者，被試者需要隨測試進行在電腦上記錄下觀察到的問題，減輕測試後的整理壓力，測試後一起2者核對觀察到的信息，能夠在一定程度上避免問題疏漏。
無論被試對象是誰，都一定要說明「無正確之分、不必擔心傷害我們的感情。」尤其是招募了公司內部適當的被試者時，這種說明愈加重要，從而避免被試者不好意思對體驗不佳的點直接表述的可能。
對不同的被試者準備不同的訪談和測試內容，當產品有幾個差異較大的目標用戶群時，測試內容和觀察重點就應該有所不同。如對分期購買而言，經驗用戶和小白用戶的測試關注點和所提問題就有較大差異。
帶著對這個被訪者的了解進行訪談。每次測試前，應該在測試腳本上備註好之前了解到的用戶基本信息，從而幫助我們獲得更有針對性的反饋。

【記得有一次聽到店員要求一個顧客填寫一個表格，寫明遇到的問題，這個顧客很生氣的說：之前不是讓我在網上填寫過xx表格了嗎？那個也很長，難道沒用嗎？那幹嘛要我花時間去填寫？這個跟網上那個根本沒什麼區別嘛，浪費時間。

「值得讓用戶寫下來的，都值得你記住。」記住用戶以前告訴過你什麼，把它當回事兒，用在下次跟他的交流互動上，讓他感受到被尊重和重視。訪談測試的過程也是產品與用戶進行的一次對話。體驗設計的工作讓我們下意識的從用戶體驗的層面去思考問題更好的呈現方式，讓被試者也有良好的被試感受的同時，這個過程中表現出的專業度也會影響產品和品牌在用戶心中的分量。】

記錄並保存訪談的視音頻資料，但集中精力在測試環節，因為很有可能之後也沒有時間再仔細回顧記錄的內容。

三、測試後

測試結束後應該為不同用戶的訪談材料做好標註，精簡寫明用戶的關鍵特徵，便於後期整理回顧喚起記憶。

1. 迅速整理訪談結果給出解決方案。

當天的訪談結果當天整理完成，避免拖久了，內容積累，整理壓力大而漏掉內容。

2. 提供解決方案到下次測試中快速校驗

測試過程中發現問題後，迅速提出可能的解決方案，哪怕是用草圖的方式繪製出來，在下一輪測試中給到用戶詢問他們的感受。充分發揮交互設計師在此階段的優勢。

3. 可用性問題整理推動落地

對發現的問題進行分類，按優先順序處理。產出簡單報告。及時跟業務方進行溝通，盡量快速解決一些高優先順序，高危機的問題。積極跟進問題解決的進度，要讓測試結果被重視，並形成良好的反饋→體驗提升循環。給定問題解決的時間，不要拖延。

tip：有些問題遲遲不解決背後可能有複雜的歷史問題或者本身優先順序並不高，解決的投入產出比過低。遇到這種情況，不妨先記錄下來，積累幾個點以後再通盤思考，可能通過改造一個底層的東西，就能解決表層的多個問題。

根據產品階段和項目目的，用戶測試的形式、耗時不同，但只要是能夠為解決業務問題，並帶來新的體驗思考就算是一次有效的用戶測試。

雖然這個問題是很多年前提的了

你們那裡有沒有要招用戶研究實習生的，能讓我投個簡歷嗎？不要嘲笑我，算了，笑就笑好了，我也覺得自己搞笑的嘞

心理學研究生，統計，諮詢，邏輯思維、歸納總結、溝通交流這些都很好的。我在網路上投了好多簡歷，不知道是我簡歷沒寫好還是怎麼的，一直沒有接到過面試通知（人家的小心肝好痛哦，嚶嚶嚶）

推掉了文案策劃、新媒體運營、人力資源專員的offer，現在家裡要我考教師編，我真的不想去（反正也不是我想去就能去），我就想安安靜靜做用戶研究。

如果可以投簡歷，能不能告訴我一下，我會老老實實私信你的，只求一個投簡歷的機會，謝謝你，雖然我曉得這個謝謝你根本都沒分量也不能換錢，不過還是謝謝你

要忍耐，不要哭！
忍不住了！嚶嚶嚶嚶

也許在深入討論方法之前，簡略的回顧一下可用性測試（usability test）和用戶研究（user research）的由來，對我們的思考會有益處。歷史總是能讓我們更輕鬆的回答當下的問題 :），然後我們再去談論方法在設計中的用途。

沒人知道誰第一個發明了可用性測試，但我們知道80年代早期起（或者更早），人們逐漸對用戶界面的效率產生了興趣。在那時所謂的效率，只是任務時間，完成率一類硬性的指標。整個的任務構成看起來像極了實驗心理學的研究任務。所以，既是以今天的眼光來看，可用性測試依然強調實驗研究方法，就像所有的實驗心理學研究，在可用性測試中，我們首要關心的是實驗設計中是否存在混雜因素（confounding factors），對參與者的取樣是否合理，任務設計是否到位等等。實驗是測量的完美工具，對於用戶界面本身而言，沒有什麼是不可測量的，位置，顏色，尺寸，甚至參與者的情感，所有能夠想到的。但是，實驗提供精準測量本身，也正預示它的不足之處。精準的測量需要具體的任務，實驗的目的是回答非常具體的問題，而在設計實踐中，往往最需要解決的問題是難以量化的。

最早開始用戶研究的，想必是人類學（如果我們願意把用戶理解為一組特殊的部落的話，這個比喻就更加恰當了）。今天我們也能夠在用戶研究的教科書里找到人類學的蹤影，尤其是它的研究方法：訪談，問卷調查，田野調查，民族志等等。用戶研究，與其定性或者定量的研究方式無關，側重於理解而非測量。

如果把設計理解為解決問題，它需要我們嘗試去理解問題的本質，也同樣需要客觀的測量提出的解決方案成功與否。在以用戶為中心的設計實踐中，我們需要用戶研究和可用性測試。也許設計的藝術在於，究竟如何把兩種不同淵源的方法毫無間隙的設計實踐中來。也許這篇文章會有所幫助

尋找新的UX設計模型
http://www.usereye.org/newuxmodel

方法在設計實踐中的應用決定於所要解決的問題。教條的遵循某個研究範式讓工作變得無趣，當然也很難行得通。比如當產品就要發布的時候，去做一次旨在理解用戶行為的田野調查聽起來總是有些奇怪；或者在基本概念尚不確定時嘗試測量任務時間。

關於如何將用戶研究和可用性測試融入敏捷開發和迭代設計中，我想尚且需要很多的努力。也很希望看到這方面的討論。

用戶體驗研究是為了驗證你的設計，看看有什麼問題。所以你要先搞清楚設計思路，然後找用戶驗證（在訪談室讓用戶試用你的產品或服務），發現問題之後當場就給出新的方案進一步驗證（紙模或者畫圖），最後得出結論，幫助設計進行優化。然後再驗證，再優化。
找什麼人？找你的目標用戶，你的產品要賣給什麼人就找什麼人。
怎麼找？自己積累試用群，找老用戶，通過親戚朋友介紹，自己去路上抓，花錢通過調研公司找，都可以。記得要給錢。
———————————————
哦，你是要知道用戶對你產品的感興趣程度啊，，這個一般是叫做市場研究，市場調研，產品競爭力研究，不過做了沒什麼意義，徒增煩惱，產品用戶感不感興趣，拿出去賣一賣（試銷）不就知道了么，花了那麼多錢做研發，老闆會因為你一份可疑的調研報告就不上市產品嗎？naive.