協助使用者盡可能快速輕鬆地填寫地址和付款表單，提高轉換率。
設計良好的表單有助於協助使用者，並提高轉換率。一個小小的修正就能帶來巨大的改變！
以下是簡單付款表單的範例，其中展示了所有最佳做法：
以下是簡易地址表單的範例，可讓您瞭解所有最佳做法：
檢查清單
- 使用有意義的 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-prefixgiven-namenicknameadditional-name-initialadditional-namefamily-namehonorific-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-numbercc-namecc-exp-monthcc-exp-year
這樣一來，瀏覽器就能安全地儲存付款卡詳細資料，並正確輸入表單資料，為使用者提供協助。如果沒有自動完成功能，使用者可能會更有可能保留付款卡詳細資料的實體記錄，或是在裝置上儲存不安全的付款卡資料。
避免使用自訂元素設定付款卡日期
如果設計不當，自訂元素可能會中斷自動填入功能，導致付款流程中斷，且無法在舊版瀏覽器上運作。如果自動完成功能可提供所有其他付款卡詳細資料，但使用者必須找出實體付款卡才能查看到期日，因為自動填入功能無法用於自訂元素，那麼您很可能會失去銷售機會。建議您改用標準 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 個國家/地區的地址格式。
- 國家/地區清單提供一項工具，可讓您下載多種語言的國家/地區代碼和名稱，且採用多種格式。