三問設計法

每個 gate 設計時回答三個問題：

成功時做什麼

Gate 通過後使用者進入下一步。這是最直覺的設計 — 認證成功進入主畫面、網路連線成功開始載入資料、權限授予後啟用功能。

成功路徑通常是設計時最先考慮的，也是最不容易遺漏的。

失敗時做什麼

Gate 未通過時使用者的替代路徑。替代路徑可以是：降級功能（部分功能可用）、替代驗證方式（密碼代替 Face ID）、手動重試（重試按鈕）、放棄操作（返回上一頁）。

失敗路徑是最容易遺漏的。app_tunnel 的 biometric gate 設定 biometricOnly: true，Face ID 不可用時使用者直接被擋住，沒有密碼 fallback、沒有跳過選項、沒有返回路徑（U.C2）。修復只改一個 boolean — biometricOnly: false — 讓系統自動提示輸入裝置密碼。但這個決策應該在企劃階段做，而非實機測試時才發現。

使用者不知道發生什麼時做什麼

Gate 處理中（loading）或結果不確定（timeout）時使用者看到什麼、能做什麼。

使用者不知道發生什麼的情境包括：認證彈窗尚未出現（系統延遲）、網路請求已發但未回應（loading）、權限對話框被系統遮擋（多個 dialog 堆疊）。

在這個狀態下使用者需要的是：知道系統在做什麼（loading 指示）、可以取消等待（取消按鈕）、超過合理時間後有提示（timeout 訊息 + 重試選項）。

Gate 的四種常見類型

認證 Gate

使用者必須驗證身份才能使用功能。生物辨識、密碼、PIN 碼、OAuth 登入。

認證 gate 的 fallback 設計取決於安全需求和使用場景。銀行 app 可能要求生物辨識 + PIN 碼雙重驗證，沒有更低層級的 fallback。自用工具可以接受密碼 fallback，因為使用者本身就是 owner — 可用性優先於認證強度（U.C2）。

網路 Gate

功能需要網路連線才能運作。連線存在但不穩定的場景比完全離線更難處理 — 請求可能成功、可能逾時、可能部分成功。

權限 Gate

App 需要系統權限（相機、位置、通知）才能使用特定功能。

權限 gate 的特殊性在於使用者可以永久拒絕。拒絕後再次請求不會彈出系統對話框 — 必須引導使用者到系統設定手動開啟。

環境 Gate

特定的硬體或軟體條件必須滿足。最低 OS 版本、特定感測器（NFC、深度相機）、特定連接（藍牙已開啟）。

環境 gate 的 fallback 通常有限 — 硬體不存在時無法用軟體模擬。但至少應該告知使用者為什麼功能不可用，而非靜默禁用。

其他常見 Gate

商業 app 還有兩種 gate 在本系列涵蓋範圍之外但實務常見：

付費 Gate（paywall）：功能需要付費才能使用。付費 gate 的 fallback 設計和上述四種不同 — 「失敗」路徑的目標是引導使用者付費而非提供替代功能。試用期、降級功能、付費引導 vs 付費強制的取捨依賴商業模式決策。

版本相容性 Gate：API 版本過舊需要升級 app。Fallback 是提示使用者更新，但強制更新會阻擋無法更新的使用者（舊 OS 版本不支援新版 app）。

Gate 設計表

把三問設計法應用到每個 gate，產出一張設計表：

失敗欄和不確定欄為空的 gate 就是 UX 死胡同的候選 — 和畫面狀態矩陣的退出路徑檢查同樣的邏輯。

三問設計法的具體應用在 Biometric fallback 完整設計中以生物辨識 gate 為例展開。Gate 在開發環境的行為可能和真機不同，開發環境 vs 真機的 gate 行為差異表列出每個 gate 在模擬器和真機上的差異。Gate 設計表的「失敗」欄和畫面狀態矩陣的「退出路徑」欄是同一個問題在不同層級的表達。

概念位置

UX 語境的 gate 聚焦在使用者體驗層 — 關注的是「使用者被擋住時看到什麼、能做什麼」。和 backend 語境的 gate decision 不同，後者關注的是部署流程中的品質關卡。Gate 的失敗路徑和不確定路徑應該反映在畫面狀態矩陣的退出路徑欄中。

可觀察訊號與例子

需要 gate 設計的訊號是使用者在某個功能前被阻擋且沒有替代路徑。常見情境：biometric 認證失敗後使用者無法進入 app、網路斷線後使用者被困在 loading 畫面、權限被拒後功能靜默消失但使用者不知道為什麼。

設計責任

Gate 的設計責任是確保每條路徑都有明確的使用者體驗。成功路徑通常最先被設計；失敗路徑需要提供 UX fallback（替代驗證、降級功能、返回上一頁）；不確定路徑需要 loading 指示和取消操作。開發環境可能遮蔽 gate 問題 — 模擬器跳過認證、debug build 自動授權 — 差異表讓開發者在上機前知道哪些 gate 還沒被真實驗證。

