"Ux-Design"
- Gate 分類與三問設計法
每個 gate 設計時問三個問題：成功時做什麼、失敗時做什麼、使用者不知道發生什麼時做什麼
- Mobile 導航模式分類
Push/pop stack / declarative router / tab bar / drawer — 四種 mobile 導航模式各自的適用場景和使用者心理模型
- U.C1 Terminal 畫面五個狀態零個退出路徑
Flutter app 的 Terminal 畫面有 idle/connecting/connected/error/disconnected 五個 enum 狀態，每個狀態都沒有 back 或 disconnect 按鈕 — 使用者一旦進入就出不去
- 畫面狀態矩陣
說明用四欄表格（顯示/可用操作/進入條件/退出路徑）系統性地暴露畫面導航缺口的設計工具
- 畫面狀態矩陣的定義與填寫方法
四欄矩陣（顯示 / 可用操作 / 進入條件 / 退出路徑）的定義、填寫步驟和檢查規則 — 退出路徑為空 = UX 死胡同
- 輸入機制決策表
Keyboard type / submit model / IME policy / special keys 四個維度的決策框架 — 每個維度都是設計決策，影響 UI layout 和 protocol
- 錯誤訊息撰寫原則
錯誤訊息的兩個職責：使用者能讀懂發生什麼、使用者能決定下一步做什麼
- Biometric fallback 完整設計
iOS Face ID / Touch ID 和 Android BiometricPrompt 的行為差異、fallback 策略、安全 vs 可用性取捨的顯式記錄方法
- Flutter GoRouter 導航設計
GoRouter 的路由定義、導航 API（go / push / pushReplacement）、redirect 機制和 ShellRoute 的使用場景
- Gate（UX）
說明使用者操作流程中「必須通過才能繼續」的關卡，以及成功/失敗/不確定三條路徑的設計責任
- Retry 機制 UX
自動 vs 手動重試、指數退避 vs 立即重試 — 重試策略的選擇取決於失敗的可恢復性和使用者的等待意願
- Terminal app 輸入設計
CLI 場景在手機上的特殊需求 — 非自然語言輸入、特殊按鍵需求、整行 vs 逐字元送出對 protocol 的影響
- U.C2 biometricOnly=true 無密碼 fallback
Flutter app 的生物辨識設定 biometricOnly: true 阻擋所有非生物辨識認證方式 — Face ID 不可用時使用者直接被擋住，沒有替代路徑
- 從 BDD 操作盤點展開到狀態矩陣
五步驟把 BDD 操作盤點的「前端引導」展開成完整的畫面狀態矩陣 — 補上操作和退出這兩個容易遺漏的面向
- Degraded mode 設計
部分功能不可用時怎麼告知使用者 — 靜默隱藏 vs 明確標示 vs 替代方案的設計取捨
- Fallback（UX）
說明 gate 未通過時使用者的替代路徑，和 backend fallback（server-side 降級）的語意區別
- iOS HIG vs Material Design 導航差異
兩個平台在 back 行為、手勢、tab bar 位置、modal 呈現上的差異 — 跨平台 app 需要決定遵循哪套慣例
- U.C3 終端機文字輸入機制未設計、事後 hotfix 補 TextField
Flutter 終端機 app 的鍵盤輸入完全未設計 — 沒有 TextField、沒有 keyboard type 選擇、沒有 IME 控制。W2 修復時才補上 TextField + 6 個參數（enableSuggestions/autocorrect/enableIMEPersonalizedLearning/keyboardType/textInputAction/onSubmitted），全是散落 hotfix
- 表單 UX 模式
表單輸入的驗證時機、auto-fill 支援、錯誤回饋設計 — 和 terminal 輸入的決策維度相同但選項不同
- 路由可達性檢查
Router 定義的路由 vs UI 實際可達的路由 — 路由存在但 UI 不可達等於死程式碼的 UX 版本
- 網路斷線 UX 模式
Offline-first / retry / degraded mode 三種網路 gate 的處理策略 — 取決於功能是否依賴即時連線
- Deep link 設計
URL scheme / Universal Link / App Link — deep link 讓外部來源直接導航到 app 的特定畫面
- error → retry → error 循環的逃生口設計
當重試持續失敗時，使用者需要第二條路 — 逃生口設計讓使用者能離開失敗循環而非被困住
- Permission 請求時機與措辭
系統權限請求的時機選擇（首次開啟 vs 功能使用時）和說明文字的設計 — 使用者只有一次機會理解為什麼需要這個權限
- U.C4 首頁缺配對入口按鈕、導航流未完整列出
Flutter app 首頁只有 Connect Terminal 按鈕、沒有 Enroll Device 入口 — 使用者首次使用時找不到配對功能。根因是導航流設計只考慮了日常操作（UC-02 連線）、遺漏了首次操作（UC-01 配對）的入口
- 反模式：假設使用者只走 happy path
為什麼開發者容易只設計 happy path 的 UI、使用者在非 happy path 狀態下被困住的機制分析、以及用狀態矩陣系統性地防止這個問題
- 搜尋 UX 模式
Debounce / instant / suggestion 三種搜尋模式的取捨 — 和輸入機制的 submit model 維度直接相關
- go vs push vs pushReplacement 的 UX 語意表
三種導航方法對堆疊、back 行為、使用者心理模型的影響 — 選擇依據是使用者的意圖而非技術方便
- 安全敏感輸入框的 IME 控制 checklist
處理密碼、API key、伺服器路徑等 secret 的輸入框需要關閉 IME 的個人化學習和自動校正 — 安全要求而非 UX 偏好
- 開發環境 vs 真機的 gate 行為差異表
模擬器、debug build、test 環境中的 gate 行為和真機 release build 不同 — 差異表讓開發者在上機前知道哪些 gate 還沒被真實驗證