協助使用者以最簡單快速的方式填妥地址和付款方式,藉此盡量爭取轉換。
設計精美的表單不僅能協助使用者提高轉換率,只要稍微修正,就能大大改變!
以下提供簡單的付款表單範例,展示所有最佳做法:
以下提供簡單的地址表單範例,展示所有最佳做法:
檢查清單
- 使用有意義的 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-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-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 驗證網路上的電話號碼
- 建立出色的表單
- 設計行動版表單的最佳做法
- 更強大的表單控制項
- 建立無障礙表單
- 使用 Credential Management API 簡化註冊流程
- Frank 的郵政地址綜合指南提供實用連結,以及超過 200 個國家/地區的地址格式詳細指引。
- 國家/地區清單提供下載多種語言的國家/地區代碼和名稱。