對應 findings

待寫章節

• Gate 分類與三問設計法（成功 / 失敗 / 使用者不知道發生什麼）
• Biometric fallback 完整設計（iOS/Android 差異）
• 網路斷線 UX 模式（offline-first / retry / degraded mode）
• Permission 請求時機與措辭
• 開發環境 vs 真機的 gate 行為差異表

跨分類引用

• → testing 模組一 測試策略：gate fallback 的 mock vs 真機行為差異需要 protocol test
• → monitoring 模組七 資安：biometric fallback 的安全 vs 可用性取捨

概念位置

UX fallback 位在 Gate 設計的失敗路徑中。Gate 的三問（成功/失敗/不確定）中，失敗路徑的具體內容就是 UX fallback。Backend 的 fallback 是系統在依賴失敗時用替代結果維持服務，UX fallback 是使用者在 gate 失敗時的操作替代方案。兩者可能並存 — server-side fallback 提供降級資料，UX fallback 決定如何呈現這些降級資料給使用者。

可觀察訊號與例子

需要 UX fallback 的訊號是 gate 失敗時使用者完全無法繼續。常見情境：biometric 設定 biometricOnly: true 導致 Face ID 失敗時沒有密碼 fallback、error 畫面只有重試按鈕沒有返回按鈕、網路斷線後所有功能不可用但部分功能不依賴網路。

設計責任

UX fallback 的設計責任是確保 gate 失敗時使用者有路可走。Fallback 的選擇取決於安全需求和使用場景 — 銀行 app 可能不提供低安全等級的 fallback，自用工具可以接受密碼 fallback 因為使用者就是 owner。安全 vs 可用性的取捨應在功能規格中顯式記錄。UX fallback 的存在應反映在畫面狀態矩陣的退出路徑欄中。

三種處理策略

Offline-first

功能的核心操作在本地完成，網路用於同步。斷線時使用者仍可操作，重新連線後自動同步差異。

Offline-first 適合的前提是資料可以本地存儲且衝突可以解決。筆記 app、待辦事項、表單填寫 — 使用者的操作產生本地資料，網路只負責把資料同步到 server。

Offline-first 的 UX 設計重點是讓使用者知道同步狀態：已同步、待同步、同步失敗。不需要 gate — 網路狀態不阻擋使用者操作。

Retry with feedback

功能需要網路但可以等待。斷線時顯示狀態和重試選項，使用者決定要等還是離開。

app_tunnel 的 terminal 連線屬於這個模式。WebSocket 連線需要網路，斷線時使用者無法操作終端機。error 和 disconnected 狀態提供重連按鈕讓使用者手動重試。

Retry 策略的 UX 設計重點：

• 告知使用者發生什麼（「連線中斷」而非空白畫面）
• 提供手動重試（重連按鈕）
• 提供退出路徑（返回首頁 — app_tunnel 原本缺少這個）
• 自動重試要有上限和間隔遞增（避免無限重試消耗電量）

Degraded mode

功能部分依賴網路。核心功能離線可用，進階功能需要網路。斷線時自動切換到降級模式，不阻擋使用者操作但功能受限。

降級模式的 UX 設計重點是清楚標示哪些功能可用、哪些不可用。「離線模式 — 搜尋功能暫時不可用」比靜默隱藏搜尋按鈕更透明。

網路狀態的 UI 呈現

全域指示器

在 app 頂部或狀態列顯示「離線」標示。適合網路狀態影響全域功能的 app。

功能級指示器

在需要網路的功能旁邊顯示不可用狀態。適合只有部分功能依賴網路的 app。

非侵入式通知

用 Snackbar 或 Toast 短暫顯示「已恢復連線」或「網路中斷」。適合網路狀態偶爾變化的場景。不適合頻繁斷開重連的場景（通知太多會干擾使用者）。

連線但品質差的場景

網路存在但延遲高或頻繁斷開，比完全離線更難處理。完全離線時 app 可以立即切換到離線模式；連線不穩定時，每次請求可能成功也可能逾時，使用者體驗是「有時候行有時候不行」。

處理策略：

• 設定合理的逾時時間（太短會把慢回應判定為失敗，太長讓使用者等太久）
• 逾時後顯示狀態和重試選項，不自動重試（避免在不穩定網路上累積重試）
• 在 loading 狀態提供取消選項，讓使用者可以中斷等待

下一步路由

• Gate 設計的通用方法論 → Gate 分類與三問設計法
• 權限請求的 UX 設計 → Permission 請求時機與措辭
• 畫面狀態矩陣中的網路狀態 → ux-design 模組一 畫面狀態機
• Server 端背壓如何影響 client UX → DevOps 背壓機制

請求時機

