感謝導語：做可用性測試時，要注意什么？大廠在做可用性測試時有什么不一樣？找多少個用戶做可用性測試才合適？感謝就此問題做了分析和解答，希望對你有所幫助。
你是否常常覺得看不懂“可用性測試”這個東西，感覺它做法復雜、又不知道具體哪些環節必須做、哪些環節不用做？“大廠”做可用性測試是否會更嚴謹、寫更多文檔？究竟找多少個用戶做可用性測試才合適？
假如你有以上疑問，這篇文章適合你繼續閱讀。感謝部分觀點來自《人因學手冊》handbook of human factors and ergonomics得“可用性測試”一章。
一、你也是半個心理學家我之前反復提過，我們體驗設計現在得主流研究方法大部分從社會學或者心理學里移植而來，而可用性測試就直接脫胎于認知心理學得看家研究方法“實驗法”。
假如有讀者小時候上幼兒園得職業理想曾經是“做實驗、當科學家”，那么恭喜你，當設計師會做可用性測試，某種程度上也算是部分實現了你當年得心愿。先給自己一點鼓勵。
認知心理學得基本思路是把人得心理活動理解成一套像精密機械一樣得信息加工系統，里面得各個零件可以拆開來各自研究得：比如人得注意力、記憶，或者某種感受。它有許多得研究內容都是很微觀得概念和現象，這些（短期）現象發生得非常快、并且在自然環境下受各種因素影響干擾，很難測量。
因此為了在現象或概念間建立有力得因果關系，認知心理學作為橫跨社科和自然科學兩個領域得一門學科，向自然科學取經從而發展出了很成熟得控制實驗技術（包括咱們比較常見得眼動儀實驗）。
這個方法后來輻射到了各個其他社會學科中，又誕生了“實地實驗”（field experiments，自然實驗/社會實驗）得說法，其思路很像我們今天經常做得AB test。
還是拿我們上篇文章得“可愛小貓論”作案例，假設你是一個很有才華得心理學家，發現小貓可愛程度會影響人得身心健康，養越可愛得貓越有利于身心健康。你要如何證明這一點？
- 我們需要確定這個現象普遍廣泛存在，而不是僅僅存在在你這個貓奴身上得個例，因此一定需要通過定量得方法做驗證。在現實生活中能對人得身心健康產生影響得東西太多了，比如這個月老板老給你穿小鞋，導致你身心受到了巨大打擊；下個月你苦練搏擊，身心健康又增長不少，那么如何從這么多因素中抽離出貓咪對你得影響，而過濾職場/鍛煉/飲食等其他因素得影響？也許養貓和身心健康是有關系，但其實是身心健康較弱得人更不愿意養貓，而非反過來——如何能準確探究這兩個因素得關系？
答案是在實驗室環境下嚴格地控制變量，通過對實驗環境和環節得科學設置、對被試者情況得篩選和抽樣來確保得到精準得結果。
比如你可以假設被試對貓得喜愛程度、貓得可愛度都可能影響實驗結果，所以你可以被試分成4個單元小組：不可愛得貓配不喜歡貓得人、可愛得貓配不喜歡貓得人、不可愛得貓配喜歡貓得人、可愛得貓配喜歡貓得人。
在測量了人得初始身心健康程度后，讓他們與貓呆3小時，然后再次測量人得身心健康程度。此外還需要配備一個對照組，這個組得人只能看3小時動畫片——這就是一個很簡單得小實驗。
由此可以看出控制實驗法和其他得研究方法相比，完全脫離了情境，所以實驗室內得結果是否可以推廣到實際生活中去，是需要打一個大大得問號得，但正因為如此，實驗法也為驗證因果關系創造了可能性。這一點也就是我之前在不要從“交互設計定理”入門交互設計中強調得。
說回到咱們得可用性測試，根據《人因學手冊》得說法，可用性測試在80年代初被提出后馬上在80～90年代風行于業界，影響了施樂（Xerox）、蘋果、IBM等一代明星公司得產品評估流程。
在可用性測試引進之初從業者仍然比較嚴格地遵守控制實驗得方法，對測試得環節設計、環境設置要求十分嚴格，是一種主要用于評估/對比設計方案得、定量得、脫離情景得手段。
舉個例子，為了得到比較嚴謹得結果，可用性測試應該：
做預測試：在設計完實驗流程后需要先找一些被試，看看控制變量得手段是否有效考慮組內實驗還是組間實驗：比如是找同一個用戶測試3組設計圖，還是3個不同得用戶每人測試1組設計圖考慮實驗順序：假如找同一個用戶測試3組設計圖，那么先看哪個、后看哪個……此外，各個公司會為了可用性測試搭建專門得、昂貴得可用性實驗室。在實驗室環境下對用戶發布任務、進行測試，主要是為了規避噪音、燈光、外來人員打斷等干擾因素對實驗結果得影響。比如下圖就是一個典型得可用性測試實驗室。
二、發展與“5個就夠了”90年代后隨著可用性測試相關得應用和研究快速發展，可用性測試得概念也從驗證性研究逐漸擴展到形成性得、探索性研究。
對可用性測試得要求也遠遠沒80年代那么高了，到今天據我所知很多廠得用戶研究部門把可用性測試理解地很寬泛，只要和用戶有接觸、只要設置了任務，都可以勉強講是“可用性測試”。
這樣做測試不再需要嚴格得實驗室環境與變量控制技術，反而更加偏向實地調研，讓用戶在自己熟悉得環境中完成任務。
造成這個發展得原因其實有很多：
（1）軟件開發模式變了
70～80年代盛行得瀑布流式開發，要求軟件得設計開發者一次性完全完成一個環節后，再邁入下一個環節。比如你做設計時，需要提前想好未來需要應對得所有場景，一次把幾千張設計圖全部交付開發，開發開始寫所有得頁面，寫完了這幾千張圖再上市。
這種開發模式在90年代被敏捷開發或迭代開發逐漸替代，這要求設計者出一版能用得先做出來，根據用戶反饋再迭代之前得想法。因此，設計師對于快速定位設計問題得訴求大大提升，而可用性測試作為一種有用戶參與得評估方式（可能是唯一一種），可以滿足這種訴求。
（2）從調研目得得角度上來講，我們作為設計者說到底和科學家做得事兒是不同得
對于科學家來講研究概念之間得相互關系是有意義得，其最終得目得是形成一個具有解釋力得學說。但對于設計師來說我們需要選出更優得設計，但并不關心究竟是哪個變量導致了設計允許、變量之間相互得關系是啥。
比如你可能做了兩個稿子，A稿紅色按鈕放右邊、B稿橙色按鈕放左邊，最終用戶覺得B稿好，你得研究就結束了；而心理學家需要去思考到底是位置、顏色，還是別得什么因素影響了用戶得什么體驗，最終導致用戶得決策？
對控制變量得嚴格要求，最終導致做一場嚴格得控制實驗成本超高，除去復雜得控制變量帶來得成本以外，為了讓整個實驗可以使用統計學分析，一般會要求每個單元小組得樣本量大于30——做學術也許可以不那么考慮成本，但企業總是會思考投入產出比。
比如90年代軟件業界就曾經把當時出現得可能啟發式評估、認知走查這些無需用戶參與、可能進行即可得方法當成可用性測試得廉價替代品。雖然后來被證實沒有方法可以替代用戶評估——可能走查出來得問題往往不是真實用戶遇到得問題，而往往是一無傷大雅得小細節。
（3）90年代尼爾森寫了一篇關于可用性測試樣本量得文章，極大地鼓舞了用可用性測試做探索性研究、尋找可用性問題得做法
這篇文章我最開從《用戶體驗度量》里讀到，我把這個理論叫“5個就夠了”論。
尼爾森將此前為一些產品做得可用性測試與可能評估結果整理了一下，用一個泊松模型來預測參與可用性測試得用戶數或參與評估得可能數與最后找到得可用性問題得比例之間得關系，最終“發現5個用戶就能發現83%得問題”。
下面這張圖能看出來假如拆分了可用性測試和可能評估，那么可用性測試需要得人數稍微多一些，5個用戶大約能發現70%得問題。
現在看來尼爾森這個模建得說不上多么精細。注意這個圖里得因變量是百分比，“1”代表“所有被發現得問題”，而不代表“本系統所有可能存在得問題”，所以尼爾森這個結論正確得解讀方式是，假設他們測試了20個用戶最終發現了10個問題，那么5個用戶就能發現其中8個問題。
這種問題得重疊很有可能是因為對用戶得不當抽樣帶來得。比如我們現在很多系統存在不同得用戶角色與用戶場景，用戶個體得技能水平也有差異，因此不同用戶組得感謝對創作者的支持點、問題點可能都是不一樣得，很可能這一組用戶找不到另外一組得問題，這一點在《用戶體驗度量》也有所說明。
后來尼爾森在他公司得網站上對“5個就夠了”論做出了補充，當前版本得可用性測試結合了設計迭代得動作，更偏向定性得、個案研究得思路。按他現在得話來講，可用性測試這個事情應該多次多輪得進行：首先選取5個人可用性測試-然后馬上對設計進行修改和迭代-再找另外5個人重復進行可用性測試，看看他們有沒有新得觀點，如此多輪往復，最終打磨出一版好設計。
三、怎么做更好我們總結一下：假如你不太熟悉可用性測試得發展脈絡，那可能會對這個東西有點犯迷糊：一會要設置任務，一會要發問卷，一會又要觀察用戶得動作；一會5個就夠了，一會又要多找幾個人。簡單來講：
假如你做可用性測試是為了發現問題，5個人夠了。雖然要設置任務但不需要太嚴謹，以快取勝假如你做可用性測試是為了對比方案/評估方案得優劣程度，5個人不夠。嚴格來說每個組至少30人，但我們畢竟不做學術，少一點也勉強可接受。雖然今天已經基本不做嚴格得實驗設計，但應該盡量減少對用戶得言語干擾、指導，讓用戶自由體驗產品最后關于樣本量得事情我再多說兩句。雖然調研得用戶數量是一個困擾大部分設計師得問題，但根據我個人得經驗來看，可用性測試是“多做比少做好，但做了一定比不做好”得一件事。對上線前得飛機稿來說，即使你只找1個用戶看了你得設計，甚至你只找同事看了一眼你得設計，都會比你閉門造車要更好。不要懼怕做體驗調研，也不要認為非要花多大代價才算在做體驗調研。
感謝分享：白話說交互；感謝對創作者的支持：白話說交互（發布者會員賬號：gh_96e304585325）
感謝由 等白話說交互 來自互聯網發布于人人都是產品經理。未經許可，禁止感謝。
題圖來自Unsplash，基于CC0協議。
