內部試跑的時候，團隊每個人都覺得這個介面直覺順手，上線之後，後台數據卻顯示有一大群使用者卡在同一個按鈕前反覆點擊，最後放棄離開，而負責設計的人盯著同一個畫面，竟然完全看不出問題出在哪裡。這不是設計師不夠專業，問題往往出在太熟悉自己一手打造的產品，反而看不到使用者眼中真正的路障。
可用性測試（Usability Testing）要解決的正是這種矛盾，它不問設計者「你覺得好不好用」，而是找真實使用者來，實際觀察他們會不會卡關、卡在哪一步。Nielsen Norman Group 長期研究使用者體驗就發現，再資深的設計師也沒辦法只靠經驗設計出零死角的介面，團隊還是得靠反覆觀察真實使用者的行為來修正，少了這一步，問題往往要等到上線後流量掉了才被發現，而那時修正的成本已經高出許多。
這篇把定範圍、招募、任務設計、執行觀察、分析這五個步驟一次講完，先從第一步怎麼決定這次測試只回答哪一個問題講起。
可用性測試是什麼？和使用者驗收測試有什麼不同？
國際標準 ISO 9241-11 對「可用性」給出的定義，把好不好用拆成三個可被觀察、可被衡量的維度。使用者能不能達成目標稱為有效性（effectiveness），達成目標花了多少力氣與時間稱為效率（efficiency），使用完之後的主觀感受則稱為滿意度（satisfaction）。可用性測試就是圍繞這三個維度設計任務，讓真實使用者在觀察下完成一連串具體任務，而不是只問一句「你覺得好不好用」。
這個定義很容易跟另一個常被排進同一張時程表的使用者驗收測試（User Acceptance Testing，UAT）搞混。UAT 測的是功能對不對、規格有沒有做完，例如退換貨按鈕按下去，訂單狀態有沒有正確更新；可用性測試測的是使用者能不能順利找到並完成任務，同一個退換貨按鈕，使用者到底找不找得到、要點幾次才點對。兩者驗證的東西完全不同，一個確認做出來的東西符合規格，一個確認做出來的東西使用者用得順，排進同一輪驗收流程，不代表可以互相取代。
也順手澄清一個常見誤解，可用性測試不是問卷調查。滿意度問卷問的是使用者「覺得」介面好不好用，答案容易受當下心情、用詞順序影響；可用性測試看的是使用者「實際上」怎麼卡關，觀察到的行為比自陳的感受更接近真相。接下來的五個步驟，就是怎麼把這套觀察方法從頭到尾跑一遍。
步驟一：定範圍，先決定這次測試只回答哪一個問題
很多團隊安排可用性測試時，常犯的第一個錯誤是想把整個網站一次測完。測試前應該先做的，是寫下這次唯一要回答的研究問題，比如「使用者能不能找到退換貨流程」，而不是「大家覺得網站好不好用」這種沒有邊界的題目。範圍一旦模糊，後面的招募、任務設計、分析都會跟著失焦，測完也說不出個所以然。
定好研究問題之後，還有兩個關鍵分岔要在這一步就決定。第一個分岔是要找問題還是要拿分數，這牽涉到接下來怎麼設計任務與怎麼分析資料；第二個分岔是要主持人在場即時互動，還是讓使用者自己遠端完成、事後看紀錄。這兩個決定會直接影響招募人數、測試流程長短，甚至要準備的工具。
如果擔心可用性測試會拖成曠日費時的大工程，其實最精簡的版本只要三天，第一天規劃研究問題與任務，第二天找幾位使用者實際測試，第三天把觀察到的問題整理出來。範圍顧好，可用性測試不必是大工程，先把這兩個分岔想清楚，再往下看怎麼選。
這次測試該選質化，還是量化？
質化測試著重找問題、看行為，適合設計還在調整階段、團隊想知道使用者到底卡在哪一步；量化測試著重拿分數、算成功率，適合要跟上一版比較差異，或是要拿一個具體數字說服團隊改版。兩者要回答的問題不一樣，不需要同一場測試硬塞兩種目的，先想清楚這次要解決的是哪裡卡住還是進步了沒有，再決定要質化還是量化。
面對面主持，還是讓使用者自己遠端做？
面對面主持，包含用線上會議即時互動，能追問使用者當下的想法、看到即時的表情與猶豫，適合需要深入挖掘卡關原因的階段；遠端非同步讓使用者自己完成任務、事後回看錄影紀錄，能同時收集比較多樣本、成本也比較低，適合已經有明確假設、只是要驗證的階段。這兩種方式不是二選一定生死，不少團隊會交替搭配，前期用面對面主持挖掘問題，後期用遠端非同步驗證修正有沒有生效。
步驟二：招募，5 個受測者為什麼通常就夠
範圍定好，接下來要面對的問題就是找誰來測、找幾個人才夠。多數人直覺會覺得受測者越多，結果越準，但 Nielsen 與 Landauer 提出的數學模型顯示，同一個使用者族群只要找 5 個人測試，就能抓出約 8 成到 85% 的可用性問題，超過這個人數之後，每多加一位受測者能多發現的新問題會快速下降。
這個發現帶出一個更划算的做法。與其把預算一次砸在一場 15 人的豪華測試，不如拆成 3 次、每次各測 5 人，而且每次測完都真的動手修正，再拿去下一輪驗證。這樣跑三輪，遠比一次測完 15 人卻只改一次版更有效，因為問題是分批被發現、也分批被修掉的，不是全部塞進一次測試才處理。
不過這個 5 人就夠的前提，是產品服務的是同一個使用者族群。如果產品同時服務差異很大的兩群人，例如一般消費者跟後台管理者，那就要對每個族群各招 3 到 5 人，而不是把總數湊到 5 人就宣告收工，不同族群卡關的地方本來就不一樣，合併計算等於漏測其中一群人。
人數決定之後，下一步是招募對象要避開哪些人，以及怎麼用篩選問卷（screener）先把不符合資格的人擋在外面。
誰不適合當受測者？
三種人最容易讓招募結果失真。
- 產品、設計或工程團隊的成員：他們對介面太熟悉，已經看不出真正的困難在哪裡。
- 專案的利害關係人：像是主管或客戶窗口，這類人給的回饋容易不夠中立，會不自覺往「這樣做才對」的方向靠。
- 習慣用利害關係人角度思考的人：即使他們不在專案團隊裡，思考方式也跟真實使用者不同，不是站在使用者的角度看問題。
找同部門同事看設計稿、給意見沒有問題，但別讓這些人正式坐上受測者的位置，篩選問卷這時候就派得上用場，先把這幾種人擋在報名名單外面。
步驟三：任務設計，用詞不慎就會誤導整場測試結果
招募到對的人之後，接下來要面對的是怎麼把任務寫對，這一步看起來只是寫幾句話，卻是整場測試最容易悄悄搞砸的環節。
第一個重點是給情境，不要只給指令。直接說「請找到退換貨頁面」，跟給一段「你剛買到不合尺寸的衣服，想辦理退換貨」的情境，會讓使用者做出完全不同的真實反應，前者等於先把答案的關鍵字告訴受測者，後者才是使用者真正遇到問題時會怎麼想、怎麼找。
第二個重點是用詞不小心就會造成促發效應（priming），任務描述裡如果用了介面上按鈕或選單的字眼，等於先把答案洩漏給受測者，測出來的結果會比實際情況樂觀許多。第三個重點是每個任務都要有清楚、可判斷完成了沒的終點，不要問開放到連主持人自己都答不出來的問題，不然連要不要判定使用者成功都沒有標準。
實務上，一場 45 到 60 分鐘的測試大概安排 5 到 7 個任務就足夠，任務排太多，使用者到後段會累，觀察品質也會下降。正式上場前，一定要先找同事或朋友跑一次先導測試（pilot test），把寫壞、會誤導人的任務句子抓出來修掉，再拿去對真正的受測者。
要怎麼避免用詞不小心引導受測者？
最直接的做法是把任務裡所有介面上會出現的字眼都換掉，只留下使用者要達成的目的。比如「請點擊搜尋按鈕，找出這件商品」洩漏了搜尋按鈕這個操作路徑，改寫成「你想找一件適合露營穿的外套，你會怎麼做」，只給情境、不給操作步驟，使用者要自己想辦法找到搜尋功能，測出來的行為才是真的。寫完每一個任務，都可以自問一次，這句話裡有沒有藏著介面上的字眼，藏著的話就換掉。
步驟四：執行觀察，主持人最容易犯的三個錯誤
任務寫對之後，接下來就是正式坐到使用者對面，這一關考驗的不是任務寫得好不好，而是主持人當下的臨場反應。
執行階段的黃金原則是出聲思考法（think-aloud），請使用者一邊操作一邊把心裡的想法講出來，而不是等做完才回頭問「你剛才在想什麼」，事後回想已經失真，即時講出來的猶豫、抱怨、猜測，才是最有價值的觀察素材。
主持人的角色是觀察者，不是教學者，這句話說起來簡單，現場最容易犯的錯誤卻有三個。
- 使用者卡住時忍不住出手幫忙：一伸手介面就等於被主持人修好了，測不出真正的困難。
- 用帶答案的問句追問：像是「你不覺得這樣比較好嗎」，使用者聽到暗示，回答自然會往主持人想要的方向靠。
- 開場沒先講清楚測的是產品、不是在測人：使用者會擔心自己表現不好，操作變得不自然，講出真心話的意願也會降低。
一場測試大致分成三段，開場先破冰、說明規則，中段讓使用者依序完成任務，收尾再追問幾個開放式問題。這個順序看似簡單，卻是讓使用者放鬆、講真話的基本架構。
案例：一句被誤解的標題，重測一次就救回來
美國國家癌症研究院曾經測試一份衛教手冊，使用者對內容本身都看得懂，卻誤以為手冊標題所指的對象只限特定族群，以為這份資料跟自己無關，直接跳過不看。團隊沒有大改內容，只把標題改得更明確，重新測試一次，這次所有受測者都正確理解這跟自己有關。這個案例證明，先觀察出問題、動手修正、再驗證一次，比一次到位的完美設計更可靠，可用性測試從來不是一次考試，而是一個可以重複跑的迴圈。
步驟五：分析，把發現的問題排出改善優先順序
測試跑完，真正的工作其實才剛開始，逐字稿和錄影不會自己整理出結論。每一場測試結束，應該趁記憶還新鮮的時候先做一次場次小結，把這位受測者卡關的地方快速記下來，再進行下一場；等所有場次都跑完，再把重複出現的問題歸類整理。
歸類完，還要決定誰先修。判斷的依據有三個，這個問題發生的頻率有多高、對業務目標的影響有多大、使用者當下的挫折感受有多重。頻率高、對業務影響大的問題該排在最前面；就算頻率不高，只要會讓使用者直接放棄整個任務，挫折感受夠重，一樣要提前處理，不能單看發生次數決定順序。
如果這次測試有做量化，還可以用國際通用的系統可用性量表（System Usability Scale，SUS），把好不好用換算成一個能跟其他專案比較的分數。MeasuringU 長期蒐集的資料顯示，SUS 分數全球平均落在 68 分上下，高於這個數字才算中等以上，低於這個數字就代表使用者體驗還有明顯的改善空間。
這幾年還多了一個新做法可以加速分析，用 AI 工具把訪談錄音自動轉成逐字稿、抓出反覆出現的關鍵詞或主題，把過去要花好幾天人工聽打、手動歸類的時間大幅縮短，讓分析的人能把精力留在判斷這個問題該不該優先修，而不是耗在打字聽打上。
分析完的結果不是放進報告就結束，而是要跟團隊分享，排進下一輪的迭代，這也呼應步驟二提到的原則，比起一次做到完美的大型測試，修完再測一次，才是真正有效的做法。
怎麼幫問題排出修復優先順序？
三個判準要交叉使用，不是各自獨立打分數。出現頻率高、又對業務影響大的問題，理所當然排在最前面處理；但就算頻率不高，只要會讓使用者直接放棄任務，挫折感受極重，也要提前處理，不能因為只有一兩個人踩到就往後排。實務上常見的做法是畫一張簡單的象限圖，橫軸放頻率、縱軸放嚴重程度，落在右上角的問題最優先。
AI 工具怎麼加速整理逐字稿與歸類問題？
具體來說，AI 轉錄工具能把整場測試的錄影或錄音自動轉成文字逐字稿，省下人工逐句聽打的時間；有些工具還能進一步抓出受測者反覆提到的關鍵詞、或是情緒明顯轉負面的段落，幫忙先框出幾個可能的問題熱區。人力要做的不是從頭聽到尾，而是複核 AI 標記出來的重點、做最後的判斷，這是這幾年才開始普及的做法，重點在於 AI 能幫忙做什麼，而不是比較哪一套工具比較好用。
回到一開始那個矛盾，內部試跑時人人都說順手，上線卻有一群人卡在同一個按鈕前放棄，不是設計師不夠專業，而是沒有人能設計出自己看不見的盲點。可用性測試存在的意義，從來不是拿來證明設計是對的，而是持續把使用者看得到、設計者看不到的地方找出來、修掉、再驗證一次。這五個步驟做完一輪，不代表可用性測試就此結束，而是下一輪迭代的起點。