四欄定義

顯示

使用者看到的畫面元素。進度指示器、錯誤訊息、表單欄位、資料列表 — 任何視覺上呈現的內容。

可用操作

使用者在這個狀態下能執行的動作。按鈕、手勢、鍵盤輸入、下拉選單選擇。重點是「能做什麼」，不是「看到什麼」。

「顯示」和「可用操作」的區別在於互動性。顯示一段錯誤訊息和顯示一個重試按鈕都是「顯示」；按下重試按鈕觸發重新連線是「可用操作」。

進入條件

什麼事件或動作讓畫面進入這個狀態。使用者操作（點擊按鈕）、系統事件（連線成功）、外部事件（推播通知）。

退出路徑

使用者如何離開這個狀態。返回上一頁、導航到另一個畫面、取消當前操作、完成流程後自動轉場。

退出路徑是這張表格中最容易遺漏的欄位。開發者設計畫面時，注意力集中在「進來後看到什麼、能做什麼」，容易忽略「怎麼離開」。

填寫步驟

第一步：列出畫面的所有狀態

從程式碼中的狀態管理機制取得狀態清單。Flutter 的 enum、React 的 state、Vue 的 reactive data — 任何控制畫面呈現的狀態變數。

如果沒有明確的狀態 enum，從畫面的視覺變化反推：loading 時長什麼樣、成功時長什麼樣、失敗時長什麼樣。每種不同的視覺呈現就是一個狀態。

第二步：每個狀態填四欄

逐一填寫每個狀態的顯示、可用操作、進入條件、退出路徑。填不出來的欄位先留空，留空本身就是發現。

第三步：檢查退出路徑欄

退出路徑為空的狀態是 UX 死胡同。使用者進入後無法靠自己的操作離開，只能殺掉 app 或等系統逾時。

app_tunnel 的 Terminal 畫面有五個 enum 狀態（idle / connecting / connected / error / disconnected），每個狀態的退出路徑都是空的。使用者從首頁點 Connect Terminal 進入後，無論處於哪個狀態都無法返回首頁（U.C1）。10 分鐘填完這張表格就能發現全部五個缺口（本章合成，UF-3 Derive）。

第四步：檢查操作欄

操作欄為空的狀態可能合理（loading 時使用者等待），也可能代表缺少互動設計。loading 狀態通常應該有「取消」操作，error 狀態通常應該有「重試」和「返回」。

填寫範例

以 app_tunnel Terminal 畫面為例，修復前的矩陣如下：

退出路徑欄全空 — 五個 UX 死胡同。修復後的矩陣應該每個狀態都有至少一條退出路徑：

每個狀態至少一條退出路徑

退出路徑是預設要求。即使是 connecting 這種過渡狀態，使用者也應該能取消 — 連線卡住時使用者需要能離開。iOS HIG 和 Material Design 對 modal 畫面都要求 dismiss 機制；畫面狀態矩陣的退出路徑欄是這個要求的具體檢查方式。

退出路徑為空只在一種情況下合理：該狀態持續時間極短（< 1 秒）且有保證的自動轉場。即使如此，仍建議保留取消操作 — 因為「極短」是在正常情況下的預期，異常情況（網路中斷、服務當機）可能讓這個狀態停留很久。

下一步路由

• 從 BDD 操作盤點展開到狀態矩陣 → 從 BDD 操作盤點展開到狀態矩陣
• 路由可達性檢查 → 路由可達性檢查
• 狀態矩陣轉 widget test case → testing 模組四 UI 自動化
• 狀態矩陣加「可觀測性」欄位 → testing 模組二 客戶端可觀測性
• 狀態轉換事件作為 funnel 分析原料 → monitoring 模組八 行為資料的商業利用

操作盤點的覆蓋範圍

BDD 操作盤點通常包含：

• 使用者操作（When）：「使用者點擊連線按鈕」
• 前端引導（Then）：「顯示連線進度指示」
• 後端回應：「WebSocket 連線建立」

「前端引導」描述的是畫面的顯示內容 — 對應狀態矩陣的「顯示」欄。但操作盤點通常不會展開：連線中的畫面除了顯示進度指示，使用者能做什麼？如果連線失敗，使用者怎麼離開失敗畫面？

app_tunnel 的操作盤點在「前端引導」欄寫了「連線失敗顯示無法連線」，覆蓋了 error 狀態的顯示。但是「顯示無法連線之後使用者能做什麼」和「使用者怎麼離開這個畫面」都沒有描述。實作出來的 error 狀態有重連按鈕但沒有 back 按鈕 — 重連失敗時使用者被困在 error → retry → error 循環裡（U.C1）。

展開步驟

步驟一：從操作盤點抽出所有畫面

每個 BDD 情境至少涉及一個畫面。列出所有情境提到的畫面名稱，去重後得到畫面清單。

例：app_tunnel 的操作盤點涉及三個畫面 — 首頁、配對畫面、終端機畫面。

步驟二：每個畫面列出狀態

從操作盤點的 Given / When / Then 條件中抽出狀態。「Given 連線已建立」暗示有 connected 狀態；「Then 顯示無法連線」暗示有 error 狀態。

同時檢查程式碼中的狀態 enum — 操作盤點可能遺漏了某些狀態（如 idle、disconnected），程式碼裡有但操作盤點沒提到的狀態同樣需要設計 UI。

步驟三：每個狀態填「顯示」欄

從操作盤點的「前端引導」直接填入。這一步通常不缺資料，因為操作盤點的強項就是描述顯示內容。

步驟四：每個狀態填「可用操作」和「退出路徑」欄

這一步是關鍵 — 操作盤點通常不提供這些資訊，需要主動補上。

對每個狀態問兩個問題：

• 使用者在這個狀態下想做什麼？（可用操作）
• 使用者怎麼離開這個狀態？（退出路徑）

開發者容易假設 connected 狀態下使用者只想打字，不會想返回首頁。但使用者可能想切換到配對畫面重新配對、想暫時離開做其他事、想結束當前操作。把這些可能性列出來，判斷哪些需要提供操作按鈕。

步驟五：檢查矩陣的空白格

退出路徑欄為空的狀態是 UX 死胡同，需要補上退出路徑。可用操作欄為空的狀態需要判斷是否合理 — loading 狀態操作欄為空可能合理，但建議至少提供取消操作。

操作盤點的「描述顯示」偏差

操作盤點的「前端引導」傾向描述顯示（What the user sees）而非描述互動（What the user can do）。這個偏差的根源在 BDD 的 Then 語法 — Then 通常描述可觀察的結果，而「畫面顯示 X」比「使用者可以做 Y」更容易寫成可觀察的斷言。

app_tunnel 的操作盤點就是這個模式。四個操作情境的「前端引導」都寫了顯示內容（「顯示終端機畫面」「顯示連線中」「顯示無法連線」），沒有一個寫了操作（「使用者可以取消」「使用者可以返回」）或退出路徑（「使用者可以回到首頁」）（U.C1）。

畫面狀態矩陣的四欄結構強制補上這兩個面向。從 BDD 操作盤點到畫面狀態矩陣的展開步驟，就是把「只描述顯示」擴展成「顯示 + 操作 + 退出」的過程。

下一步路由

• 畫面狀態矩陣的完整定義 → 畫面狀態矩陣的定義與填寫方法
• 路由可達性檢查 → 路由可達性檢查
• 想知道什麼是「假設只走 happy path」的反模式 → 反模式：假設使用者只走 happy path