test

name	test
description	規劃與執行可用性測試，蒐集行為與回饋，整理優先修正清單（可含 a11y 驗證）。
license	MIT
metadata	{"author":"goodux","version":"1.0.0","category":"design-thinking","language":"zh-TW"}

Test｜可用性驗證

任務定義

透過任務操作觀察使用者行為，量化/質化回饋並排序問題，為迭代提供明確修正方向。當你需要「驗證設計是否好用」、「發現可用性問題」、「收集使用者回饋」時，就應該使用此技能進行可用性測試與問題發現。

何時使用

• 原型或產品釋出前需要驗證體驗
• 比對多個方案或追蹤迭代成效
• 需要同時檢視可用性與可及性風險
• 需要發現使用者操作問題並排序修正優先順序

必要輸入

• Prototype 連結與限制說明
• 測試任務、成功標準與評估指標
• 目標使用者招募條件，錄影/紀錄方式

預期輸出

• 測試腳本、任務與成功標準
• 問題清單（含嚴重度與影響範圍）
• 建議修正與後續迭代優先順序

完成條件

• 至少 5-8 位目標使用者的觀察資料
• 問題依嚴重度排序並對應到任務/指標
• 形成明確的修正建議與後續計畫

不適用情境

• 仍在發散解法、未有可測試產物（建議回到 Ideate 或 Prototype）
• 測試目標/任務尚未定義（建議回到 Define）

觸發條件

完整關鍵字庫請參考：KEYWORDS_LIBRARY.md > Test 章節

核心關鍵字（高優先級）

• 主要動詞：測試、驗證、檢驗、評估、評測、檢查、發現問題、找出問題、收集回饋、蒐集意見
• 名詞：可用性測試、使用者測試、測試、驗證、評估、任務測試、情境測試、出聲思考、think aloud、完成率、錯誤率、任務時間、問題清單、改善建議、A/B 測試、對比測試、無障礙測試、a11y 驗證、螢幕閱讀器、鍵盤流程
• 情境描述：好不好用、使用者能不能完成、有什麼問題、如何改善、是否符合 WCAG

前置條件

• 需要已有原型或產品可供測試（來自 Prototype）

排除條件（優先考慮其他技能）

• 若同時提到「還沒有原型」→ 轉 Prototype
• 若同時提到「還沒設計」→ 轉 Ideate
• 若同時提到「還沒定義測試目標」→ 轉 Define
• 若同時提到「為什麼使用者不用這功能」（探索性）→ 轉 Empathize

必要澄清

專案狀態檢查

在開始測試前，請先確認：

• 是否已有可測試的原型或產品（Prototype）？
• 是否已定義測試目標與成功標準（Define）？
• 如果沒有，建議先補足前置工作

測試規劃

• 測試裝置/平台與網路限制？
• 是否需要 a11y 驗證（對比度、鍵盤、朗讀、替代文字）？
• 成功標準與量測方式為何？
• 是否允許遠端測試？

測試後的下一步

1. UX 迭代評估（推薦）

測試完成後，建議進行完整的 UX 評估：

評估項目：

• ✅ 可用性（任務完成率、錯誤率、完成時間）
• ✅ 可訪問性（WCAG 符合度、鍵盤操作、螢幕閱讀器）
• ✅ 視覺設計（一致性、視覺層級、品牌符合度）
• ✅ 效能（載入速度、互動回應、使用者感知）
• ✅ 內容品質（文案清晰度、資訊架構、微互動）

完整評估指引：參考 references/UX_ITERATION_GUIDE.md

2. 問題嚴重度分級

根據測試結果，將問題分級：

• P0 - 阻斷性問題：使用者無法完成主要任務 → 立即修復
• P1 - 嚴重問題：嚴重影響使用體驗 → 本週期內修復
• P2 - 中度問題：造成不便但可完成任務 → 下週期修復
• P3 - 輕微問題：優化項目 → 排入待辦清單

3. 迭代決策

根據問題嚴重度決定迭代方式：

如果使用者不滿意測試結果，可以選擇：

回到 /empathize：

• 發現使用者需求理解有誤
• 需要重新研究使用者行為
• 痛點分析不夠深入

回到 /define：

• 問題定義不夠明確
• 成功指標需要調整
• MVP 範圍需要重新界定

回到 /ideate：

• 設計方向需要調整
• 資訊架構不合理
• 視覺層級混亂
• 需要探索其他設計方案

回到 /prototype：

• 互動流程需要調整
• 操作步驟過多
• 狀態不明確
• 原型需要重新製作

局部修正（小問題）：

• 文案調整
• 樣式微調
• 錯誤訊息優化

技術優化（效能問題）：

• 載入速度改善
• 互動延遲優化
• 效能問題修復

重要提醒：

• 允許在任何階段重新開始，確保專案達到最佳品質
• 根據問題根源選擇正確的回溯階段
• P0/P1 問題建議回到對應階段重新設計

4. 程式碼專案的特別評估

如果使用程式碼原型（React + Shadcn/UI 等）：

技術可行性驗證：

• 技術架構是否合理？
• 效能是否符合預期？
• 是否有技術債需要處理？

開發體驗評估：

• 元件是否易於維護？
• 程式碼結構是否清晰？
• 是否需要重構？

準備進入開發：

• 原型是否可直接作為開發基礎？
• 需要哪些調整才能進入生產？
• 是否需要建立設計系統？

可搭配技能

• Prototype：作為測試素材
• Ideate：根據問題回到發想階段調整

參考資料 (References)

本技能整合以下詳細方法，當需要更深入的執行指引時請參考：

可用性測試相關

• references/usability-testing/SKILL.md
  測試腳本撰寫、任務設計、問題分級、量化指標與報告產出。
  適用時機：規劃測試、設計任務、執行測試、分析結果、撰寫報告。
  關鍵場景：「如何寫測試腳本」、「如何設計測試任務」、「如何分級問題嚴重度」、「如何量測完成率」、「如何寫測試報告」。

無障礙測試相關

• references/accessibility-design/SKILL.md
  a11y 測試清單、螢幕閱讀器驗證、WCAG 檢查與無障礙問題分級。
  適用時機：執行無障礙測試、驗證 WCAG、測試螢幕閱讀器、檢查鍵盤操作。
  關鍵場景：「如何測試無障礙功能」、「如何用螢幕閱讀器測試」、「如何檢查 WCAG 符合度」、「如何測試鍵盤操作」。

進階參考

• references/SKILL_USAGE_GUIDE.md - Skill 使用規則、專案檢測與測試後迭代

執行步驟

1. 定義目標：設定任務、成功標準、評估指標。
2. 招募與安排：找 5-8 位目標使用者，安排錄影/紀錄。
3. 執行測試：出聲思考、觀察行為/卡點，標記嚴重度。
4. 整理輸出：問題清單、影響層級、建議修正與後續計畫。

執行檢查

• 測試任務與成功標準已確認
• 招募到足夠且匹配的使用者
• 問題已依嚴重度排序並對應任務/指標
• a11y 檢查（若需要）已執行並紀錄

精簡範例輸出

# Test 摘要
- 參與者：5 人，桌機 3 / 行動 2
- 問題：物流選單位置不明顯（高）、表單錯誤提示不被朗讀（高, a11y）、優惠碼錯誤訊息不清晰（中）
- 建議：提升物流選單可見度、修正 aria-describedby 朗讀、將錯誤訊息放在欄位旁且顏色/文字並用