# Usability Testing

> 規劃、執行與整理可用性測試,用於發現操作障礙、驗證流程與優先排序改善項目。當任務涉及使用者測試、task flow 驗證、原型評估、可用性問題盤點或設計方案比較時使用。

- Skill: `candy14432/usability-testing` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add candy14432/usability-testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/candy14432/usability-testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: MIT
- Author: candy14432 (https://skillmd.com/u/candy14432)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/candy14432/usability-testing

---


# 可用性測試法則

## 任務定義

用真實任務觀察使用者操作,找出卡點、錯誤、理解落差與效率問題,並轉成可排序的改善項目。

## 何時使用

- 原型或產品開發的任何階段
- 發布前驗證設計是否符合使用者需求
- 發現可用性問題時
- 比較不同設計方案時

## 必要輸入

- 測試目標與核心假設
- 目標使用者輪廓
- 原型、網站或產品版本
- 想驗證的任務流程
- 可用的時間、人力與測試方式

## 預期輸出

- 測試計畫與任務腳本
- 觀察紀錄與問題分類
- 定量與定性分析
- 問題優先順序
- 具體改善建議

## 完成條件

- 已定義清楚的測試目標、受測對象與任務腳本
- 已記錄任務完成率、卡點、錯誤或關鍵反應
- 已區分問題嚴重程度與影響範圍
- 已從觀察中歸納問題成因,而非只列出表面現象
- 已提出可執行的改善建議,並指出優先處理順序

## 不適用情境

- 還在探索使用者需求本身,應先做 user-interview
- 只有想收集滿意度分數,不一定需要完整 usability test
- 沒有可測任務或介面,不應直接安排測試

## 常見誤用

- 把測試做成功能導覽,不是真正觀察使用者自行操作
- 任務敘述過度引導,導致測不到真實可用性問題
- 只記錄使用者說了什麼,沒有記錄實際行為與卡點
- 問題列表很多,卻沒有排序嚴重程度與優先順序
- 測試後只得到抱怨摘要,沒有回到設計決策與修正方向

## 觸發條件

- 使用者提到「可用性測試」、「usability test」、「使用者測試」、「task flow 驗證」
- 任務需要驗證新流程、原型或頁面是否好用
- 任務需要比較兩個版本哪個更容易使用

## 高複雜度觸發

- 任務涉及 B2B 平台、後台流程、資料密集操作或多角色協作場景
- 使用者提到 onboarding、審批流程、客服處理、報表分析或跨系統工作流
- 問題包含任務中斷、切換成本高、例外流程多、培訓成本高或不同角色表現差異大
- 團隊需要驗證複雜流程到底是結構問題、內容問題還是權限/狀態設計問題

## 必要澄清

- 這次測試要驗證哪一段關鍵流程?成功標準是什麼?
- 有哪些角色需要分開測試?他們的任務和權限是否不同?
- 目前最常出錯、最耗時或最容易放棄的是哪個步驟?
- 測試對象是現有產品、原型還是新概念?保真度夠不夠支撐測試?
- 是否需要測試例外情境,例如退件、逾時、缺資料或跨部門交接?
- 測試結果會如何被使用?是排優先序、說服利害關係人還是決定是否上線?

## 可搭配技能

- `user-interview`: 先了解問題背景或在測試後深挖原因
- `wireframing`: 針對發現快速提出低成本改善方案
- `prototyping`: 建立更完整的可測試互動流程
- `information-architecture`: 若問題來自分類與導航,回頭調整架構

## 執行步驟

1. 定義目標: 寫清要驗證的流程、任務與成功標準。
2. 設計任務: 用真實情境描述目標,不要把步驟直接告訴使用者。
3. 招募受測者: 每個主要角色至少找 5 位左右,避免內部人員。
4. 執行測試: 保持中立,記錄卡點、錯誤、時間、引言與完成率。
5. 整理結果: 依嚴重程度排序,提出可執行修正建議。

## 執行檢查

- [ ] 已定義流程、任務與成功標準
- [ ] 已設計真實任務而非導覽腳本
- [ ] 已招募符合條件的受測者
- [ ] 已記錄完成率、時間、錯誤與關鍵引言
- [ ] 已排序問題優先順序並提出修正建議

## 精簡範例輸出

```markdown
# 可用性測試摘要

- 測試流程: 結帳流程
- 受測者: 5 位

關鍵問題:
- 3/5 找不到優惠券輸入位置
- 2/5 不知道是否還有下一步

優先修正:
- 在購物車顯示優惠券欄位
- 補上步驟指示器
```

## 範例資料庫

本技能提供完整的可用性測試範例庫，請參考 `examples.yaml`：

- **測試情境**：電商、SaaS 產品等實際測試任務範例
- **測試方法**：主持式、非主持式、A/B 測試的優缺點和適用場景
- **評估指標**：任務完成率、完成時間、錯誤率、滿意度等量化與質化指標
- **測試計畫範本**：目標、參與者、任務、流程的完整範本
- **嚴重程度分級**：問題優先級評估標準

使用方式：根據產品類型選擇測試情境，使用範本快速建立測試計畫。

## 資料使用規則

- 產出內容前，**先閱讀** `TEMPLATE.md`，確認欄位結構、最小必要欄位、品質標準與驗證方式。
- 接著再閱讀 `examples.yaml`，從既有測試情境、方法、指標、計畫模板與分級規則中選取最適合的內容。
- 若要新增資料，優先沿用 `TEMPLATE.md` 的格式與命名規則，避免建立重複或標準不一致的測試項目。
- 最終輸出必須優先對齊 `TEMPLATE.md` 的格式要求，其次再引用 `examples.yaml` 的內容細節。