付款和地址表單的最佳做法

協助使用者盡可能快速輕鬆地填寫地址和付款表單，盡量爭取轉換。

Sam Dutton

設計良好的表單可協助使用者，並提高轉換率。小小的修正就能帶來很大的差異！

以下是簡單的付款表單範例，示範所有最佳做法：

以下是簡單的地址表單範例，示範所有最佳做法：

檢查清單

• 使用有意義的 HTML 元素：<form>、<input>、<label> 和 <button>。
• 使用 <label> 為每個表單欄位加上標籤。
• 使用 HTML 元素屬性存取內建瀏覽器功能，尤其是 type 和 autocomplete，並設定適當的值。
• 請避免將 type="number" 用於不應遞增的數字，例如付款卡號。請改用 type="text" 和 inputmode="numeric"。
• 如果 input、select 或 textarea 有適當的自動完成值，請務必使用。
• 為協助瀏覽器自動填入表單，請為輸入 name 和 id 屬性提供穩定值，不會在載入網頁或網站部署之間變更。
• 停用提交按鈕：在使用者輕觸或點選提交按鈕後，停用該按鈕。
• 在輸入資料時驗證，而非等到提交表單時才驗證。
• 將訪客結帳設為預設選項，並在結帳完成後提供簡單的帳戶建立流程。
• 以明確的步驟和行動號召，顯示結帳程序的進度。
• 移除雜亂和干擾元素，減少潛在的結帳離開點。
• 在結帳時顯示完整的訂單詳細資料，並讓顧客能輕鬆調整訂單。
• 請勿要求不需要的資料。
• 除非有充分理由，否則請使用單一輸入欄位要求使用者輸入姓名。
• 不要強制要求姓名和使用者名稱只能使用拉丁字元。
• 允許各種地址格式。
• 建議使用單一 textarea 欄位填寫地址。
• 使用帳單地址自動完成功能。
• 視需要國際化和本地化。
• 建議避免郵遞區號地址查詢。
• 使用適當的付款卡自動完成值。
• 付款卡號使用單一輸入欄位。
• 如果自訂元素會破壞自動填入體驗，請避免使用。
• 在實際環境和實驗室中測試：網頁數據分析、互動數據分析，以及實際使用者效能評估。
• 在各種瀏覽器、裝置和平台上測試。

使用有意義的 HTML

使用專為這項工作設計的元素和屬性：

• <form>、<input>、<label>和<button>
• type、autocomplete 和 inputmode

這些元素可啟用內建瀏覽器功能、改善無障礙功能，並為標記增添意義。

按照預期用途使用 HTML 元素

將表單放在 <form> 中

您可能不想費心將 <input> 元素包裝在 <form> 中，而是想完全使用 JavaScript 處理資料提交。

千萬別這麼做！

HTML <form> 可讓您在所有新式瀏覽器中存取一組強大的內建功能，並協助螢幕閱讀器和其他輔助裝置存取您的網站。<form> 也能簡化為 JavaScript 支援有限的舊版瀏覽器建構基本功能，並在程式碼發生問題時啟用表單提交功能，以及為少數實際停用 JavaScript 的使用者啟用表單提交功能。

如果有多個用於使用者輸入內容的頁面元件，請務必將每個元件放入各自的 <form> 元素中。舉例來說，如果搜尋和註冊功能位於同一個網頁，請分別放在不同的 <form> 中。

使用 <label> 標示元素

如要為 <input>、<select> 或 <textarea> 加上標籤，請使用 <label>。

將標籤的 for 屬性設為與輸入內容的 id 相同的值，即可將標籤與輸入內容建立關聯。

<label for="address-line1">Address line 1</label>
<input id="address-line1" …>

一個輸入欄位只使用一個標籤：請勿嘗試用一個標籤標示多個輸入欄位。這種做法最適合瀏覽器和螢幕閱讀器。輕觸或點選標籤會將焦點移至相關聯的輸入欄位，當標籤或標籤的輸入欄位取得焦點時，螢幕閱讀器會朗讀標籤文字。

讓按鈕發揮作用

按鈕請使用 <button>！您也可以使用 <input type="submit">，但請勿使用 div 或其他隨機元素做為按鈕。按鈕元素提供無障礙行為、內建表單提交功能，且可輕鬆設定樣式。

為每個表單提交按鈕提供說明其功能的值。在結帳流程的每個步驟中，使用描述性的行動號召，顯示進度並明確指出下一步。舉例來說，請將寄送地址表單上的提交按鈕標示為「Proceed to Payment」(前往付款)，而非「Continue」(繼續) 或「Save」(儲存)。

