啟用快速登入：立即使用者介面模式 UX 模式

Eiji Kitamura

發布日期：2026 年 9 月 30 日，上次更新日期：2026 年 10 月 7 日

總覽

即時 UI 模式可解決因導向專屬登入頁面而導致的情境遺失和使用者流失問題。這項功能可讓使用者快速登入，直接在瀏覽或處理的頁面上，使用密碼金鑰或已儲存的密碼完成登入，不必離開目前的情境。

與條件式 UI 不同，使用者聚焦文字輸入欄位時，條件式 UI 會顯示自動填入建議，而「立即」UI 模式則會在使用者點按按鈕或連結時，立即叫用瀏覽器的驗證對話方塊 (目前 uiMode 只接受 "immediate"，但日後可能會變更)。

即時 UI 模式有三項核心特徵，可有效快速登入：

  • 略過跨裝置 QR code：如果裝置上已有可立即使用的密碼金鑰或已儲存的密碼，瀏覽器會立即顯示驗證對話方塊。如果沒有，系統會立即結束，不會顯示智慧型手機的跨裝置 QR code 畫面。 這樣一來，網站就能自然轉換為一般備用導覽 (例如移至登入頁面)。
  • 直覺式帳戶選取 UI：系統不會個別列出混合類型的憑證，而是隱藏密碼金鑰和密碼之間的差異，提供直覺式帳戶選擇器，讓使用者專注於要登入的帳戶。
  • 安全漸進增強：雖然僅支援 Google Chrome 和 Chromium 瀏覽器，但使用功能偵測功能，即可在支援的環境中為使用者提供快速登入服務，同時不會中斷不支援瀏覽器 (例如 Safari 或 Firefox) 或無痕模式使用者的現有登入流程。

如要進一步瞭解 API 的運作方式，以及如何實作功能偵測，請參閱「登入的即時 UI 模式」。本文將探討建議使用的 UX 模式，說明如何透過即時 UI 模式提高轉換率，以及應避免的設計反模式。

最適合使用 Immediate UI 模式的地方，是在網頁導覽前進行攔截。每當未經驗證 (或工作階段過期) 的使用者點選連結或動作按鈕，正常情況下系統會將他們導向登入頁面，此時叫用「立即 UI」模式可建立流暢的 UX，絕不會中斷他們的工作流程。

大多數網站會在畫面頂端的全域標題中放置「登入」連結，導向專屬登入頁面。使用者在瀏覽的頁面上點選這個連結時，瀏覽器會暫停導覽並叫用「立即 UI」模式，如果裝置上有憑證，瀏覽器就會在目前頁面上顯示帳戶選取對話方塊。

使用者選取帳戶並完成驗證後，標題會更新為登入狀態，且不會導覽至其他頁面，讓使用者繼續瀏覽，不必離開目前查看的頁面。反之，如果裝置上沒有憑證，系統就不會顯示任何瀏覽器使用者介面，使用者會順利前往登入頁面，與原本的意圖完全一致。

結帳時動態登入 (電子商務)

在電子商務網站上，從購物車到結帳的過程，是因網頁瀏覽阻礙而導致購物車放棄率偏高的最常見原因之一。當未經驗證的購物者點選購物車畫面上的「Proceed to Checkout」按鈕時，系統會立即叫用 Immediate UI 模式，在點選按鈕的位置顯示帳戶選取對話方塊，只要輕觸一下即可完成驗證。

驗證成功後，購物者會完全略過登入頁面，直接進入最終的運送和付款確認畫面 (結帳頁面)，大幅減少完成購買所需的步驟。如果沒有憑證，購物者會照常前往傳統登入或訪客結帳選項畫面。您可以根據業務需求設計網站，允許訪客結帳或要求登入。立即 UI 模式可消除回訪顧客的結帳流程阻力。

微動作 (喜歡、加入書籤、儲存) 的內嵌登入功能

當訪客瀏覽社群動態消息、社群網站或電子商務產品目錄時，如果每次嘗試「喜歡」貼文或「將項目加入書籤」時，系統都會強制將他們重新導向至登入頁面，可能會導致部分使用者放棄操作。

如果未登入的訪客點選「喜歡」、「書籤」或「儲存」等動作按鈕，系統會立即在該位置顯示「立即 UI 模式」對話方塊，讓訪客完成身分驗證，並立即觸發動作記錄和 UI 動畫 (例如愛心圖示變成紅色)。捲動位置不會移動單一像素，完全保留瀏覽沉浸感。如果沒有憑證，您可以顯示輕量型內嵌登入模式，覆蓋目前的畫面，或引導使用者前往登入頁面，讓他們登入後返回原處，而不是立即離開。

