四欄定義

顯示

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

可用操作

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

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

進入條件

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

退出路徑

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

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

填寫步驟

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

從程式碼中的狀態管理機制取得狀態清單。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

定義 vs 可達

Router 定義的路由

現代前端框架（Flutter GoRouter、React Router、Vue Router）通常有一個集中的路由定義檔，列出所有可存取的路徑和對應的畫面元件。這個列表是 router 認知的「所有畫面」。

UI 可達的路由

從首頁（或 app 的入口畫面）開始，透過 UI 上的按鈕、連結、手勢能到達的所有路由。這個集合代表使用者實際能存取的畫面。

差集分析

router 有但 UI 不可達：路由定義了、畫面元件也實作了，但沒有任何 UI 元素導航到這個路由。功能存在但使用者找不到入口。

UI 指向但 router 沒有：UI 上有一個按鈕 navigateTo('/settings')，但 router 沒有定義 /settings 路由。使用者點擊後會看到 404 或空白畫面。

路由存在但不可達的案例

app_tunnel 的 router 定義了三條路由：/（首頁）、/enrollment（配對）、/terminal（終端機）。首頁只有一個 Connect Terminal 按鈕導航到 /terminal。/enrollment 路由存在，EnrollmentScreen 完整實作，但首頁沒有任何 UI 元素導航到這個路由（U.C4）。

從使用者視角看，配對功能不存在。從開發者視角看，配對功能完整 — 路由定義了、畫面寫好了、業務邏輯都通了。問題出在「入口」這個連接層。

這和程式碼裡寫了一個 function 但沒有任何地方呼叫它的情況結構相同。Function 本身可能正確無誤，但從系統角度看是死程式碼。路由可達性檢查是這個問題在 UX 層的對應。

檢查方法

手動檢查

列出 router 定義的所有路由，然後逐一在 UI 上找到通往該路由的操作路徑。找不到路徑的就是不可達路由。

手動檢查的成本隨畫面數量線性增長。5 個路由的 app 很快能查完；50 個路由的 app 需要系統化方法。

從操作盤點交叉比對

BDD 操作盤點列出了所有使用者操作（UC）。每個 UC 對應至少一個畫面。把 UC 清單和 router 定義對照：

• 每個 UC 的主要入口畫面是否有從首頁可達的路徑？
• 每個 UC 涉及的中間畫面是否都有進入和退出路徑？

app_tunnel 的操作盤點列了四個操作（配對、連線、輪替、啟停），首頁只提供了「連線」的入口。「配對」是 app 操作，應該有入口但沒有。「輪替」和「啟停」是主機端操作，不需要 app 入口。這個交叉比對能在 5 分鐘內揭露入口缺失。

自動化檢查

從 router 定義檔解析所有路由路徑，再從 UI 元件的程式碼中搜尋所有 navigateTo、context.go、context.push、router.push 等導航呼叫的目標路徑。兩個集合取差集。

自動化檢查能發現靜態定義的入口缺失，但無法發現動態導航（根據執行期條件決定目標路由）的可達性問題。

go vs push 的語意影響

路由可達性確認之後，導航方式的選擇影響使用者的返回路徑。

push 把新畫面推入導航堆疊，使用者按 back 能回到前一個畫面。go 替換整個導航堆疊，使用者按 back 不會回到原來的畫面。

選擇 go 還是 push 取決於使用者的心理模型：這個導航是「暫時離開主畫面去做一件事，做完回來」（push），還是「切換到另一個主要工作區」（go）。

app_tunnel 修復時選擇 context.push('/enrollment') 讓使用者配對完成後按 back 回首頁 — 配對是「暫時去做一件事」，不是切換工作區（U.C4）。

下一步路由

• 畫面狀態矩陣完整定義 → 畫面狀態矩陣的定義與填寫方法
• 想測試導航路徑的正確性 → testing 模組四 UI 自動化
• 想設計完整導航模式 → ux-design 模組五 導航模式

隱性假設如何產生

開發者設計 connected 狀態時，注意力在「終端機介面的功能」— 打字、特殊鍵、滾動。「使用者可能想離開 connected 狀態回到首頁」這個需求在 happy path 中不存在 — 如果一切順利，使用者為什麼要離開？

這個推論在使用者行為和開發者假設吻合時成立。但使用者可能想：

• 切換到配對畫面重新配對另一台裝置
• 暫時離開終端機處理其他事
• 遇到回應異常想從頭重新連線
• 覺得功能不符需求想回到首頁看其他選項

app_tunnel 的 Terminal 畫面五個狀態都沒有退出路徑。connected 狀態有打字和特殊鍵操作，但沒有「離開」操作；error 和 disconnected 有重連按鈕，但沒有「放棄重連、回首頁」的選項。開發者設計 error 狀態時的隱性假設是「使用者遇到錯誤會想重試」— 沒考慮「使用者可能想放棄」（U.C1）。

Happy path 偏差的擴散

Happy path 偏差不只發生在單一畫面。首頁只放 Connect Terminal 按鈕、沒放配對入口，是首頁層級的 happy path 偏差 — 假設使用者已經完成配對、只需要連線（U.C4）。

操作盤點的「前端引導」只描述顯示不描述操作和退出，是設計流程層級的 happy path 偏差 — 關注「順利時使用者看到什麼」，忽略「不順利時使用者能做什麼」。

從企劃到設計到實作，每一層的 happy path 偏差累積起來，最終產出的 app 在正常情境下運作良好，在任何偏離的情境下使用者都被困住。

用狀態矩陣防止

畫面狀態矩陣的四欄結構（顯示 / 可用操作 / 進入條件 / 退出路徑）強制設計者回答每個狀態的操作和退出問題。不需要預測使用者的所有行為，只需要機械式地對每個狀態填寫四欄 — 空白格自動暴露缺口。

具體的檢查規則：

退出路徑欄為空：需要補退出路徑。即使是 connecting 這種過渡狀態，使用者也應該能取消。

可用操作欄只有一個選項：使用者在這個狀態下只有一條路。如果這條路走不通（重連失敗），使用者被困住。至少考慮加一條替代路徑（返回、取消）。

進入條件是不可逆的：使用者無法自行觸發進入條件的反向操作（例如「連線成功」的反向操作「斷開連線」不存在）。這代表使用者進入後無法主動退出，只能等系統狀態變化。

狀態矩陣的價值在於機械式的完整性檢查。填完所有狀態的四欄是一個 10 分鐘的工作（以 5 個狀態的畫面為例），產出是一張可以直接轉為 test case 的表格，同時能在實作前發現所有退出路徑缺口。

矩陣的四欄定義和填寫步驟在畫面狀態矩陣的定義與填寫方法中完整展開。如果畫面設計從 BDD 操作盤點出發，從 BDD 操作盤點展開到狀態矩陣提供五步驟的展開流程。填完的矩陣可以直接轉成 widget test case — 具體方法見 testing 模組四 UI 自動化。