# Prototyping

> 建立可互動的產品原型與互動流程說明,用於驗證概念、展示設計、測試流程與收集回饋。當任務涉及高保真原型、畫面 flow、互動設計、轉場、狀態設計或原型測試時使用。

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

---


# 互動原型製作法則

## 任務定義

建立可展示、可測試、可對齊的互動畫面與流程,模擬關鍵狀態、分支與回饋,用來驗證決策。

## 何時使用

- 需要測試複雜的互動流程時
- 向利害關係人展示設計概念時
- 在開發前驗證技術可行性時
- 進行可用性測試時

## 必要輸入

- 產品目標或功能目標
- 主要使用者流程
- 頁面清單或畫面需求
- 互動細節、狀態與邊界情境
- 測試目的或展示目的

## 預期輸出

- 原型範圍定義
- 畫面與狀態清單
- 互動流程與轉場規格
- 原型製作建議與工具選擇
- 測試與迭代建議

## 完成條件

- 已定義原型目的、保真度與涵蓋流程範圍
- 已列出關鍵畫面、狀態、分支與例外情境
- 已建立足以展示或測試的完整互動流程
- 已說明哪些互動是模擬、哪些細節尚未涵蓋
- 已讓利害關係人或測試對象能用原型回答當前決策問題

## 不適用情境

- 只需討論頁面骨架,更適合 wireframing
- 只需定義視覺風格,更適合 ui-visual-design
- 還沒有主要流程與畫面範圍,不應直接做高保真原型

## 常見誤用

- 為了追求精美而做太多畫面,卻沒有聚焦關鍵流程
- 只做正常路徑,忽略錯誤、空狀態與例外流程
- 視覺很完整,但互動邏輯與狀態切換不一致
- 原型目的不清,導致既不適合測試也不適合交付
- 沒有標記假設與限制,讓團隊誤以為所有細節都已定案

## 觸發條件

- 使用者提到「原型」、「prototype」、「flow」、「點擊流程」、「轉場」、「高保真」
- 任務需要把線框圖升級成可測試或可展示的互動版本
- 任務需要整理互動狀態、動畫回饋或操作邏輯

## 高複雜度觸發

- 任務涉及 B2B 後台、管理流程、多步驟設定、審批機制或跨角色協作流程
- 使用者提到需要模擬多種狀態、權限差異、例外流程、批次操作或跨頁操作邏輯
- 問題不只是單一畫面,而是整段工作流程是否順暢、可理解、可展示或可測試
- 團隊需要在開發前先驗證複雜流程、說服利害關係人或對齊多部門理解

## 必要澄清

- 這個原型的主要目的是測試、展示、對齊需求還是交付開發?
- 需要涵蓋哪些關鍵角色、步驟、分支流程與例外狀態?
- 哪些互動細節一定要模擬?例如權限限制、審批退回、錯誤訊息或批次處理
- 原型要做到什麼保真度才足以回答目前的決策問題?
- 利害關係人最想驗證的是流程、內容理解、操作效率還是視覺可信度?
- 原型完成後會如何驗證?會做可用性測試、內部評審還是客戶展示?

## 可搭配技能

- `wireframing`: 先定義頁面骨架與資訊優先順序
- `usability-testing`: 用原型驗證複雜流程是否可理解
- `design-system`: 提升原型一致性並對應後續實作元件
- `information-architecture`: 若流程涉及多模組與深層導航,先整理結構

## 執行步驟

1. 定義原型目的: 測試、展示、對齊需求或交付開發。
2. 定義範圍: 列出關鍵畫面、狀態、分支與例外流程。
3. 選擇保真度: 結構驗證用低保真,流程測試用中保真,展示與交付用高保真。
4. 選擇工具: 一般流程用 Figma, 複雜互動用 Protopie, 程式整合用 Framer。
5. 製作原型: 使用真實內容,補齊載入、錯誤、空狀態與成功回饋。
6. 驗證原型: 檢查所有連結、分支與互動是否可走通,確認原型足以回答決策問題。

## 執行檢查

- [ ] 已定義原型目的與成功標準
- [ ] 已列出畫面、狀態、分支與例外情境
- [ ] 已選定保真度與工具
- [ ] 已用真實內容取代假字
- [ ] 已補齊錯誤、空狀態、載入與成功回饋
- [ ] 已測試主要路徑與返回路徑
- [ ] 已標記原型限制與未定案項目

## 精簡範例輸出

```markdown
# 結帳流程原型規格

- 目的: 驗證結帳流程是否可理解
- 保真度: 中保真
- 工具: Figma

關鍵畫面:
- 購物車
- 配送資訊
- 付款方式
- 訂單確認
- 完成頁

必要狀態:
- 空狀態
- 載入中
- 驗證錯誤
- 付款成功 / 付款失敗

待驗證問題:
- 使用者是否知道下一步
- 表單是否過長
- 付款切換是否清楚
```

## 範例資料庫

本技能提供完整的原型製作範例庫，請參考 `examples.yaml`：

- **保真度層級**：低、中、高保真的特性、工具、使用時機和優缺點
- **互動模式**：導航、回饋、轉場等常見互動模式和動畫參數
- **原型流程**：註冊、結帳、儀表板等完整流程範例
- **動畫指南**：持續時間、緩動曲線、設計原則
- **工具比較**：Figma、Framer、ProtoPie、Axure 的優缺點和適用場景
- **測試檢查清單**：測試前、中、後的完整檢查項目

使用方式：根據測試目標選擇保真度層級，參考互動模式和流程範例快速建立原型。

## 資料使用規則

- 產出內容前，**先閱讀** `TEMPLATE.md`，確認欄位結構、最小必要欄位、品質標準與驗證方式。
- 接著再閱讀 `examples.yaml`，從既有保真度層級、互動模式、流程範例、動畫規則與工具比較中選取最適合的內容。
- 若要新增資料，優先沿用 `TEMPLATE.md` 的格式與命名規則，避免建立重複流程或互動定義不一致的項目。
- 最終輸出必須優先對齊 `TEMPLATE.md` 的格式要求，其次再引用 `examples.yaml` 的內容細節。