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

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

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>

您可能會想不必在 <form> 中包裝 <input> 元素，並且只使用 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」。

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

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

充分運用 HTML 屬性

讓使用者輕鬆輸入資料

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

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

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

使用 Autocomplete 提升無障礙性，避免使用者重複輸入資料

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

如果表單欄位有適合的自動完成值，請使用該值。MDN 網路文件提供完整的值清單，並說明如何正確使用這些值。

穩定值

帳單地址

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

請為帳單地址使用適當的自動完成值，就像您為運送地址所做的一樣，這樣使用者就不必重複輸入資料。如果不同部分中的同名輸入內容有不同的值，請在自動完成屬性中加入前置字詞。

<input autocomplete="shipping address-line-1" ...>
...
<input autocomplete="billing address-line-1" ...>

協助使用者輸入正確資料

請避免因客戶「做錯事」而「責罵」他們。相反地，請協助使用者即時解決問題，讓他們更輕鬆快速地完成表單。在結帳流程中，消費者會為了購買產品或服務而付錢給貴公司，你的工作是協助他們，而不是懲罰他們！

您可以新增限制屬性至表單元素，指定可接受的值，包括 min、max 和 pattern。元素的有效性狀態會根據元素值是否有效而自動設定，:valid 和 :invalid CSS 擬似類別也是如此，可用於為含有效或無效值的元素設定樣式。

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

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

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

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

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

您也應使用 JavaScript，在使用者輸入資料和提交表單時，進行更可靠的驗證。使用Constraint Validation API (廣泛支援) 新增自訂驗證，使用內建瀏覽器 UI 設定焦點並顯示提示。

詳情請參閱「使用 JavaScript 進行更複雜的即時驗證」。

協助使用者避免缺少必要資料

在輸入必要值時，請使用 required 屬性。

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

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

簡化結帳流程

請留意行動商務的差距！

假設您的使用者有疲勞預算。使用完畢，使用者就會離開。

您需要減少摩擦點並保持專注，特別是在行動裝置上。許多網站在行動裝置上獲得的流量較多，但在電腦上獲得的轉換較多，這種現象稱為行動商務差距。客戶可能只是偏好在電腦上完成購買交易，但行動版轉換率偏低也是使用者體驗不佳的結果。您的工作是盡量減少行動裝置上的轉換損失，並盡量提高桌機上的轉換。研究顯示，提供更優質的行動表單體驗有極大商機。

最重要的是，使用者更有可能放棄看起來冗長、複雜且沒有方向感的表單。尤其是當使用者使用小螢幕、分心或忙碌時。請盡量少要求資料。

將訪客結帳設為預設值

對於網路商店而言，最簡單的解決方法是將訪客結帳設為預設值，以減少表單摩擦。請勿強制要求使用者在購買前建立帳戶。不允許訪客結帳是購物車放棄的主要原因。

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

顯示結帳進度

您可以透過顯示進度，並清楚說明下一步要採取的行動，讓結帳流程變得簡單易懂。下方影片展示英國零售商 johnlewis.com 如何達成這項目標。

您需要持續保持動力！在付款流程的每個步驟中，請使用頁面標題和說明性按鈕值，清楚說明目前需要執行的操作，以及下一個結帳步驟。

在表單輸入框中使用 enterkeyhint 屬性，即可設定行動鍵盤的 Enter 鍵標籤。舉例來說，在多頁表單中使用 enterkeyhint="previous" 和 enterkeyhint="next"、在表單中使用 enterkeyhint="done" 做為最終輸入內容，以及在搜尋輸入內容中使用 enterkeyhint="search"。

enterkeyhint 屬性在 Android 和 iOS 上支援。詳情請參閱enterkeyhint 說明。

請讓使用者在結帳流程中輕鬆往返，方便調整訂單，即使是在最後付款步驟也一樣。顯示訂單的完整詳細資料，而非僅顯示摘要。讓使用者輕鬆在付款頁面調整商品數量。在結帳時，請避免中斷轉換過程。

