行動銀行 App UX：我們在合規下的三個設計取捨

這篇文章適合誰

• 產品／行銷：需要向管理層說明「為何金融 App 不能像電商一樣三步註冊」，同時又要控制 onboarding 流失率。
• UX／開發：負責 KYC、OTP、生物辨識與法遵文案整合的行動銀行團隊。

問題背景

行動銀行 App 的每個畫面都可能涉及個資蒐集、契約同意、身分驗證與交易安全，上線前須通過法遵與資安審查。實務上常見的矛盾是：法規要求步驟完整、稽核要求留痕，但使用者期望「五分鐘開戶」；一旦證件照片上傳失敗或 OTP 逾時，畫面只顯示錯誤代碼或制式警示，使用者不知道要重拍、換網路還是隔天再試。

我們在金融科技專案中觀察到：onboarding 流失往往不是卡在「步驟太多」，而是卡在「失敗後無法恢復」。合規不是 UX 的敵人，但若設計階段只交給工程師套 API，送審前才補法遵文案，往往要整段重做。

決策者摘要：合規約束下仍可做體驗——關鍵是可恢復流程、可執行錯誤訊息、以及設計初期就納入法遵；三者缺一，再漂亮的視覺也救不了轉換率。

取捨一：可恢復的 checkpoint，而非一次走完

行銷／產品關注： 使用者中途離開（來電、證件不在身邊）若必須從頭開始，流失率會在第二次開啟 App 時飆升；客服也會收到大量「我昨天填到哪」的詢問。

設計與技術做法：

• 將 onboarding 拆成可獨立完成的階段：手機驗證 → 身分證件 → 人臉／活體 → 契約閱讀 → 帳戶啟用
• 每階段結束寫入伺服器端進度，換機或重裝 App 可從最後通過的 checkpoint 繼續
• 未完成階段在首頁以明確 CTA 提示（「還差 2 步即可啟用轉帳」），而非空白首頁
• 進度條顯示「已完成／總步驟」，避免使用者誤以為還有十幾個隱藏關卡
• 技術上：進度與 KYC 審核狀態分離——使用者可補件，後台審核可非同步進行

我們放棄什麼： 不追求「單頁式」極簡註冊；法遵與稽核需要階段性同意紀錄，強行合併畫面反而在送審時被要求拆開。

取捨二：可執行的錯誤回饋，而非僅顯示錯誤碼

行銷／產品關注： 驗證失敗若只顯示「E_KYC_042」，使用者會認為 App 壞了並在商店留下一星評價；客服成本遠高於多寫幾句白話說明。

設計與技術做法：

• 每個失敗情境對應下一步動作：「光線不足，請至窗邊重拍證件正面」「簡訊驗證碼已逾時，點此重新發送」
• 錯誤文案由法遵審過的範本庫維護，工程師綁定錯誤類型而非自由撰寫
• 區分可重試與需人工審核：後者顯示預計處理時間與查詢管道，避免無限重試
• 技術日誌保留錯誤碼與 trace id；使用者畫面不顯示內部代碼，客服後台可依代碼查詢
• 網路逾時與伺服器錯誤分開處理：前者建議切換網路，後者顯示「服務忙碌」並允許稍後重送

失敗類型	使用者看到	系統行為
證件模糊	具體重拍指引 + 範例圖	不消耗當日重試額度
OTP 逾時	重新發送按鈕 + 倒數	速率限制防濫發
黑名單／需人工	說明與預計天數	停止自動重試，建立審核單

我們放棄什麼： 不在畫面上堆疊完整法條——改在「延伸說明」連結與契約附錄；主流程保持可掃讀。

取捨三：設計階段引入法遵，而非送審後才改

行銷／產品關注： 活動檔期若因 UX rework 延後上線，錯失的不只是下載量，還有與同業功能對齊的窗口。

設計與技術做法：

• 在 wireframe 階段 邀請法遵參與：哪些欄位必填、哪些同意要勾選、哪些操作要二次確認
• 建立元件庫：已審過的按鈕文案、風險揭露區塊、OTP 與生物辨識提示，新功能優先重用
• 工程與法遵共用情境清單（新戶註冊、裝置更換、大額轉帳、忘記密碼），每情境標註必留 log 的操作
• 送審前做合規走查：截圖 + 操作路徑 + 對應條款，減少「請補充說明第 7 點」的往返
• .NET 後端 API 與 App 共用同一套業務錯誤枚舉，避免 iOS／Android 文案不一致

我們放棄什麼： 不讓每個產品經理自創風險揭露用語——統一由法遵範本產出，犧牲少許文案「創意」換取審查可預測性。

量測與迭代

上線後建議追蹤：

• 各 checkpoint 完成率與平均停留時間
• 驗證失敗後 24 小時內回訪率（可恢復設計的成效指標）
• 客服工單中「看不懂錯誤訊息」占比
• 送審往返次數與從設計凍結到上架的天數

A/B 測試在受監管功能上需謹慎——優先測文案清晰度與步驟順序，而非省略法定步驟。

下一步

若貴單位正在改版行動銀行或數位帳戶 onboarding，建議先盤點失敗情境清單與現有錯誤碼對照，再評估 checkpoint 拆分。我們在金融科技 App 與合規流程整合有相關經驗——歡迎透過網站聯絡，討論可用元件庫與分階段優化範圍。