昨天檢視了三個痛點的改善程度，也預告要改用另一種視角呈現流程。今天沿用同一份流程說明文件與子流程 5，將 User Flow 改畫成 Swimming Lane（泳道圖），觀察以「角色分工」為主軸時，哪些資訊會變得更清楚。

為什麼同一段流程要再畫一次

Day 27 的 User Flow 主要回答「接下來會發生什麼」。節點依流程順序由上而下排列，讀者沿著箭頭即可掌握每一步的後續發展；至於步驟由誰執行，則要透過節點顏色判讀，例如綠色代表系統處理、橘色代表外部系統。

Swimming Lane 關注的是另一個問題：這一步由誰負責。角色構成版面的主要骨架，每個活動都必須歸入特定泳道，因此能直接呈現執行者與跨角色的交接關係。圖中仍保留流程順序，但優先傳達的是分工，而非時間。

今天要驗證的，正是同一份流程說明文件能否支援這種不同視角的圖表。

從五條規劃泳道調整為六條

原先的 30 天大綱只列出五個角色：會員、系統、訂單系統、金流系統與客服後台通知中心。實際繪製時，我另外加入了 MCP Server 泳道。

泳道代表「誰執行活動、誰承擔這段責任」，不以角色的重要程度決定是否呈現。依據目前圖表採用的架構，MCP Server 會接收系統呼叫，將兩項請求分別送往訂單系統與金流系統，再把結果回傳給系統，因此具備獨立泳道的理由：

• 它承擔具體活動。 圖中不只呈現網路傳輸，而是將請求轉送至兩個外部系統。若只是底層 HTTP 連線，才較適合省略為連線而不另設泳道。
• 它是跨系統的交接點。 泳道圖的用途之一，就是呈現責任如何在不同角色之間轉移。若將 MCP Server 隱藏在箭頭標籤中，這段交接關係便不易辨識。
• 它也是 Sequence Diagram 的參與者。 Day 29 與 Day 30 沿用相同角色，讀者較容易比較兩種圖表的差異。

這也說明了圖表轉換時常見的情況：規劃階段通常依業務角色列出清單，泳道圖則會進一步依「是否實際執行活動」重新檢查參與者，因此兩者未必完全相同。

圖表的組成方式

• 採用直式泳道，流程由上而下進行：六條泳道橫向並列，角色名稱置於上方。這項安排延續 Day 22、23 為 User Flow 訂定的閱讀方向，降低切換圖表類型時的理解成本。

• 沿用既有配色：泳道標題使用各角色的代表色，包括會員藍、系統綠、MCP Server 紫，以及外部系統使用的橘色。泳道本體維持白底，避免大面積色塊影響節點辨識；節點與圖例則繼續使用 Day 22 定義的六類配色。

• 以線條區分呼叫與回傳：「建立退貨單請求」與「建立退款申請請求」使用實線；「回傳退貨單建立結果」、「回傳退款申請建立結果」與「回傳結果」使用虛線。這是 User Flow 未採用的區分方式，可讓跨泳道的往返關係更容易辨識。

• 各泳道的節點分布如下：

  • 會員：開始、流程結束，共 2 個
  • 系統：呼叫 MCP Server、接收回傳結果、兩個判斷點、失敗提示、兩則前台訊息與兩項通知推送，共 9 個
  • MCP Server：接收呼叫並轉送請求、彙整結果並回傳，共 2 個
  • 訂單系統：建立退貨單，共 1 個
  • 金流系統：建立退款申請，共 1 個
  • 客服後台通知中心：記錄成功或異常通知，以及各自的流程結束點，共 4 個

• 三個結束點位於流程實際終止的泳道：退貨單建立失敗時，系統提示會員稍後再試或轉接人工客服，結束點位於會員泳道；其餘兩種結果最後皆送往客服後台通知中心，因此結束點位於該泳道。這樣安排可直接呈現各分支最終停留的角色。

• 成功與異常分支分列左右兩側：「退款申請是否建立成功」之後，成功路徑位於系統泳道左側，異常路徑位於右側。兩條路徑分開排列，可避免成功分支的垂直連線與異常通知的橫向箭頭交錯。

圖表揭露的架構假設

流程說明文件提到「系統接收兩系統的回傳結果」，但沒有明確說明結果是否先由 MCP Server 彙整。User Flow 可以讓兩條回傳線直接匯入系統節點，不必決定中間由誰處理；泳道圖則必須為每項活動指定執行者。

因此，目前圖中將這段流程拆成「MCP Server 彙整兩系統結果」與「回傳給系統」兩個步驟。這是為了完成圖表而加入的架構假設，不是流程說明文件已明確定義的內容。若實際設計是由系統分別呼叫兩個 MCP 工具並各自接收結果，相關泳道與連線都需要調整。

換句話說，改用不同圖表，不只是重新排列同一批節點，也可能揭露原始文件尚未說明的細節。這些差異應標示為待確認事項，再由實際架構補充，而不宜直接當成既定需求。

明天是系列最後一天，我會繼續使用子流程 5 與相同的六個角色，改以 Sequence Diagram 呈現呼叫順序，並與子流程 3 較單純的系統呼叫進行比較。