移除干擾元素

移除視覺雜訊和干擾元素 (例如產品宣傳內容)，減少潛在的離開點。許多成功的零售商甚至會在結帳時移除導覽和搜尋功能。

讓旅程保持專注。這不是誘使使用者執行其他操作的時機！

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

提供簡單的姓名和地址輸入方式

只要求所需的資料

開始編寫姓名和地址表單的程式碼前，請務必瞭解必要的資料。請勿要求不需要的資料！如要簡化表單，最簡單的方法就是移除不必要的欄位。這對顧客隱私權也有益處，而且還能降低後端資料成本和責任。

使用單一名稱輸入

允許使用者使用單一輸入欄位輸入姓名，除非您有充分理由要分別儲存名字、姓氏、敬語或其他姓名部分。使用單一名稱輸入方式可簡化表單，讓使用者可以剪下並貼上內容，並簡化自動填入功能。

特別注意，除非有充分理由，否則請勿為前置字元或頭銜 (例如 Mrs、Dr 或 Lord) 新增個別輸入欄位。使用者可以視需要輸入自己的名字。此外，honorific-prefix 自動完成功能目前無法在多數瀏覽器中運作，因此新增名稱前置字元或標題欄位，會讓多數使用者的地址表單無法自動填入。

啟用姓名自動填入功能

使用 name 表示全名：

<input autocomplete="name" ...>

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

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

允許國際名稱

您可能需要驗證名稱輸入內容，或限制姓名資料可用的字元。不過，您需要盡可能不受限於使用字母。告訴你名稱無效很失禮！

如要進行驗證，請避免使用只會比對拉丁字母的規則運算式。只使用拉丁字母的排除條件會排除那些姓名或地址含有非拉丁字母字元的使用者。請改為允許 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-line-1" id="address-line1" ...>
<input autocomplete="address-line-2" id="address-line2" ...>

新增標籤以符合下列條件：

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

<label for="address-line-2">
Address line 2 (optional)
</label>
<input autocomplete="address-line-2" 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-month
• cc-exp-year

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

避免使用自訂元素來顯示付款卡日期

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

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

請使用單一輸入方式輸入付款卡和電話號碼，不要將號碼分成多個部分。這樣一來，使用者就能更輕鬆地輸入資料，驗證作業也更簡單，瀏覽器還能自動填入資料。建議您也為其他數值資料 (例如 PIN 碼和銀行代碼) 採取相同做法。

謹慎驗證

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

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

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

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

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

導入數據分析和 RUM

在本機測試可用性和效能雖然有助於瞭解情況，但您仍需要實際資料，才能正確掌握使用者對付款和地址表單的體驗。

為此，您需要使用數據分析和真實使用者監控功能，取得實際使用者體驗的資料，例如結帳頁面載入時間或付款所需時間：

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

當您將網頁分析、互動分析和實際使用者成效評估結果與伺服器記錄、轉換資料和 A/B 測試結合時，這些資料就會特別有用，可協助您回答諸如折扣碼是否能增加收益，或是表單版面配置變更是否能提升轉換率等問題。

這麼一來，您就能有充足的依據，決定要優先處理哪些工作、進行哪些變更，以及如何獎勵成功。

持續掌握情況

• 登入表單最佳做法
• 註冊表單最佳做法
• 使用 WebOTP API 在網路上驗證電話號碼
• 建立出色的表單
• 行動表單設計的最佳做法
• 功能更強大的表單控制項
• 建立無障礙表單
• 使用憑證管理 API 簡化註冊流程
• Frank's Compulsive Guide to Postal Addresses 提供實用連結和詳細指南，協助您瞭解超過 200 個國家/地區的地址格式。
• 國家/地區清單提供工具，可讓您以多種語言和格式下載國家/地區代碼和名稱。

相片來源：@rupixen 在 Unsplash 網站上提供。