頁面流程是使用者在系統裡從起點走到終點的真實動線。就像遊樂園地圖，每個路口都要有路標，人才知道往哪走。
① 狀態移轉圖（State Transition Diagram）：像捷運路線圖。精確定義：畫出系統在「載入中、有資料、空資料、出錯」之間怎麼跳轉。
② 操作路徑卡（Operation Path Card）：像步道路標。精確定義：寫清楚「人在哪、做了什麼、系統回什麼、下一步去哪」，並標上 PRD 編號。
③ 頁面責任卡（Page Responsibility Card）：像服務台告示牌。精確定義：講清楚這個畫面只負責解決哪件事。
先求動線通順，再求視覺美觀。
① 純文字條列：簡單有效。寫得快，適合前期對邏輯。
② 狀態卡加 Mermaid 圖：高效實用。工程和設計看圖對齊最快。
① 抓出頭尾與條件：確定誰在用、從哪進來、要完成什麼。
② 補齊所有分支：正常流程、沒資料引導、連線失敗重試全部列出。
③ 每一步都要有退路：能前進也能返回，絕不把人卡死在頁面上。
④ 標註規格來源：每步對齊 PRD 的功能需求 ID，沒寫到的就是待辦決策。
依據 FlowBoard 案例，我們梳理出四條核心操作路徑卡片：
① 操作路徑 P1（主要順利路徑）
② 操作路徑 P2（空資料引導路徑）
③ 操作路徑 P3（異常復原路徑）
④ 操作路徑 P4（檢視後返回路徑）
狀態圖呈現動態移轉關係：
![US-01 頁面流程示意：載入狀態分流至有任務、空資料或異常狀態，並標出操作去向]
四張頁面責任卡片清楚劃分每個畫面的職責邊界：
① 首頁提示卡片
② 任務詳情卡片
③ 待分派任務狀態卡片
④ 載入異常狀態卡片
角色：你是一位專業的互動流程設計助手，專注將產品規格轉換為完整的操作路徑。
輸入資料：
【貼上 PRD、功能需求 ID、使用者故事、驗收標準與 Demo 範圍】
執行步驟：
① 確立角色與目標：明確定義操作角色、觸發起點、前置條件與成功終點。
② 規劃完整路徑：依序建立主要順行路徑、空資料引導路徑、異常處理路徑與返回路徑。
③ 標記規格來源 ID：為每一步驟標註對應的需求編號；若屬原型新增決策則標註【待補規格】。
④ 檢視動線完整性：確保每個介面皆具備前進與後退出口，每個異常狀態皆具備復原機制。
輸出格式：
操作路徑卡片／狀態移轉圖（Mermaid 格式）／頁面責任清單／待補充決策清單
透過結構化流程轉換，團隊能將文字條文轉變為具備因果關係的動態路徑。這項做法的核心價值在於及早發現路徑中缺乏去向的按鈕與孤立狀態，讓整個操作體驗連貫順暢。
① 使用者是否能清楚理解自己目前所處的介面位置？
② 主要行動按鈕是否能有效推進使用者的核心目標？
③ 載入重試是否可能引發重複發送事件？
④ 各畫面名詞與按鈕文案是否在整份規格中維持高度一致？
建立檔案路徑：
.claude/skills/user-flow/SKILL.md
設定 YAML 內容：
---
name: user-flow
description: 將 PRD 與 Demo 規格轉換為頁面狀態與操作路徑，確保每個動作具備明確去向。
---
請輸出頁面 ID、進入條件、可見內容、使用者動作、下一狀態與離開方式。
標註缺乏去向的按鈕、缺少異常狀態的動線與待拍板的權限邏輯。
專注於既有規格內容，保持操作路徑客觀真實。
在 Claude Code 中執行指令：
/user-flow 請讀取 PRD 和 Demo 規格，輸出 US-01 的頁面流程與未決問題。
執行 Skill 後，Claude Code 會產出狀態轉移清單，並標註需要補齊去向的操作環節，成為團隊最實用的動線檢查器。
今天完成一份附帶需求來源 ID 的操作路徑卡片、狀態移轉圖與頁面責任卡。當每條路徑都具備明確出口與復原動線，使用者就能在產品中自在穿梭。
我會再讓這個 Skill 輸出一張「狀態 × 動作」表：每格是允許、禁止，或 PRD 沒定義。只畫存在的箭頭，容易漏掉「載入中又按一次重試」「權限已撤銷卻返回詳情」這類組合。未定義的格子先進待決策清單，不讓模型補成合理的流程；已定義的格子再轉成測試案例。這樣圖的完整性才有可檢查的標準，而不只是看起來每個畫面都有出口。
iThome鐵人賽
看影片追技術