建議您在使用者輕觸或點選提交按鈕後停用該按鈕，尤其是在使用者付款或下單時。許多使用者會重複點按按鈕，即使按鈕運作正常也一樣。這可能會導致結帳流程出錯，並增加伺服器負載。

const form = document.querySelector('form');
const submitButton = form.querySelector('button[type="submit"]');

form.addEventListener('submit', () => {
  submitButton.disabled = true;
  submitButton.textContent = 'Placing order…';
});

另一方面，請勿在等待使用者輸入完整且有效的內容時，停用提交按鈕。舉例來說，請勿因為缺少某些內容或內容無效，而停用「儲存地址」按鈕。這對使用者沒有幫助，他們可能會繼續輕觸或點選按鈕，並認為按鈕已損壞。 相反地，如果使用者嘗試提交含有無效資料的表單，請向他們說明問題所在，以及如何修正。這在行動裝置上尤其重要，因為行動裝置較難輸入資料，而且使用者嘗試提交表單時，可能不會在螢幕上看到遺漏或無效的表單資料。

充分運用 HTML 屬性

讓使用者輕鬆輸入資料

使用適當的輸入 type 屬性，在行動裝置上提供正確的鍵盤，並啟用瀏覽器的基本內建驗證功能。

例如，電子郵件地址使用 type="email"，電話號碼則使用 type="tel"。

日期部分，請盡量避免使用自訂 select 元素。如果未正確實作，會破壞自動填入體驗，且無法在舊版瀏覽器上運作。如果是出生年份等數字，建議使用 input 元素，而非 select，因為手動輸入數字可能比從冗長的下拉式選單中選取更簡單，也更不容易出錯，尤其是在行動裝置上。請使用 inputmode="numeric"，確保行動裝置上顯示正確的鍵盤，並使用文字或預留位置新增驗證和格式提示，確保使用者以適當的格式輸入資料。

使用自動完成功能，提升無障礙程度，並協助使用者避免重新輸入資料

使用適當的 autocomplete 值，瀏覽器就能安全地儲存資料，並自動填入 input、select 和 textarea 值，為使用者提供協助。這在行動裝置上尤其重要，也是避免表單放棄率過高的關鍵。自動完成功能也提供多項無障礙功能優勢。

如果表單欄位有適當的自動完成值，請務必使用。MDN 網頁文件提供完整的值清單，以及如何正確使用這些值的說明。

穩定值

帳單地址

根據預設，帳單地址會與寄送地址相同。提供編輯帳單地址的連結 (或使用 summary 和 details 元素)，而不是在表單中顯示帳單地址，以減少視覺雜亂。

請為帳單地址使用適當的自動完成值，就像為運送地址設定一樣，這樣使用者就不必多次輸入資料。如果不同區段中相同名稱的輸入欄位有不同的值，請在自動完成屬性中加入前置字詞。

<input autocomplete="shipping address-line1" ...>
<!-- Other fields omitted. -->
<input autocomplete="billing address-line1" ...>

協助使用者輸入正確資料

請避免因為客戶「做錯事」而「斥責」他們。請在使用者發生問題時協助他們修正，讓他們能更快速輕鬆地填寫表單。在結帳過程中，顧客會嘗試向貴公司支付產品或服務的費用，您的工作是協助他們，而不是懲罰他們！

您可以在表單元素中加入限制屬性，指定可接受的值，包括 min、max 和 pattern。系統會根據元素的值是否有效，自動設定元素的有效性狀態，以及 :valid 和 :invalid CSS 虛擬類別，可用於設定具有有效或無效值的元素樣式。

舉例來說，下列 HTML 指定了 1900 到 2020 年之間的出生年份輸入內容。使用 type="number" 會將輸入值限制為數字，範圍由 min 和 max 指定。如果嘗試輸入超出範圍的數字，輸入內容會設為無效狀態。

以下範例使用 pattern="[\d ]{10,30}" 確保付款卡號有效，同時允許空格：

新式瀏覽器也會對 email 或 url 類型的輸入內容進行基本驗證。

提交表單時，瀏覽器會自動將焦點設在有問題或缺少必要值的欄位。不需使用 JavaScript！

在使用者輸入資料時，即時驗證並提供意見回饋，而不是在他們點選提交按鈕時才提供錯誤清單。如果需要在提交表單後驗證伺服器上的資料，請列出所有發現的問題，並清楚醒目標示所有含有無效值的表單欄位，同時在每個有問題的欄位旁顯示內嵌訊息，說明需要修正的部分。查看伺服器記錄和數據分析資料，找出常見錯誤，您可能需要重新設計表單。

