candy14432 互動原型製作法則
任務定義
建立可展示、可測試、可對齊的互動畫面與流程,模擬關鍵狀態、分支與回饋,用來驗證決策。
何時使用
- 需要測試複雜的互動流程時
- 向利害關係人展示設計概念時
- 在開發前驗證技術可行性時
- 進行可用性測試時
必要輸入
- 產品目標或功能目標
- 主要使用者流程
- 頁面清單或畫面需求
- 互動細節、狀態與邊界情境
- 測試目的或展示目的
預期輸出
- 原型範圍定義
- 畫面與狀態清單
- 互動流程與轉場規格
- 原型製作建議與工具選擇
- 測試與迭代建議
完成條件
- 已定義原型目的、保真度與涵蓋流程範圍
- 已列出關鍵畫面、狀態、分支與例外情境
- 已建立足以展示或測試的完整互動流程
- 已說明哪些互動是模擬、哪些細節尚未涵蓋
- 已讓利害關係人或測試對象能用原型回答當前決策問題
不適用情境
- 只需討論頁面骨架,更適合 wireframing
- 只需定義視覺風格,更適合 ui-visual-design
- 還沒有主要流程與畫面範圍,不應直接做高保真原型
常見誤用
- 為了追求精美而做太多畫面,卻沒有聚焦關鍵流程
- 只做正常路徑,忽略錯誤、空狀態與例外流程
- 視覺很完整,但互動邏輯與狀態切換不一致
- 原型目的不清,導致既不適合測試也不適合交付
- 沒有標記假設與限制,讓團隊誤以為所有細節都已定案
觸發條件
- 使用者提到「原型」、「prototype」、「flow」、「點擊流程」、「轉場」、「高保真」
- 任務需要把線框圖升級成可測試或可展示的互動版本
- 任務需要整理互動狀態、動畫回饋或操作邏輯
高複雜度觸發
- 任務涉及 B2B 後台、管理流程、多步驟設定、審批機制或跨角色協作流程
- 使用者提到需要模擬多種狀態、權限差異、例外流程、批次操作或跨頁操作邏輯
- 問題不只是單一畫面,而是整段工作流程是否順暢、可理解、可展示或可測試
- 團隊需要在開發前先驗證複雜流程、說服利害關係人或對齊多部門理解
必要澄清
- 這個原型的主要目的是測試、展示、對齊需求還是交付開發?
- 需要涵蓋哪些關鍵角色、步驟、分支流程與例外狀態?
- 哪些互動細節一定要模擬?例如權限限制、審批退回、錯誤訊息或批次處理
- 原型要做到什麼保真度才足以回答目前的決策問題?
- 利害關係人最想驗證的是流程、內容理解、操作效率還是視覺可信度?
- 原型完成後會如何驗證?會做可用性測試、內部評審還是客戶展示?
可搭配技能
wireframing: 先定義頁面骨架與資訊優先順序usability-testing: 用原型驗證複雜流程是否可理解design-system: 提升原型一致性並對應後續實作元件information-architecture: 若流程涉及多模組與深層導航,先整理結構
執行步驟
- 定義原型目的: 測試、展示、對齊需求或交付開發。
- 定義範圍: 列出關鍵畫面、狀態、分支與例外流程。
- 選擇保真度: 結構驗證用低保真,流程測試用中保真,展示與交付用高保真。
- 選擇工具: 一般流程用 Figma, 複雜互動用 Protopie, 程式整合用 Framer。
- 製作原型: 使用真實內容,補齊載入、錯誤、空狀態與成功回饋。
- 驗證原型: 檢查所有連結、分支與互動是否可走通,確認原型足以回答決策問題。
執行檢查
- 已定義原型目的與成功標準
- 已列出畫面、狀態、分支與例外情境
- 已選定保真度與工具
- 已用真實內容取代假字
- 已補齊錯誤、空狀態、載入與成功回饋
- 已測試主要路徑與返回路徑
- 已標記原型限制與未定案項目
精簡範例輸出
# 結帳流程原型規格
- 目的: 驗證結帳流程是否可理解
- 保真度: 中保真
- 工具: Figma
關鍵畫面:
- 購物車
- 配送資訊
- 付款方式
- 訂單確認
- 完成頁
必要狀態:
- 空狀態
- 載入中
- 驗證錯誤
- 付款成功 / 付款失敗
待驗證問題:
- 使用者是否知道下一步
- 表單是否過長
- 付款切換是否清楚
範例資料庫
本技能提供完整的原型製作範例庫，請參考 examples.yaml：
- 保真度層級：低、中、高保真的特性、工具、使用時機和優缺點
- 互動模式：導航、回饋、轉場等常見互動模式和動畫參數
- 原型流程：註冊、結帳、儀表板等完整流程範例
- 動畫指南：持續時間、緩動曲線、設計原則
- 工具比較：Figma、Framer、ProtoPie、Axure 的優缺點和適用場景
- 測試檢查清單：測試前、中、後的完整檢查項目
使用方式：根據測試目標選擇保真度層級，參考互動模式和流程範例快速建立原型。
資料使用規則
- 產出內容前，先閱讀
TEMPLATE.md，確認欄位結構、最小必要欄位、品質標準與驗證方式。 - 接著再閱讀
examples.yaml，從既有保真度層級、互動模式、流程範例、動畫規則與工具比較中選取最適合的內容。 - 若要新增資料，優先沿用
TEMPLATE.md的格式與命名規則，避免建立重複流程或互動定義不一致的項目。 - 最終輸出必須優先對齊
TEMPLATE.md的格式要求，其次再引用examples.yaml的內容細節。