解鎖發布商網站的付費牆

新聞媒體和內容平台廣泛採用一種模式，讓使用者可免費存取文章的開頭段落，但當讀者捲動頁面到一半時，會看到軟付費牆或僅限會員的模糊處理內容。

讀者捲動文章並抵達付費牆後，如果點選「使用帳戶繼續閱讀」按鈕，系統就會叫用「立即 UI」模式，在讀者暫停捲動的位置顯示驗證對話方塊。驗證完成後，文章模糊效果會立即消失，且網頁不會重新載入，讀者可繼續閱讀，不會錯過原本正在看的文字。如果沒有憑證，請展開付費牆區段中的內嵌註冊或登入表單。

應避免的反模式

在網頁導覽之前使用「立即顯示 UI」模式，可帶來極大的價值，但如果將其放在錯誤的位置，或套用至不支援的流程，則會嚴重影響使用者的登入體驗。

避免在專屬登入頁面的登入按鈕上使用「立即」UI 模式

由於「立即顯示 UI」模式會在單一精緻對話方塊中處理密碼金鑰和密碼，因此您可能會想在專屬登入頁面上的「登入」按鈕使用這項模式。不過，請避免在此使用。首先，「立即」UI 模式嚴格要求使用者啟用 (例如點選或輕觸)，因此在登入頁面上會顯得不自然，因為使用者可能會希望在頁面載入時，就能立即使用登入選項。其次，如果使用者裝置上沒有本機憑證，或是想透過行動裝置上的密碼金鑰 (跨裝置驗證) 或硬體安全金鑰登入，登入頁面就是最終目的地。使用者只要點選「使用密碼金鑰登入」，就會前往登入頁面。如果您在此使用「立即」UI 模式，瀏覽器會停用跨裝置 QR code 和安全金鑰備援，並在裝置上找不到本機憑證時立即終止，導致使用者陷入死胡同，因為點選按鈕後，系統不會將使用者導向任何頁面。

在每個驗證方法都必須正常運作的登入頁面，最佳做法是在輸入欄位設定條件式 UI (自動填入整合)，確保本機密碼金鑰的便利性，同時將明確的「使用密碼金鑰登入」按鈕與標準叫用方法配對，以便可靠地顯示跨裝置 QR code 和安全金鑰選項。

避免在逐步重新驗證時使用「立即」UI 模式

登入使用者執行敏感操作時 (例如變更密碼、更新運送地址、編輯已儲存的付款方式或新增密碼金鑰)，網站通常會要求重新驗證身分，由於使用者已登入，重新驗證流程通常會傳遞非空白的 allowCredentials 清單，將驗證限制為屬於該特定使用者的憑證。

不過，請勿使用「立即」UI 模式重新驗證身分。「立即」UI 模式專為未經驗證的登入流程設計，這時系統還不知道使用者的身分。如果依賴方可以在「立即」使用者介面模式中查詢特定憑證 ID 清單，並觀察憑證是否存在，就能推斷使用者是否曾與該網站互動，並跨工作階段追蹤使用者。為避免這種跨工作階段追蹤風險，瀏覽器會立即拒絕任何包含非空白 allowCredentials 清單的即時 UI 模式要求，並擲回 NotAllowedError。反之，在重新驗證期間省略 allowCredentials 也有問題，因為瀏覽器會顯示裝置上儲存的所有網站憑證，讓使用者不小心選取目前登入的帳戶以外的帳戶。

如要進行逐步重新驗證 (使用者身分已知的驗證)，請使用標準模式 WebAuthn 要求 (navigator.credentials.get()，不含 uiMode: 'immediate')，並在 allowCredentials 中填入已登入使用者註冊的憑證，或將使用者導向標準重新驗證挑戰畫面。

結論

立即 UI 模式是強大的 UX 工具，可消除登入頁面的不必要繞道，並實現快速登入，在保留內容的同時完成登入。在網頁瀏覽發生前，攔截使用者意圖明確的時刻 (例如標頭登入連結、結帳按鈕、微行動和文章付費牆)，即可防止使用者流失，並提供流暢的使用者體驗。

同時請注意，在網頁瀏覽之前，立即 UI 模式嚴格來說是未經驗證使用者的漸進增強功能。請避免將這項功能套用至最終目的地登入頁面的按鈕，確保設計保持開放，且跨裝置 (QR code) 使用者可存取，並避免用於需要 allowCredentials 的重新驗證流程。

如要進一步瞭解如何導入密碼金鑰和最新的 Web Identity 功能，請參閱下列資源：