您也應該使用 JavaScript，在使用者輸入資料和提交表單時進行更完善的驗證。使用限制驗證 API (廣受支援)，透過內建瀏覽器 UI 新增自訂驗證，設定焦點並顯示提示。

詳情請參閱「用戶端表單驗證」。

協助使用者避免遺漏必要資料

在輸入強制值時使用 required 屬性。

提交表單時，新式瀏覽器會自動提示並聚焦在缺少資料的 required 欄位，您可以使用 :required 虛擬類別醒目顯示必填欄位。不需要 JavaScript！

在每個必填欄位的標籤加上星號，並在表單開頭加上附註，說明星號的意義。

簡化結帳程序

留意行動商務落差

假設使用者有疲勞預算。如果用完，使用者就會離開。

您需要減少干擾並保持專注，尤其是在行動裝置上。許多網站的行動版流量較高，但電腦版的轉換率較高，這種現象稱為行動商務差距。消費者可能只是偏好在電腦上完成購買，但行動裝置轉換率較低，也可能是因為使用者體驗不佳。您的工作是盡量減少行動裝置上流失的轉換，並盡量提高電腦上的轉換。研究顯示，提供更優質的行動表單體驗，是提升轉換率的大好機會。

最重要的是，如果表單看起來很長、很複雜，而且沒有明確的方向，使用者就更有可能放棄填寫。當使用者使用較小的螢幕、分心或趕時間時，更是如此。盡可能減少要求的資料量。

將訪客結帳設為預設選項

對網路商店來說，減少表單阻力最簡單的方法，就是將訪客結帳設為預設選項。 請勿強制使用者先建立帳戶才能購物。不允許訪客結帳，是消費者放棄購物車的主要原因。

你可以在結帳後提供帳戶註冊選項。此時，您已擁有設定帳戶所需的大部分資料，因此使用者應能快速輕鬆地建立帳戶。

顯示結帳進度

您可以顯示進度，並清楚說明接下來需要執行的操作，讓結帳程序看起來不那麼複雜。以下影片說明英國零售商 johnlewis.com 如何做到這一點。

你必須保持動力！在付款的每個步驟中，使用網頁標題和描述性按鈕值，清楚說明目前需要執行的操作，以及下一個結帳步驟。

在表單輸入內容中使用 enterkeyhint 屬性，設定行動鍵盤的 Enter 鍵標籤。舉例來說，在多頁表單中使用 enterkeyhint="previous" 和 enterkeyhint="next"，在表單的最後一個輸入欄位中使用 enterkeyhint="done"，在搜尋輸入欄位中使用 enterkeyhint="search"。

enterkeyhint 屬性適用於 Android 和 iOS。詳情請參閱 enterkeyhint 說明。

讓使用者在結帳程序中輕鬆來回切換，即使在最後的付款步驟，也能輕鬆調整訂單。顯示完整的訂單詳細資料，而非僅提供有限的摘要。讓使用者在付款頁面輕鬆調整商品數量。結帳時的首要任務是避免中斷轉換流程。

移除干擾元素

移除視覺雜訊和干擾元素 (例如產品促銷活動)，減少潛在的離開點。 許多成功的零售商甚至會從結帳頁面中移除導覽和搜尋功能。

讓旅程保持聚焦。這時不應誘導使用者進行其他操作。

對於回訪者，您可以隱藏他們不需要查看的資料，進一步簡化結帳程序。例如：以純文字 (而非表單) 顯示寄送地址，並允許使用者透過連結變更地址。

簡化姓名和地址輸入程序

只要求提供必要資料

開始編寫姓名和地址表單的程式碼之前，請務必瞭解需要哪些資料。請勿要求不需要的資料！降低表單複雜度最簡單的方法，就是移除不必要的欄位。這也有助於保護客戶隱私，並降低後端資料成本和責任。

使用單一姓名輸入欄位

除非您有充分理由需要分開儲存名字、姓氏、敬稱或其他姓名部分，否則請允許使用者在單一輸入欄位中輸入姓名。使用單一姓名輸入欄位可簡化表單、啟用剪下和貼上功能，並簡化自動填入功能。

除非有充分理由，否則請勿為前置字元或稱謂 (例如女士、博士或爵士) 另外新增輸入欄位。使用者可以視需要輸入名稱。此外，honorific-prefix自動完成功能目前在大多數瀏覽器中都無法運作，因此新增名稱前置字元或稱謂欄位，會破壞大多數使用者的地址表單自動填入體驗。

