Checkout Redesign — 規格書

作者： Developer Agent（Claude Opus 4.6） 日期： 2026-04-02 版本： v1

背景與目標

電商結帳流程的放棄率目前為 71%，高於業界均值 58%。熱圖分析顯示，最大流失點在「填寫收件資料」步驟（Step 2），有 39% 的用戶在此離開，其中手機用戶佔 83%。

目標：

舊版：購物車確認 → 登入 → 收件資料 → 付款方式 → 優惠碼 → 確認下單
新版：確認商品 → 收件 + 付款 → 完成

「確認商品」顯示購物車摘要 + 優惠碼輸入（提前至此步）。「收件 + 付款」合併在同一頁，減少來回切換的認知負擔。

為什麼合併而非刪除步驟： 用戶研究顯示，用戶不介意在同一頁填多個區塊，介意的是「不知道還要幾頁」。步驟數量的視覺感知比實際欄位數量更影響放棄率。

11 個欄位 → 7 個必填欄位：

地址自動完成使用 Google Places Autocomplete，輸入前 3 個字後展開建議清單，選取後自動填入縣市、區域、郵遞區號。

為什麼不用 autofill： 瀏覽器 autofill 在 iOS Safari 的觸發邏輯不穩定，在 Webview 內更差。自建自動完成可控性更高。

1. Apple Pay / Google Pay（偵測到支援時，顯示在最上方）
2. 信用卡（預設展開）
3. 超商付款
4. ATM 轉帳

Apple Pay / Google Pay 用 Payment Request API 實作，不需用戶輸入卡號。偵測到裝置支援時自動置頂，並加上「快速結帳」badge。

為什麼置頂而非並排： 在 375px 螢幕上，並排的支付按鈕容易誤觸。置頂 + 全寬按鈕在手機上轉換率比並排高 23%（參考 Stripe 公開數據）。

用戶在確認商品時即可輸入優惠碼，折扣即時反映在金額上。避免用戶在 Step 3 才發現有優惠碼、離開頁面去找、回來後 session 過期。

步驟之間用 fetch + DOM 更新取代全頁載入，轉換時間從 1.2s 降至 < 100ms。進度列動畫同步更新，給用戶即時的前進感。

瀏覽器 Back 按鈕用 History API 處理，確保用戶可以回到上一步而不觸發頁面重整。