協助使用者以最簡單快速的方式填妥地址和付款方式，藉此盡量爭取轉換。
設計精美的表單不僅能協助使用者提高轉換率，只要稍微修正，就能大大改變！
以下提供簡單的付款表單範例，展示所有最佳做法：
以下提供簡單的地址表單範例，展示所有最佳做法：
檢查清單
- 使用有意義的 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" …>
針對單一輸入使用單一標籤：請不要嘗試只用一個標籤為多個輸入項目加上標籤。這項功能最適合瀏覽器，且最適合螢幕閱讀器。輕觸或點選標籤，即可將焦點移至相關聯的輸入項目，並在標籤或標籤的 input 成為焦點時，朗讀標籤文字。
讓按鈕實用
請將 <button> 用於按鈕！您也可以使用 <input type="submit">，但不要使用 div 或其他隨機元素做為按鈕。按鈕元素提供易於存取的行為、內建的表單提交功能，而且可輕鬆設定樣式。
為每個表單提交按鈕指定相應的用途。針對每個使用者結帳步驟，請盡量使用描述性的行動號召文字，表明目前進度，並明確指出後續步驟。舉例來說，將寄送地址表單上的提交按鈕加上「繼續付款」標籤，而不要使用「繼續」或「儲存」標籤。
建議在使用者輕觸或點選提交按鈕後停用該按鈕，特別是使用者付款或下單時。許多使用者會重複點選按鈕，即使按鈕運作正常也無妨。 這可能會妨礙結帳，並增加伺服器負載。
另一方面，請勿在使用者輸入完成且有效的使用者輸入內容時，停用提交按鈕。例如，請勿因為缺少項目或內容無效，才讓「Save Address」按鈕停用。但這對於使用者沒有幫助；他們可能會繼續輕觸或按一下按鈕，並假設按鈕損壞。 如果使用者嘗試提交的表單含有無效資料，請說明問題和解決方法。這點對於行動裝置尤其重要，因為行動裝置難以輸入資料，使用者嘗試提交表單時，畫面上可能不會顯示資料輸入或無效的表單資料。
充分運用 HTML 屬性
讓使用者輕鬆輸入資料
使用適當的輸入 type 屬性，在行動裝置上提供正確的鍵盤，並在瀏覽器中啟用基本內建驗證。
例如，使用 type="email" 做為電子郵件地址，使用 type="tel" 代表電話號碼。
針對日期，請避免使用自訂 select 元素。如未正確實作，且無法在舊版瀏覽器中運作，這類功能會破壞自動填入體驗。以出生年份等數字來說，建議您使用 input 元素而非 select，因為比起從長下拉式清單選取數字，手動輸入數字較為容易，也較不容易出錯。請使用 inputmode="numeric" 確保行動裝置上的鍵盤正確，並加入含有文字或預留位置的驗證和格式提示，確保使用者以適當的格式輸入資料。
使用自動完成功能提升無障礙體驗，並協助使用者不必重新輸入資料
使用適當的 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 屬性，設定行動裝置鍵盤的輸入鍵標籤。舉例來說，您可以在多頁表單中使用 enterkeyhint="previous" 和 enterkeyhint="next"，使用 enterkeyhint="done" 做為表單的最終輸入內容，使用 enterkeyhint="search" 則用於搜尋輸入內容。
Android 和 iOS 支援 enterkeyhint 屬性。詳情請參閱 Enterkeyhint 說明。
使用者能輕鬆在結帳程序中來回切換，即使在最後付款步驟中仍能輕鬆調整訂單。顯示訂單的完整詳細資料，而不只是摘要。讓使用者能夠在付款頁面上輕鬆調整商品數量。結帳流程的第一要務，是避免干擾轉換前的進度。
去除乾擾元素
消除產品促銷等視覺幹擾元素，減少潛在的離開點。許多成功的零售商甚至移除了結帳選項和搜尋功能。
將重點放在整個歷程。這並不是誘使使用者採取其他行動的好時機！
對於回訪者來說，您可以隱藏不需要查看的資料，進一步簡化結帳流程。例如：以純文字 (而非表單) 顯示寄送地址，並允許使用者透過連結變更地址。
方便使用者輸入姓名和地址
只要求提供所需資料
在開始編寫姓名和地址表單前，請務必瞭解需要填寫哪些資料。 不要索取不需要的資料！如要降低表單複雜度，最簡單的方法就是移除不必要的欄位。這也有助於客戶隱私保護，並降低後端資料成本和責任。
使用單一名稱
除非您有充分的理由，分別儲存名字、姓氏、榮譽或其他名稱部分，否則允許使用者以單一輸入內容輸入自己的名稱。使用單一名稱輸入可簡化表單的複雜作業，啟用剪下和貼上功能，並讓自動填入功能變得更加簡單。
尤其是，除非有充分理由，否則請不要個別為前置字串或標題加入不同的輸入內容 (例如：Mrs、Dr 或 Lord)。使用者可以視需要以自己的名稱輸入文字。此外，大多數瀏覽器都不支援 honorific-prefix 自動完成功能，因此，如果新增名稱前置字串或標題的欄位，多數使用者就無法在地址表單中自動填入服務。
啟用姓名自動填入功能
使用 name 做為全名：
<input autocomplete="name" ...>
如果有充分理由拆分名稱部分，請務必使用適當的自動完成值：
honorific-prefixgiven-namenicknameadditional-name-initialadditional-namefamily-namehonorific-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-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 的郵政地址綜合指南提供實用連結，以及超過 200 個國家/地區的地址格式詳細指引。
- 國家/地區清單提供下載多種語言的國家/地區代碼和名稱。