啟用名稱自動填入功能

使用 name 顯示全名：

<input autocomplete="name" ...>

如果您確實有充分理由拆分姓名，請務必使用適當的自動完成值：

• honorific-prefix
• given-name
• nickname
• additional-name-initial
• additional-name
• family-name
• honorific-suffix

允許國際名稱

建議您驗證輸入的名稱，或限制名稱資料允許使用的字元。不過，您應盡可能不限制字母。如果有人說你的名字「無效」，這很不禮貌！

驗證時，請避免使用僅比對拉丁字元的規則運算式。「僅限拉丁字母」會排除姓名或地址包含非拉丁字母字元的使用者。請改為允許 Unicode 字母比對，並確保後端安全地支援 Unicode 做為輸入和輸出。新式瀏覽器對規則運算式中的 Unicode 支援良好。

<!-- Names with non-Latin characters (such as Françoise or Jörg) are 'invalid'. -->
<input pattern="[\w \-]+" ...>

<!-- Accepts Unicode letters. -->
<input pattern="[\p{L} \-]+" ...>

允許各種地址格式

設計地址表單時，請注意地址格式種類繁多，即使在同一個國家/地區也可能有所不同。請注意，不要對「正常」地址做出假設。(如果您不相信，請參閱英國地址奇聞！)

讓地址表單更靈活

請勿強迫使用者將地址塞進不合適的表單欄位。

舉例來說，請勿要求使用者在不同輸入欄位中輸入門牌號碼和街道名稱，因為許多地址不採用這種格式，而且不完整的資料可能會導致瀏覽器自動填入功能中斷。

請特別留意 required 地址欄位。舉例來說，英國大城市的地址沒有郡，但許多網站仍會強制使用者輸入。

使用兩行彈性地址欄位，就能充分因應各種地址格式。

<input autocomplete="address-line1" id="address-line1" ...>
<input autocomplete="address-line2" id="address-line2" ...>

新增要比對的標籤：

<label for="address-line1">
Address line 1 (or company name)
</label>
<input autocomplete="address-line1" id="address-line1" ...>

<label for="address-line2">
Address line 2 (optional)
</label>
<input autocomplete="address-line2" id="address-line2" ...>

建議使用單一文字區域輸入地址

最靈活的地址選項是提供單一 textarea。

textarea 方法適用於任何地址格式，且非常適合剪下和貼上，但請注意，這可能不符合您的資料需求，且如果使用者先前只使用 address-line1 和 address-line2 表單，可能會錯過自動填入功能。

如果是文字區域，請使用 street-address 做為自動完成值。

以下表單範例示範如何使用單一 textarea 輸入地址：

將地址表單國際化和本地化

地址表單必須根據使用者所在位置，考量國際化和本地化，這點特別重要。

請注意，即使是同一種語言，地址部分的命名和地址格式也會有所不同。

    ZIP code: US
 Postal code: Canada
    Postcode: UK
     Eircode: Ireland
         PIN: India

如果表單不符合地址格式，或使用的字詞不符合預期，可能會令人感到困擾或困惑。

您的網站可能需要針對多個語言代碼自訂地址表單，但使用技術盡可能提高表單彈性 (如上所述) 可能就足夠了。如果您不打算將地址表單本地化，請務必瞭解處理各種地址格式的主要優先事項：

• 避免過度具體地描述地址部分，例如堅持提供街道名稱或門牌號碼。
• 請盡可能避免將欄位設為 required。舉例來說，許多國家/地區的地址沒有郵遞區號，鄉村地址可能沒有街道或道路名稱。
• 使用包容性命名：「國家/地區」而非「國家」；「郵遞區號」而非「郵遞區號」。

保持彈性！上述簡單的地址表單範例可經過調整，在許多語言代碼中「正常」運作。

建議避免使用郵遞區號地址查詢

部分網站會使用服務，根據郵遞區號查詢地址。這對某些用途來說可能很合理，但您應留意潛在缺點。

郵遞區號地址建議功能不適用於所有國家/地區，且在某些區域，郵遞區號可能包含大量潛在地址。

使用者很難從冗長的地址清單中選取地址，尤其是在行動裝置上，如果他們趕時間或感到壓力，就更難選取。讓使用者利用自動填入功能，輕觸或點選一下就能填寫完整地址，不僅更輕鬆，也更不容易出錯。

