先記住：先走使用者旅程，再決定元件和狀態擁有者。
需要深入時：再畫流程圖。

設計稿切得很細，操作卻接不起來

購物車被拆成商品列、優惠框、摘要卡和結帳按鈕，每個元件都很乾淨。
可是登入後優惠代碼不見了，按上一步金額又回到舊版本。

問題不是元件不夠小，而是切元件之前沒有先看使用者如何走過整個流程。
畫面邊界與狀態生命週期，不一定是同一條線。

先把旅程寫成一句一動作

在教學案例中，使用者會：

• 查看商品
• 修改數量
• 套用優惠
• 確認報價
• 登入或確認身分
• 提交訂單
• 查看結果

接著在每一步加上返回與失敗。登入取消後回到哪裡？
改數量會讓哪份資料失效？送出訂單後按返回，能不能再次送出？
這些箭頭會告訴我們：草稿可能要跨過登入流程，但 Loading 只屬於當前請求；訂單結果則不能靠按鈕自己的布林值代表。

從變更原因決定責任

商品列負責顯示項目與發出數量變更意圖，不需要知道優惠服務的網址。
優惠輸入元件處理輸入與錯誤呈現，不應直接改寫整份購物車。

頁面或 Use Case 層協調「商品改變後，報價應失效」這種跨元件規則。
服務層處理與後端的互動。這不是唯一資料夾結構，而是一種清楚的責任方向。

如果兩個小元件總是一起變、只能彼此使用，先放在同一功能模組也很合理。
把每一行 UI 都拆檔案，反而增加理解成本。

用一個失敗案例驗證切法

假設登入取消，需求是保留商品與優惠代碼。
若這些資料都放在已卸載的登入前元件裡，就會消失。
這時要調整的是生命週期擁有者，而不是再多做一個輸入元件。
但也不要因此把所有資料塞進全域 store。

先問：需要存活多久、誰會讀寫、何時清除？
只有路由切換需要保留，可以評估流程層的狀態；跨裝置延續則可能需要伺服器支援。

可以交給 AI 的 Prompt

請先用文字流程整理購物車到結帳的使用者旅程，包含登入取消、修改商品、報價失效與提交結果不明。再根據流程提出元件與狀態責任。每個狀態請標示擁有者、讀取者、存活期間和清除條件。不要先依設計稿方框直接切檔案。

這段把 User Journey 接到 SD 的 ownership。
AI 提出元件清單後，要檢查的是「返回和失敗還能否恢復」。

今日練習與筆記

把一個多步表單畫成文字箭頭，在每一步加一條取消或失敗路徑。
再圈出會跨步驟存活的資料。這些圈起來的地方，往往就是狀態設計真正需要討論的地方。

之後進一步整理狀態機，避免用一大堆互相打架的布林值控制流程。