首次開啟時一次性請求

App 首次啟動時依序請求所有需要的權限。優點是使用者只被打斷一次；缺點是使用者尚未使用任何功能，不理解每個權限的用途，傾向拒絕。

這個模式適合權限數量少（1-2 個）且和 app 核心功能直接相關的情境。相機 app 在首次開啟時請求相機權限，使用者能直覺理解原因。

功能使用時即時請求

使用者點擊需要權限的功能時才請求。優點是使用者在操作 context 中，能理解為什麼需要這個權限；缺點是操作流程被打斷。

這個模式適合權限和特定功能綁定的情境。掃描 QR code 時請求相機權限，使用者正在嘗試掃描，理解為什麼需要相機。

推薦策略

功能使用時即時請求是多數場景的推薦策略。使用者有操作 context，授權率較高。打斷可以透過 pre-permission 說明畫面降低突兀感。

Pre-permission 說明畫面

在觸發系統權限對話框之前，app 先顯示自己的說明畫面，解釋為什麼需要這個權限和用途。

說明畫面的設計要點：

說明用途而非技術細節。「需要相機來掃描裝置上的 QR code」比「app 需要存取 AVCaptureDevice」更有用。使用者關心的是「為什麼」，不是「用什麼 API」。

提供「稍後再說」選項。使用者可能想先了解 app 再決定是否授權。強制授權（沒有跳過選項）會讓使用者選擇拒絕。

視覺化說明。用截圖或圖示展示「授權後這個功能長什麼樣」，讓使用者預覽授權的價值。

拒絕後的處理

使用者拒絕權限後，app 需要：

記住拒絕狀態。不要在每次使用者操作同一功能時都顯示 pre-permission 說明（使用者已經表達不想授權，反覆詢問是騷擾）。

提供功能降級。如果可能，提供不需要權限的替代方案。掃描 QR code 可以改成手動輸入配對碼。

在適當時機再提醒。使用者多次使用需要權限的功能但都因為沒有權限而失敗時，用非侵入式提示（Snackbar）說明「開啟相機權限可以使用掃描功能」加設定連結。

引導到系統設定。一旦使用者在系統對話框中選擇「不再詢問」（Android）或拒絕（iOS 拒絕後系統不再彈窗），唯一的路徑是引導使用者到系統設定手動開啟。提供直接跳轉到 app 設定頁面的按鈕。

下一步路由

• Gate 設計的通用方法論 → Gate 分類與三問設計法
• 網路 gate 的處理策略 → 網路斷線 UX 模式
• 開發環境遮蔽 gate 問題 → 開發環境 vs 真機的 gate 行為差異表

差異機制

模擬器不支援硬體功能

iOS 模擬器不支援 Face ID / Touch ID 硬體。local_auth 的 isAvailable() 在模擬器上回傳 false（isDeviceSupported() 為 true 但 getAvailableBiometrics() 為空），app 跳過認證走預設路徑。

在真機上 isAvailable() 回傳 true，app 嘗試認證，如果設定了 biometricOnly: true 且 Face ID 失敗，使用者被擋住。模擬器上「跳過認證直接使用」的體驗讓開發者以為認證流程沒有問題（U.C2）。

Debug build 的權限行為不同

某些平台在 debug build 和 release build 的權限處理不同。例如 Android 的某些 OEM 客製化系統在 debug mode 下自動授予特定權限，release mode 下需要手動授權。

Test 環境跳過 gate

Unit test 和 integration test 通常 mock 掉所有 gate — FakeBiometricService 永遠回傳成功，FakeNetworkChecker 永遠回傳已連線。這和名義 integration test 的問題相同 — test 環境的「一切正常」遮蔽了真實環境的 gate 失敗場景。

Gate 行為差異表

在功能規格中建立一張差異表，列出每個 gate 在不同環境下的行為差異：

差異表的使用方式

開發階段

開發者對照差異表，意識到哪些 gate 在當前環境下沒有被真實驗證。差異表中「模擬器行為」和「真機 release」不同的行 = 需要上真機確認的項目。

實機測試規劃

測試計畫中針對差異表的每一行設計測試案例。生物辨識的測試案例必須涵蓋「Face ID 失敗時的 fallback」，網路連線的測試案例必須涵蓋「飛航模式下的 UX」。

Code review

Review 涉及 gate 的程式碼時，對照差異表確認 fallback 路徑是否存在。如果 review 的程式碼用了 biometricOnly: true，差異表立刻提示「模擬器上看不到這個問題，需要上真機確認 fallback」。

差異表揭露的問題和 testing 領域的 mock 遮蔽在結構上相同 — testing 模組一 Mock 遮蔽機制從 API 層 vs 協議層的角度分析同一類問題。差異表本身是三問設計法在實機驗證階段的延伸，biometric gate 的完整 fallback 設計見 Biometric fallback 完整設計。