UX 測試的核心做法是可用性測試：請符合目標客群條件的人，用你的網站完成幾個真實任務，例如找到某項服務的收費說明並送出詢問，過程中請他邊做邊說出想法，觀察他在哪裡猶豫、點錯或放棄。Nielsen Norman Group 建議每輪不超過五位受測者、改完再測下一輪，比一次找很多人更有效率。測完後依問題發生的頻率、影響程度與是否會反覆困擾使用者排出修正順序，再搭配問卷與網站行為數據確認改善方向。
先決定這次測試要回答什麼問題
可用性測試由三個元素組成：主持人、任務與受測者。動手招募前，先把要驗證的事寫成具體問題，例如「新訪客能不能在首頁找到服務項目」「手機上填完詢價表單會卡在哪個欄位」。問題越具體，任務越好設計，結論也越能直接轉成修改項目。
接著決定測試性質。Nielsen Norman Group 把可用性測試分成兩類：質化測試著重收集洞察與發現，適合找出問題；量化測試著重收集描述體驗的指標，例如完成率、花費時間，適合做前後比較。官網改版前若目的是找出問題，用質化測試即可，人數不必多，但每場要看得仔細。
測試不一定要等網站上線。還在規劃階段時，可以用線框圖或可點擊原型測導覽與資訊架構，做法可參考線框圖的用途與畫法，越早發現結構問題，修改成本越低。
寫任務腳本：真實、可執行、不給提示
任務寫得好不好，決定能不能觀察到真實行為。Nielsen Norman Group 整理了三個原則：
- 任務要真實：依受測者的身分設計情境，例如「你想替公司換一個官網，先了解這家廠商做過哪些類型的網站」。
- 任務要能執行：請對方實際操作，而不是問「你會怎麼找」。
- 不給線索、不描述步驟：避免寫「點選上方選單的服務」，步驟描述常藏著介面的提示；但不給線索不等於含糊，任務仍要交代清楚目標。
一份腳本通常包含：開場說明（強調測的是網站，不是受測者）、幾個暖身問題、依序執行的任務、每個任務後的簡短提問，以及結束前的整體訪談。正式開始前先找一兩個人試跑，修正任務文字、估算時間，並確認測試環境與網站都能正常運作。
受測者怎麼找、每輪要找幾位
受測者要能代表真正的訪客。先寫一份篩選問卷，用職務、決策角色、使用過哪些同類服務等條件過濾，避免只找到熟悉公司產品的人。來源可以是既有客戶、電子報訂閱者，或在官網放招募連結；同事與親友對產品太熟，適合用來試跑腳本，不適合當正式受測者。
人數方面，Nielsen Norman Group 的建議是每輪不超過五位，把預算分成幾輪小測試，每輪修正後再測。網站若有幾群差異很大的使用者，例如採購人員與工程人員，就要分群招募：兩群時每群三到四位，三群以上每群約三位。若目的是取得可統計的量化指標，則需要更多受測者。
測試若要錄影或錄音，事前說明用途、保存方式與誰會看到，並請受測者簽署同意書；涉及個人資料的處理，請以主管機關公告與專業意見為準。
主持與紀錄：放聲思考與觀察重點
常見的方法是放聲思考：請受測者一邊操作，一邊持續說出心裡的想法。主持人的工作是少說話，讓受測者主導；中途打斷或提示很容易改變對方的行為，受測者卡住時，可以用「你現在在找什麼？」這類中性問題引導，而不是告訴他答案。
每個任務建議記下：
- 是否完成，以及完成的方式是否符合預期。
- 在哪個畫面猶豫、點錯或回上一頁。
- 受測者的原話，例如「我以為這個按鈕是下載」。
- 主持人觀察到、但受測者沒說出口的行為。
主持方式也要依情況選擇：
| 方式 | 適合情境 | 限制 |
|---|---|---|
| 面對面 | 要觀察手機實際握持、實體環境的操作 | 要安排場地與交通，受測者較難招募 |
| 主持式遠端 | 受測者分散各地，仍需要即時追問 | 透過螢幕不容易掌握追問時機 |
| 非主持式遠端 | 時程緊、任務單純，受測者自行完成 | 無法針對當下的操作追問細節 |
用戶體驗問卷：SUS 與任務後單題
觀察之外，可以用標準化的用戶體驗問卷補上受測者的主觀感受，方便不同輪次比較：
- 系統易用性量表（SUS）：整場測試結束後填寫，共十題，正向與反向題交替排列，以從「非常同意」到「非常不同意」的五點量表作答。原作者說明分數介於零到一百，但不是百分比；SUS 也不具診斷性，只能看出整體易用程度，看不出問題出在哪裡。
- 任務後單題（SEQ）：每個任務結束後，請受測者用七點量表評估剛才的任務有多困難，可以找出哪個任務相對難。
- 開放式問題：例如「有沒有哪個地方讓你想放棄？」補充量表看不到的原因。
自訂題目時，避免「這個頁面是不是很好用？」這類引導式問句，改用中性的描述；問卷也不要太長，以免受測者後半段隨便作答。
搭配行為數據：熱圖、錄影與漏斗
可用性測試人數少，能解釋原因但無法代表全部訪客；網站行為數據則相反。兩者搭配時，可以這樣分工：
- 用數據挑測試對象：在 Google Analytics 的漏斗探索中，把詢價或購買步驟畫成圖表，找出流失明顯的步驟；開放式漏斗允許從任何步驟進入，封閉式漏斗只計從開頭步驟進入的使用者。
- 用錄影補細節：Microsoft Clarity 提供免費的工作階段錄影與熱圖，可以看到大量真實訪客在流失頁面上點了哪裡、捲到哪裡，安裝與判讀方式可參考Microsoft Clarity 的用法。
- 用測試找原因：把數據指出的頁面寫成任務，請受測者實際操作，聽他說出卡住的理由。
- 改版後回頭看數據：確認修正後同一步驟的流失是否改善。
測試結果怎麼排優先順序
一輪測試常會列出一長串問題，全部修完不實際。Nielsen Norman Group 建議從三個面向評估嚴重程度：問題發生的頻率、發生時對使用者的影響，以及是否會反覆困擾使用者；另外也要考慮對業務的影響，例如問題剛好出現在詢價流程上。
整理步驟：
- 把每場紀錄中的問題彙整成一張表，相同的問題合併並註明出現幾場。
- 依嚴重程度分級，從「不算問題」到「上線前必須修正」。
- 評估修改成本，先處理嚴重度高、修改成本低的項目。
- 每個問題寫下對應的修改方向與負責人。
- 修正後安排下一輪測試，確認問題消失，也沒有產生新問題。
常見問題
UX測試和A/B測試有什麼不同？
可用性測試是觀察少數人操作，找出卡住的原因；A/B 測試是讓真實流量隨機看到不同版本，比較指標高低。常見做法是先用可用性測試找問題、提出改法，再用 A/B 測試驗證效果。
網站還沒上線也能做UX測試嗎？
可以。用線框圖或可點擊原型就能測導覽、分類命名與資訊架構，結構問題越早發現，修改成本越低；視覺稿完成後，可以再測一次文案與按鈕是否清楚。
用戶體驗問卷可以取代可用性測試嗎？
不能取代。問卷反映整體感受，SUS 原作者也說明它不具診斷性，看不出問題出在哪個畫面。要知道哪個步驟卡住，仍需要觀察受測者的實際操作。
受測者需要提供酬勞嗎？
建議提供，例如禮券或服務折抵，讓受測者願意撥出時間並準時出席。但酬勞不要成為參加的主要誘因，仍要用篩選問卷確認對方符合目標客群條件。
測試時受測者一直卡住，主持人可以幫忙嗎？
先不要直接給答案，可以問對方現在在找什麼、預期會看到什麼。若卡太久影響後續任務，再告訴他可以跳過，並把這個卡點記錄為需要優先檢討的問題。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
如果網站流量穩定、詢問卻不如預期，可以先從數據找出流失明顯的步驟，挑兩三個關鍵任務做一輪小型可用性測試。京采的轉換優化與數據追蹤服務可以協助設定漏斗與行為追蹤、規劃測試任務，並把測試結果整理成依嚴重程度排序的修改清單。想討論你的網站，歡迎與我們聯繫。