簡化付款表單

付款表單是結帳流程中最關鍵的部分。付款表單設計不佳是購物車棄單的常見原因。魔鬼藏在細節裡：小小的問題就可能導致使用者放棄購買，在行動裝置上尤其如此。您的工作是設計表單，讓使用者能盡可能輕鬆輸入資料。

協助使用者避免重新輸入付款資料

請務必在付款卡表單中加入適當的 autocomplete 值，包括付款卡號碼、卡片上的姓名、到期日和安全碼：

• cc-number
• cc-name
• cc-exp，或 cc-exp-month 和 cc-exp-year (用於個別欄位)
• cc-csc

這樣一來，瀏覽器就能安全地儲存付款卡詳細資料，並正確輸入表單資料，為使用者提供協助。如果沒有自動填入功能，使用者可能會更傾向以實體方式記錄付款卡詳細資料，或以不安全的方式將付款卡資料儲存在裝置上。

避免使用自訂元素輸入付款卡日期

如果自訂元素設計不當，可能會破壞自動填入功能，導致付款流程中斷，且無法在舊版瀏覽器上運作。如果自動完成功能可提供所有其他付款卡詳細資料，但使用者因自動填入功能無法用於自訂元素，而必須找出實體付款卡來查詢到期日，您可能會失去銷售機會。建議改用標準 HTML 元素，並據此設定樣式。

使用單一輸入欄位填寫付款卡和電話號碼

付款卡和電話號碼請使用單一輸入欄位，不要將號碼拆成多個部分。這可讓使用者更輕鬆地輸入資料、簡化驗證程序，並讓瀏覽器自動填入資料。建議您對其他數字資料 (例如 PIN 碼和銀行代碼) 採取相同做法。

仔細驗證

您應即時驗證資料輸入，並在提交表單前進行驗證。其中一種做法是在付款卡輸入欄位中加入 pattern 屬性。如果使用者嘗試提交含有無效值的付款表單，瀏覽器會顯示警告訊息，並將焦點設在輸入欄位。不需要 JavaScript！

不過，pattern 規則運算式必須足夠靈活，才能處理付款卡號長度範圍：從 14 位數 (或可能更少) 到 20 位數 (或更多)。如要進一步瞭解付款卡號碼結構，請參閱 LDAPwiki。

允許使用者在輸入新的付款卡號時加入空格，因為實體卡片上的卡號就是這樣顯示。這種做法對使用者更友善 (不必告訴他們「做錯了什麼」)，也比較不會中斷轉換流程，而且在處理前移除數字中的空格也很簡單。

在各種裝置、平台、瀏覽器和版本上測試

請務必在使用者最常用的平台上測試地址和付款表單，因為表單元素的功能和外觀可能有所不同，且可視區域大小的差異可能會導致定位問題。BrowserStack 可讓您在各種裝置和瀏覽器上免費測試開放原始碼專案。

導入數據分析和 RUM

在本機測試可用性和效能可能很有幫助，但您需要實際資料，才能正確瞭解使用者如何體驗付款和地址表單。

因此，您需要分析和實際使用者監控功能，也就是實際使用者體驗的資料，例如結帳頁面的載入時間，或付款完成所需的時間：

• 網頁數據分析：每個表單網頁的網頁瀏覽量、跳出率和離開率。
• 互動數據分析：目標漏斗和事件會指出使用者在何處放棄結帳程序，以及與表單互動時採取哪些動作。
• 網站效能：以使用者為中心的指標可指出結帳頁面載入速度是否緩慢，以及原因為何。

網頁分析、互動分析和實際使用者成效評估，在與伺服器記錄、轉換資料和 A/B 測試結合時，會變得特別有價值，可讓您回答折扣碼是否能增加收益，或表單版面配置的變更是否能提高轉換率等問題。

這樣一來，您就能以此為依據，排定工作優先順序、做出調整，並獎勵成功。

持續掌握情況

• 登入表單最佳做法
• 註冊表單最佳做法
• 使用 WebOTP API 驗證網頁上的電話號碼
• 建立出色的表單
• 行動表單設計最佳做法
• 更強大的表單控制項
• 建立無障礙表單
• 使用 Credential Management API 簡化註冊流程
• Frank's Compulsive Guide to Postal Addresses 提供實用連結和詳盡指南，說明 200 多個國家/地區的地址格式。
• Countries Lists 提供一項工具，可下載多種語言和格式的國家/地區代碼和名稱。

相片來源：@rupixen 發表於 Unsplash 網站上。