前段時間做了一次針對全系統的可用性測試。因此寫了這篇文章作為個人對可用性測試的梳理和反思。可用性測試是一個體量很大的學科，僅僅從形式和平台兩個維度去分，就可以細分出十幾種不同的可用性測試，而每種不同的測試其研究方法還有相當大的不同。而且我相信，即使是同樣的一個目標，由不同的角色去設計和執行（比如諮詢公司的用研人員，某些公司專門的用研部門，或者業務線上的產品經理）也會有不同的方法和側重點，因此本文數千字的篇幅是不可能涵蓋可用性測試的方方面面的，甚至連作為某一種特定的可用性測試的工具書都不夠詳盡。這裡只是我作為一個業務部門裡的交互設計師，就我們採用的實驗室的可用性分析(usability lab studies)來談一談進行可用性測試的一些技巧和需要注意的點——總的來說，站在測試的大目標下，我們的每一個決定和方法都需要緊貼在目標上，每一個步驟都需要有合理的前因後果和清晰地邏輯。本文分為「可用性測試的時機」，「可用性測試的目標」，「以目標為導向的方案設計」和「測試的過程」四個部分。閱讀時間18分鐘。
作者
學霸君 交互設計師 楊子建
可用性測試的時機
廣義的可用性分析是指讓用戶使用真實材料（包括真實的產品，模塊，頁面，原型，概念等）來探索其可用性的研究。包括了概念測試(concept testing)，實驗室的可用性分析(usabilitylab studies)，遠程的有指引可用性測試(moderated remote usability studies)，快速迭代的測試和評估(rapid iterative testing and evaluation)，眼動分析(eyetracking)等。我們將這些可用性測試的方法放到用戶研究方法的「定性—定量／態度-行為」坐標系中，我們發現各種可用性測試方法涵蓋了定性到定量的整個坐標軸，而在縱坐標軸上，可以看到可用性測試是偏向行為的。因此，不論是要對系統的可用性得到一個概括性的結論，還是要針對一個模塊的可用性進行精確的數據分析，我們都可以通過不同的測試方法來完成。然而不論是哪一種方法，可用性測試的核心都是建立在觀察上的。
那麼，我們應該在什麼時候去發起一次可用性測試？NNG的聯合創始人JacobNielsen列出了以下三個場景：
1. 在迭代的過程中，特別是兩個迭代之間的時候。我們需要知道我們本期的設計是否解決了之前的問題，或者我們還需要繼續改進我們的設計方案。
2. 數據不會騙人——對於競品的可用性分析，可用性測試得到的指標是非常有用的
3. 在每一次新的發布之前，我們需要在腦海中有一個清晰的目標。當我們對現在的設計方案沒有很大的把握的時候，一次可用性測試可以告訴我們，新的版本是不是已經準備好發布了
總的來說，可用性測試最好是發生在整個設計周期里的研究階段（在連續迭代的過程中，研究可以被看作是一個設計周期的第一環，也可以是發布后的最後一環）在我們擁有一個真正的產品之前，我們需要知道一個方案是否可行，此時需要注意的是，我們需要平衡可用性測試材料的保真度。我們可以用一個盡量輕量級的原型來進行，這樣就可以儘快的對設計方案進行迭代；當然，它也要有足夠的細節來讓用戶明白我們到底做了一個什麼東西，並且能夠被帶入到我們預設的場景里。再就是在我們發布產品之後對於設計的評估和梳理，這個時候的可用性測試相當於一次低配版的田野觀察。
可用性測試的目標
這一部分我分兩點來說，第一是什麼是可用性以及我們是怎麼用可用性測試來衡量它的，第二是可用性測試是用來做什麼。
usability.gov為可用性給出的定義是「用戶與一個系統交互時體驗的質量」，而構成可用性的三個因素包括效度，效率和主觀滿意度。一般來說，我們通過以下的幾個維度來衡量系統的可用性：
1. 設計的直觀性：產品的整體架構符合用戶的心智模型，換句話說，用戶可以輕鬆直觀的了解產品的結構，並利用導航系統在界面間清晰的移動
2. 清晰性：界面元素表意清晰，交互方式和結果符合用戶的預期
3. 可尋性：用戶可以快速準確的找到界面的關鍵信息
4. 易學性：一個新用戶可以輕鬆的完成一個任務
5. 使用的高效性：一個老用戶可以用系統高效的解決問題
6. 可記憶性：在第一次訪問這個系統后，用戶可以記住足夠的內容來幫助他在以後使用的時候可以高效的使用
7. 發生錯誤的頻率和嚴重性：用戶在使用系統時發生錯誤的頻率，這些錯誤的嚴重性，以及用戶能否修正這些錯誤
8. 主觀滿意度：用戶在使用時的總體體驗，以及他們有多喜愛這個系統
9. ……
那麼問題來了：我們是怎麼來衡量這些可用性指標的呢？我反思了我們之前做過的可用性測試，在所有的這些測試里，我們招募的都是從未使用過系統的目標用戶。這樣做的好處在於，上述的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人的酒店篩選出來呢？你覺得你應該怎樣去操作才能完成篩選呢？」等
打個比方，如下圖所示，還是預訂酒店的例子。
我們的目標是測試酒店搜索結果頁對於一個新用戶的的可用性，用戶任務是在該頁面找到一家價格適中，位置靠近老城，評價優異，可供全家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名用戶進行測試，當測試完第五名用戶的時候，如果我們發現問題的分佈足夠集中，或者是不再出現新的問題，那麼針對這個目標的可用性測試就可以結束了。如果此時還在暴露出新的問題，那麼我們就還需要繼續進行測試，直到不再暴露明顯的新問題為止。
測試的過程
關於測試的過程我就不在這裡詳細描寫一次可用性測試所有的步驟了，下面列出幾個我認為可以最大程度上提升研究質量的點。
不要試圖去消滅測試的「人為因素」
一次典型的實驗室環境的可用性測試包括了一把椅子，一張桌子，用戶坐在屏幕前完成任務，由錄像機和各種感測器來追蹤所有發生的事情——包括眼動，面部表情，身體語言等等。這樣做的目標就是試圖消滅掉試驗中的一切實驗因素。甚至有一些用研人員建議「不要和用戶說話」。雖然我完全同意傾聽多於說話的觀點，但是——即使我完全保持沉默，甚至是躲在另外一個房間，用戶總是會知道他們是正在被觀察著的，我不用做任何事情，我的身份就是一個觀察者，這個時候適得其反的事情就發生了
• 用戶會把我視作一個標杆或者權威，他們會用他們的答案和行為來取悅我
• 因為他們懼怕在我眼中顯得愚蠢，因此他們會懼怕犯錯
• 他們的行為模式會和自然狀態下截然不同，他們會使用一些前所未有的方式去和我們的產品交互
我們需要意識到的是，可用性測試對於用戶來說本來就是一件不自然的事情——包括馬上我要說的ThinkOut Loud——就像洗澡的時候突然有人拉開浴簾問我水溫如何一樣。因此，我認為消滅測試的「人為因素」是一件徒勞的事情，相反，我們應該向前一步，去接受實驗環境和現實不同的這個事實。去扮演一個友好的角色，我習慣於在正式的測試開始之前和用戶有一個簡短的寒暄，講兩個適當的段子，一些和用戶貼近的小問題，注意自己的語氣和身體語言——事實上，這樣的開場適合於所有的定性研究。總之，創造一個輕鬆的氛圍，讓自己看上去親和友好，向用戶傳達我們是多麼高興他可以幫助我們發現系統的問題。當用戶願意走出他的舒適區時，我們就可以得到更多有價值的信息了。
Think Out Loud&測試后的復盤
測試的目的之一是挖掘出更多的信息，而用戶的操作只能展示出測試時所發生的事情的很小一部分，除了仔細的觀察之外，我們會要求用戶在使用時將自己的思考/決策過程說出來，包括
• 當進入這個頁面的時候，我首先注意到了哪些東西？
• 我認為這個頁面是做什麼用的
• 我下一步想做什麼？我覺得頁面上哪些元素可以幫助我？
• 當我完成某一操作后，我預期會有怎樣的反饋？那真實的反饋是怎樣的？
• 界面上有哪些元素是我不明白的？
• 我進行了誤操作，我應該怎麼消除這個錯誤？
• ……
這樣，我們就可以保證我們設置的觀察點得到了充分的覆蓋，並且可以幫助我們對界面以及產品結構進行更全面的洞察。當然，Think Out Loud是建立在第一條的基礎上的，只有當用戶在一個足夠放鬆和信任的狀態下，他才會保持一個說話的狀態。
在用戶完成任務之後，我們已經收集到了足夠多的信息，但是如何保證信息的精確性呢？我使用的方法是進行一次復盤。我們需要回顧用戶剛才的路徑和所有操作，去確認每一個決定的原因，以及用戶沒有說出來的東西，比如：
• 你為什麼要點擊多次撤銷，而不去點擊清空按鈕呢？
• 我注意到你將滑鼠移到了A按鈕上，但是最後又沒有點擊呢？
• 我注意到你在進行B操作的時候顯得有些焦躁，這是為什麼呢？
• ……
保證信息的完整和精確，我們就可以告訴用戶說今天你的測試已近完成了
對測試方案的迭代
如果我說「我需要在研究的過程中修改我的研究方案」，很多研究者心中的第一反應多半是WTF？我理解很多人將中途修改方案視為洪水猛獸，因為這和「得到一個客觀的結論」的目的似乎是相悖的。他們說你需要5名用戶去做一模一樣的任務，這樣才能得到一個有意義的結論。
我當然同意要想辦法得到更客觀的答案，但是這並不意味著我們的研究方案就自始至終一成不變的了。我們應該在保證目標和關鍵假設不變的前提下，在每一次測試之後，對我們的觀察點以及復盤時的問題進行迭代——這個習慣同樣適用於其他的定性用戶研究方法——因為我們的觀察點和問題的擬定都建立在我們對系統了解的基礎上，但是有的時候，用戶和我們設計的體驗是兩回事情，曾經有同事反饋說，自己設置的觀察點很多都沒有用上，而用戶的很多行為完全出乎了他的意料。打個比方，如果前兩個用戶在任務的最開始都統統選擇了一條我們預料之外的路徑，而我們都沒有在這條路徑上設置任何的觀察點與問題。那麼，如果我們不在後續的研究上加上「你為什麼會點擊這個入口」這樣的問題，那麼我們永遠也不會知道用戶這樣奇怪舉動背後的原因。