candy14432 可用性測試法則
任務定義
用真實任務觀察使用者操作,找出卡點、錯誤、理解落差與效率問題,並轉成可排序的改善項目。
何時使用
- 原型或產品開發的任何階段
- 發布前驗證設計是否符合使用者需求
- 發現可用性問題時
- 比較不同設計方案時
必要輸入
- 測試目標與核心假設
- 目標使用者輪廓
- 原型、網站或產品版本
- 想驗證的任務流程
- 可用的時間、人力與測試方式
預期輸出
- 測試計畫與任務腳本
- 觀察紀錄與問題分類
- 定量與定性分析
- 問題優先順序
- 具體改善建議
完成條件
- 已定義清楚的測試目標、受測對象與任務腳本
- 已記錄任務完成率、卡點、錯誤或關鍵反應
- 已區分問題嚴重程度與影響範圍
- 已從觀察中歸納問題成因,而非只列出表面現象
- 已提出可執行的改善建議,並指出優先處理順序
不適用情境
- 還在探索使用者需求本身,應先做 user-interview
- 只有想收集滿意度分數,不一定需要完整 usability test
- 沒有可測任務或介面,不應直接安排測試
常見誤用
- 把測試做成功能導覽,不是真正觀察使用者自行操作
- 任務敘述過度引導,導致測不到真實可用性問題
- 只記錄使用者說了什麼,沒有記錄實際行為與卡點
- 問題列表很多,卻沒有排序嚴重程度與優先順序
- 測試後只得到抱怨摘要,沒有回到設計決策與修正方向
觸發條件
- 使用者提到「可用性測試」、「usability test」、「使用者測試」、「task flow 驗證」
- 任務需要驗證新流程、原型或頁面是否好用
- 任務需要比較兩個版本哪個更容易使用
高複雜度觸發
- 任務涉及 B2B 平台、後台流程、資料密集操作或多角色協作場景
- 使用者提到 onboarding、審批流程、客服處理、報表分析或跨系統工作流
- 問題包含任務中斷、切換成本高、例外流程多、培訓成本高或不同角色表現差異大
- 團隊需要驗證複雜流程到底是結構問題、內容問題還是權限/狀態設計問題
必要澄清
- 這次測試要驗證哪一段關鍵流程?成功標準是什麼?
- 有哪些角色需要分開測試?他們的任務和權限是否不同?
- 目前最常出錯、最耗時或最容易放棄的是哪個步驟?
- 測試對象是現有產品、原型還是新概念?保真度夠不夠支撐測試?
- 是否需要測試例外情境,例如退件、逾時、缺資料或跨部門交接?
- 測試結果會如何被使用?是排優先序、說服利害關係人還是決定是否上線?
可搭配技能
user-interview: 先了解問題背景或在測試後深挖原因wireframing: 針對發現快速提出低成本改善方案prototyping: 建立更完整的可測試互動流程information-architecture: 若問題來自分類與導航,回頭調整架構
執行步驟
- 定義目標: 寫清要驗證的流程、任務與成功標準。
- 設計任務: 用真實情境描述目標,不要把步驟直接告訴使用者。
- 招募受測者: 每個主要角色至少找 5 位左右,避免內部人員。
- 執行測試: 保持中立,記錄卡點、錯誤、時間、引言與完成率。
- 整理結果: 依嚴重程度排序,提出可執行修正建議。
執行檢查
- 已定義流程、任務與成功標準
- 已設計真實任務而非導覽腳本
- 已招募符合條件的受測者
- 已記錄完成率、時間、錯誤與關鍵引言
- 已排序問題優先順序並提出修正建議
精簡範例輸出
# 可用性測試摘要
- 測試流程: 結帳流程
- 受測者: 5 位
關鍵問題:
- 3/5 找不到優惠券輸入位置
- 2/5 不知道是否還有下一步
優先修正:
- 在購物車顯示優惠券欄位
- 補上步驟指示器
範例資料庫
本技能提供完整的可用性測試範例庫，請參考 examples.yaml：
- 測試情境：電商、SaaS 產品等實際測試任務範例
- 測試方法：主持式、非主持式、A/B 測試的優缺點和適用場景
- 評估指標：任務完成率、完成時間、錯誤率、滿意度等量化與質化指標
- 測試計畫範本：目標、參與者、任務、流程的完整範本
- 嚴重程度分級：問題優先級評估標準
使用方式：根據產品類型選擇測試情境，使用範本快速建立測試計畫。
資料使用規則
- 產出內容前，先閱讀
TEMPLATE.md，確認欄位結構、最小必要欄位、品質標準與驗證方式。 - 接著再閱讀
examples.yaml，從既有測試情境、方法、指標、計畫模板與分級規則中選取最適合的內容。 - 若要新增資料，優先沿用
TEMPLATE.md的格式與命名規則，避免建立重複或標準不一致的測試項目。 - 最終輸出必須優先對齊
TEMPLATE.md的格式要求，其次再引用examples.yaml的內容細節。