เพิ่มจำนวน Conversion สูงสุดด้วยการช่วยผู้ใช้ให้กรอกแบบฟอร์มการชำระเงินและที่อยู่ได้อย่างรวดเร็วและง่ายดายที่สุด
แบบฟอร์มที่ออกแบบมาอย่างดีจะช่วยผู้ใช้และเพิ่มอัตรา Conversion การแก้ไขเล็กๆ น้อยๆ เพียงอย่างเดียวอาจสร้างความแตกต่างได้อย่างมาก
ต่อไปนี้เป็นตัวอย่างแบบฟอร์มการชำระเงินแบบง่ายที่แสดงแนวทางปฏิบัติแนะนำทั้งหมด
ต่อไปนี้คือตัวอย่างแบบฟอร์มที่อยู่แบบง่ายที่แสดงแนวทางปฏิบัติแนะนำทั้งหมด
เช็กลิสต์
- ใช้องค์ประกอบ HTML ที่มีความหมาย เช่น
<form>
,<input>
,<label>
และ<button>
- ติดป้ายกำกับช่องในแบบฟอร์มแต่ละช่องด้วย
<label>
- ใช้แอตทริบิวต์องค์ประกอบ HTML เพื่อเข้าถึงฟีเจอร์ในตัวของเบราว์เซอร์ โดยเฉพาะ
type
และautocomplete
ที่มีค่าที่เหมาะสม - หลีกเลี่ยงการใช้
type="number"
สำหรับตัวเลขที่ไม่ได้หมายถึงการเพิ่ม เช่น หมายเลขบัตรสำหรับชำระเงิน ให้ใช้type="text"
และinputmode="numeric"
แทน - หากมีค่าการเติมข้อความอัตโนมัติที่เหมาะสมสำหรับ
input
,select
หรือtextarea
คุณควรใช้ค่าดังกล่าว - เพื่อช่วยเบราว์เซอร์ในการป้อนข้อมูลแบบอัตโนมัติ ให้ระบุค่าที่แน่นอนให้กับแอตทริบิวต์อินพุต
name
และid
ซึ่งจะไม่เปลี่ยนแปลงระหว่างการโหลดหน้าเว็บหรือการใช้งานเว็บไซต์ - ปิดใช้ปุ่มส่งเมื่อมีการแตะหรือคลิก
- ตรวจสอบข้อมูลระหว่างป้อน ไม่ใช่แค่เมื่อส่งแบบฟอร์ม
- กำหนดให้การชำระเงินโดยไม่ลงชื่อเข้าใช้เป็นค่าเริ่มต้น และทำให้การสร้างบัญชีเป็นเรื่องง่ายเมื่อการชำระเงินเสร็จสมบูรณ์
- แสดงความคืบหน้าในกระบวนการชำระเงินเป็นขั้นตอนที่ชัดเจนพร้อมคำกระตุ้นให้ดำเนินการ (Call-To-Action) ที่ชัดเจน
- จำกัดจุดออกที่อาจเกิดขึ้นในการชำระเงินโดยการนําสิ่งรบกวนออก
- แสดงรายละเอียดคำสั่งซื้อทั้งหมดที่จุดชำระเงินและทำการปรับเปลี่ยนคำสั่งซื้อได้อย่างง่ายดาย
- อย่าขอข้อมูลที่ไม่จำเป็นต้องใช้
- ถามชื่อโดยป้อนข้อมูลครั้งเดียว เว้นแต่คุณจะมีเหตุผลที่ดีที่จะไม่ถาม
- ไม่บังคับใช้อักขระละตินเท่านั้นกับชื่อและชื่อผู้ใช้
- รองรับรูปแบบที่อยู่ต่างๆ
- ลองใช้
textarea
เดียวสำหรับที่อยู่ - ใช้การเติมข้อความอัตโนมัติสำหรับที่อยู่สำหรับการเรียกเก็บเงิน
- ปรับให้เป็นสากลและแปลตามความจำเป็น
- โปรดพิจารณาหลีกเลี่ยงการค้นหาที่อยู่รหัสไปรษณีย์
- ใช้ค่าการเติมข้อความอัตโนมัติจากบัตรสำหรับชำระเงินที่เหมาะสม
- ใช้อินพุตเดียวสำหรับหมายเลขบัตรสำหรับชำระเงิน
- หลีกเลี่ยงการใช้องค์ประกอบที่กำหนดเองหากทำให้ประสบการณ์การป้อนข้อความอัตโนมัติแย่ลง
- ทดสอบทั้งในสนามและห้องทดลอง: ข้อมูลวิเคราะห์หน้าเว็บ ข้อมูลวิเคราะห์การโต้ตอบ และการวัดประสิทธิภาพของผู้ใช้จริง
- ทดสอบในเบราว์เซอร์ อุปกรณ์ และแพลตฟอร์มต่างๆ
ใช้ HTML ที่มีความหมาย
ใช้องค์ประกอบและแอตทริบิวต์ที่สร้างมาเพื่องานนี้
<form>
,<input>
,<label>
และ<button>
type
,autocomplete
และinputmode
เครื่องมือเหล่านี้ช่วยให้มีฟังก์ชันของเบราว์เซอร์ในตัว ปรับปรุงการช่วยเหลือพิเศษ และเพิ่มความหมายให้กับมาร์กอัปของคุณ
ใช้องค์ประกอบ HTML ตามที่ต้องการ
ใส่แบบฟอร์มใน <form>
คุณอาจไม่สนใจที่จะห่อองค์ประกอบ <input>
ใน <form>
และจัดการการส่งข้อมูลด้วย JavaScript เพียงอย่างเดียว
อย่าทำ
HTML <form>
ช่วยให้คุณเข้าถึงชุดฟีเจอร์ที่มีประสิทธิภาพซึ่งรวมอยู่ในเบราว์เซอร์สมัยใหม่ทั้งหมด และช่วยให้เว็บไซต์ของคุณเข้าถึงได้โดยใช้โปรแกรมอ่านหน้าจอและอุปกรณ์ช่วยเหลือพิเศษอื่นๆ <form>
ยังช่วยให้สร้างฟังก์ชันพื้นฐานสําหรับเบราว์เซอร์รุ่นเก่าที่รองรับ JavaScript แบบจํากัดได้ง่ายขึ้น รวมถึงเปิดใช้การส่งแบบฟอร์มได้แม้ว่าโค้ดจะมีปัญหา และเพื่อรองรับผู้ใช้จํานวนน้อยที่ปิดใช้ JavaScript จริงๆ
หากคุณมีคอมโพเนนต์หน้าเว็บสําหรับอินพุตของผู้ใช้มากกว่า 1 รายการ ให้ใส่แต่ละรายการไว้ในเอลิเมนต์ <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
หรือองค์ประกอบแบบสุ่มอื่นๆ ที่ทำหน้าที่เป็นปุ่ม องค์ประกอบปุ่มมีลักษณะการทำงานที่เข้าถึงได้ ฟังก์ชันการส่งแบบฟอร์มในตัว และจัดสไตล์ได้ง่าย
ตั้งค่าปุ่มส่งของแบบฟอร์มแต่ละรายการให้บอกถึงสิ่งที่ปุ่มนั้นทํา สําหรับแต่ละขั้นตอนในการชําระเงิน ให้ใช้คำกระตุ้นให้ดำเนินการที่สื่อความหมายซึ่งแสดงความคืบหน้าและทำให้ขั้นตอนถัดไปชัดเจน เช่น ติดป้ายกำกับปุ่มส่งในแบบฟอร์มที่อยู่สำหรับจัดส่งว่าดำเนินการต่อไปยังการชำระเงินแทนต่อไปหรือบันทึก
พิจารณาปิดใช้ปุ่ม "ส่ง" เมื่อผู้ใช้แตะหรือคลิกปุ่มดังกล่าว โดยเฉพาะเมื่อผู้ใช้กำลังชำระเงินหรือสั่งซื้อ ผู้ใช้จํานวนมากคลิกปุ่มซ้ำๆ แม้ว่าปุ่มจะทํางานได้ตามปกติ ซึ่งอาจทำให้การชำระเงินยุ่งเหยิงและเพิ่มภาระให้กับเซิร์ฟเวอร์
ในทางกลับกัน อย่าปิดใช้ปุ่ม "ส่ง" ที่รออินพุตที่สมบูรณ์และถูกต้องจากผู้ใช้ ตัวอย่างเช่น อย่าปิดใช้ปุ่มบันทึกที่อยู่ไว้เฉยๆ เนื่องจากมีข้อมูลขาดหายไปหรือไม่ถูกต้อง ซึ่งไม่ได้ช่วยผู้ใช้แต่อย่างใด เนื่องจากผู้ใช้อาจแตะหรือคลิกปุ่มต่อไปและคิดว่าปุ่มเสีย หากผู้ใช้พยายามส่งแบบฟอร์มที่มีข้อมูลไม่ถูกต้อง ให้อธิบายปัญหาที่พบและวิธีแก้ไข สิ่งนี้มีความสำคัญอย่างยิ่งสำหรับอุปกรณ์เคลื่อนที่ เนื่องจากการป้อนข้อมูลจะยากยิ่งขึ้น และข้อมูลในแบบฟอร์มที่ขาดหายไปหรือไม่ถูกต้องอาจไม่ปรากฏบนหน้าจอของผู้ใช้ในขณะที่ผู้ใช้พยายามส่งแบบฟอร์ม
ใช้แอตทริบิวต์ HTML ให้เกิดประโยชน์สูงสุด
ทําให้ผู้ใช้ป้อนข้อมูลได้ง่าย
ใช้แอตทริบิวต์ type
อินพุตที่เหมาะสมเพื่อระบุแป้นพิมพ์ที่ถูกต้องในอุปกรณ์เคลื่อนที่และเปิดใช้การตรวจสอบพื้นฐานในตัวโดยเบราว์เซอร์
เช่น ใช้ type="email"
สำหรับอีเมลและ type="tel"
สำหรับหมายเลขโทรศัพท์
สำหรับวันที่ ให้พยายามหลีกเลี่ยงการใช้องค์ประกอบ select
ที่กําหนดเอง แท็กเหล่านี้จะขัดขวางประสบการณ์การป้อนข้อความอัตโนมัติหากติดตั้งใช้งานไม่ถูกต้องและไม่ทำงานในเบราว์เซอร์รุ่นเก่า สำหรับตัวเลข เช่น ปีเกิด ให้พิจารณาใช้องค์ประกอบ input
แทน select
เนื่องจากการป้อนตัวเลขด้วยตนเองนั้นง่ายกว่าและมีโอกาสเกิดข้อผิดพลาดน้อยกว่าการเลือกจากรายการแบบเลื่อนลงที่ยาว โดยเฉพาะในอุปกรณ์เคลื่อนที่ ใช้ inputmode="numeric"
เพื่อตรวจสอบแป้นพิมพ์ที่ถูกต้องในอุปกรณ์เคลื่อนที่ รวมถึงเพิ่มการตรวจสอบความถูกต้องและคำแนะนำการจัดรูปแบบด้วยข้อความหรือตัวยึดตำแหน่งเพื่อให้แน่ใจว่าผู้ใช้ป้อนข้อมูลในรูปแบบที่เหมาะสม
ใช้การเติมข้อความอัตโนมัติเพื่อปรับปรุงการช่วยเหลือพิเศษและช่วยให้ผู้ใช้ไม่ต้องป้อนข้อมูลซ้ำ
การใช้ค่า autocomplete
ที่เหมาะสมจะช่วยให้เบราว์เซอร์ช่วยเหลือผู้ใช้ได้โดยจัดเก็บข้อมูลอย่างปลอดภัยและป้อนค่า input
, select
และ textarea
ให้โดยอัตโนมัติ ซึ่งสำคัญอย่างยิ่งบนอุปกรณ์เคลื่อนที่ และสำคัญอย่างยิ่งในการหลีกเลี่ยงอัตราการหยุดกลางคันในการกรอกแบบฟอร์มสูง การเติมข้อความอัตโนมัติยังมีสิทธิประโยชน์ด้านการช่วยเหลือพิเศษหลายอย่าง
คุณควรใช้ค่าการเติมข้อความอัตโนมัติที่เหมาะสมสำหรับช่องแบบฟอร์ม MDN Web Docs มีรายการค่าทั้งหมดและคำอธิบายวิธีใช้อย่างถูกต้อง
ค่าที่คงที่
ที่อยู่สำหรับการเรียกเก็บเงิน
โดยค่าเริ่มต้น ระบบจะตั้งค่าที่อยู่สำหรับการเรียกเก็บเงินให้เหมือนกับที่อยู่สำหรับจัดส่ง ลดความยุ่งเหยิงของภาพโดยส่งลิงก์สำหรับแก้ไขที่อยู่สำหรับการเรียกเก็บเงิน (หรือใช้องค์ประกอบ summary
และ details
) แทนการแสดงที่อยู่สำหรับการเรียกเก็บเงินในแบบฟอร์ม
ใช้ค่าการเติมข้อความอัตโนมัติที่เหมาะสมสำหรับที่อยู่สำหรับการเรียกเก็บเงินเช่นเดียวกับที่อยู่สำหรับจัดส่ง เพื่อให้ผู้ใช้ไม่ต้องป้อนข้อมูลมากกว่า 1 ครั้ง เพิ่มคำนำหน้าเพื่อเติมแอตทริบิวต์ให้สมบูรณ์หากคุณมีค่าที่แตกต่างกันสำหรับอินพุตที่มีชื่อเดียวกันในส่วนต่างๆ
<input autocomplete="shipping address-line-1" ...>
...
<input autocomplete="billing address-line-1" ...>
ช่วยให้ผู้ใช้ป้อนข้อมูลที่ถูกต้อง
พยายามหลีกเลี่ยงการ "ตำหนิ" ลูกค้าเนื่องจาก "ลูกค้าทำสิ่งผิดพลาด" แต่ให้ช่วยผู้ใช้กรอกแบบฟอร์มได้เร็วและง่ายขึ้นด้วยการช่วยแก้ปัญหาที่เกิดขึ้น ลูกค้าพยายามจ่ายเงินค่าผลิตภัณฑ์หรือบริการให้กับบริษัทของคุณผ่านขั้นตอนการชำระเงิน งานของคุณคือช่วยเหลือลูกค้า ไม่ใช่ลงโทษ
คุณเพิ่มแอตทริบิวต์ข้อจำกัดลงในองค์ประกอบแบบฟอร์มเพื่อระบุค่าที่ยอมรับได้ เช่น min
, max
และ pattern
สถานะความถูกต้องขององค์ประกอบจะได้รับการตั้งค่าโดยอัตโนมัติ ขึ้นอยู่กับว่าค่าขององค์ประกอบถูกต้องหรือไม่ เช่น คลาสเทียมของ CSS :valid
และ :invalid
ซึ่งใช้เพื่อจัดรูปแบบองค์ประกอบที่มีค่าถูกต้องหรือไม่ถูกต้อง
ตัวอย่างเช่น HTML ต่อไปนี้ระบุอินพุตสำหรับปีเกิดระหว่างปี 1900 ถึง 2020 การใช้ type="number"
จะจำกัดค่าอินพุตเป็นตัวเลขเท่านั้นภายในช่วงที่ระบุโดย min
และ max
หากคุณพยายามป้อนตัวเลขที่อยู่นอกช่วง ระบบจะตั้งค่าอินพุตให้มีสถานะไม่ถูกต้อง
ตัวอย่างต่อไปนี้ใช้ pattern="[\d ]{10,30}"
เพื่อให้แน่ใจว่าหมายเลขบัตรสำหรับชำระเงินถูกต้อง และอนุญาตให้เว้นวรรคได้
นอกจากนี้ เบราว์เซอร์สมัยใหม่ยังทำการตรวจสอบพื้นฐานสำหรับอินพุตที่มีประเภท email
หรือ url
ด้วย
เมื่อส่งแบบฟอร์ม เบราว์เซอร์จะตั้งค่าโฟกัสในช่องที่มีปัญหาหรือไม่มีค่าที่จำเป็นโดยอัตโนมัติ ไม่ต้องใช้ JavaScript
ตรวจสอบแบบอินไลน์และแสดงความคิดเห็นให้ผู้ใช้ทราบขณะป้อนข้อมูลแทนการแสดงรายการข้อผิดพลาดเมื่อผู้ใช้คลิกปุ่ม "ส่ง" หากต้องการตรวจสอบข้อมูลในเซิร์ฟเวอร์หลังจากส่งแบบฟอร์ม ให้แสดงรายการปัญหาทั้งหมดที่พบและไฮไลต์ฟิลด์แบบฟอร์มทั้งหมดที่มีค่าไม่ถูกต้องอย่างชัดเจน รวมถึงแสดงข้อความในบรรทัดถัดจากฟิลด์ที่มีปัญหาแต่ละรายการเพื่ออธิบายสิ่งที่ต้องแก้ไข ตรวจสอบบันทึกของเซิร์ฟเวอร์และข้อมูลวิเคราะห์เพื่อหาข้อผิดพลาดที่พบได้ทั่วไป คุณอาจต้องออกแบบแบบฟอร์มใหม่
นอกจากนี้ คุณควรใช้ JavaScript เพื่อตรวจสอบความถูกต้องที่มีประสิทธิภาพมากขึ้นขณะที่ผู้ใช้ป้อนข้อมูลและส่งแบบฟอร์ม ใช้ Constraint Validation API (ซึ่งรองรับในวงกว้าง) เพื่อเพิ่มการตรวจสอบที่กำหนดเองโดยใช้ UI ของเบราว์เซอร์ในตัวเพื่อตั้งโฟกัสและแสดงข้อความแจ้ง
ดูข้อมูลเพิ่มเติมได้ในใช้ JavaScript สําหรับการตรวจสอบแบบเรียลไทม์ที่ซับซ้อนมากขึ้น
ช่วยให้ผู้ใช้ไม่ต้องระบุข้อมูลที่จําเป็น
ใช้แอตทริบิวต์ required
ในอินพุตสำหรับค่าที่จำเป็น
เมื่อส่งแบบฟอร์ม เบราว์เซอร์สมัยใหม่จะแสดงข้อความแจ้งและตั้งค่าโฟกัสในช่อง required
ที่ขาดข้อมูลโดยอัตโนมัติ และคุณใช้คลาสจำลอง :required
เพื่อไฮไลต์ช่องที่ต้องกรอกได้ ไม่ต้อง JavaScript อีกต่อไป
เพิ่มเครื่องหมายดอกจันลงในป้ายกำกับของช่องที่ต้องกรอกทุกช่อง และเพิ่มหมายเหตุไว้ที่ตอนต้นของแบบฟอร์มเพื่ออธิบายความหมายของเครื่องหมายดอกจัน
ลดความซับซ้อนในการชำระเงิน
ระวังช่องว่างในการค้าในอุปกรณ์เคลื่อนที่
ลองจินตนาการว่าผู้ใช้มีงบประมาณความเหนื่อยล้า หากใช้โฆษณามากเกินไป ผู้ใช้จะเลิกใช้งาน
คุณต้องลดอุปสรรคและรักษาโฟกัสไว้ โดยเฉพาะบนอุปกรณ์เคลื่อนที่ เว็บไซต์จำนวนมากได้รับการเข้าชมบนอุปกรณ์เคลื่อนที่มากกว่า แต่ได้รับ Conversion เพิ่มขึ้นบนเดสก์ท็อป ซึ่งนับเป็นปรากฏการณ์ที่เรียกว่าช่องว่างในการค้าบนอุปกรณ์เคลื่อนที่ ลูกค้าอาจต้องการทําการซื้อบนเดสก์ท็อปให้เสร็จสมบูรณ์ แต่อัตรา Conversion บนอุปกรณ์เคลื่อนที่ที่ต่ำลงก็อาจเกิดจากประสบการณ์การใช้งานที่ไม่ดีด้วย หน้าที่ของคุณคือลด Conversion ที่สูญเสียไปในอุปกรณ์เคลื่อนที่ และเพิ่ม Conversion ในเดสก์ท็อป การวิจัยแสดงให้เห็นว่ามีโอกาสมากมายในการสร้างประสบการณ์การใช้งานแบบฟอร์มบนอุปกรณ์เคลื่อนที่ที่ดีขึ้น
โดยส่วนใหญ่แล้ว ผู้ใช้มักจะออกจากฟอร์มที่ดูยาว ซับซ้อน และไร้ทิศทาง โดยเฉพาะอย่างยิ่งเมื่อผู้ใช้ใช้หน้าจอขนาดเล็ก เสียสมาธิ หรือรีบ ขอข้อมูลให้น้อยที่สุด
ตั้งค่าการชำระเงินโดยไม่ลงชื่อเข้าใช้เป็นค่าเริ่มต้น
สําหรับร้านค้าออนไลน์ วิธีที่ง่ายที่สุดในการลดความยุ่งยากของแบบฟอร์มคือการทําให้การชำระเงินโดยไม่ลงชื่อเข้าใช้เป็นค่าเริ่มต้น อย่าบังคับให้ผู้ใช้สร้างบัญชีก่อนทำการซื้อ การไม่อนุญาตให้ชำระเงินโดยไม่ลงชื่อเข้าใช้เป็นสาเหตุหลักที่ทำให้ลูกค้าออกจากรถเข็นช็อปปิ้ง
คุณสามารถเสนอการลงชื่อสมัครใช้บัญชีหลังการชำระเงิน เมื่อถึงตอนนั้น คุณมีข้อมูลส่วนใหญ่ที่ต้องใช้ในการตั้งค่าบัญชีแล้ว ดังนั้นการสร้างบัญชีก็ควรทำได้อย่างรวดเร็วและง่ายดายสำหรับผู้ใช้
แสดงความคืบหน้าในการชำระเงิน
คุณทำให้กระบวนการชำระเงินซับซ้อนน้อยลงได้โดยการแสดงความคืบหน้าและอธิบายสิ่งที่ต้องทำต่อไปอย่างชัดเจน วิดีโอด้านล่างแสดงวิธีที่ผู้ค้าปลีกในสหราชอาณาจักรอย่าง johnlewis.com บรรลุเป้าหมายนี้
คุณต้องรักษากระแสความนิยมไว้ สำหรับแต่ละขั้นตอนการชำระเงิน ให้ใช้ส่วนหัวของหน้าและค่าปุ่มที่สื่อความหมายซึ่งระบุสิ่งที่ต้องทำในตอนนี้และขั้นตอนการชำระเงินถัดไปอย่างชัดเจน
ใช้แอตทริบิวต์ enterkeyhint
ในอินพุตของฟอร์มเพื่อตั้งค่าป้ายกำกับแป้น Enter บนแป้นพิมพ์อุปกรณ์เคลื่อนที่ เช่น ใช้ enterkeyhint="previous"
และ enterkeyhint="next"
ในแบบฟอร์มแบบหลายหน้า ใช้ enterkeyhint="done"
สำหรับอินพุตสุดท้ายในแบบฟอร์ม และใช้ enterkeyhint="search"
สำหรับอินพุตการค้นหา
แอตทริบิวต์ enterkeyhint
รองรับใน Android และ iOS
ดูข้อมูลเพิ่มเติมได้จากคำอธิบายเกี่ยวกับแอตทริบิวต์ enterkeyhint
ช่วยให้ผู้ใช้กลับไปกลับมาภายในกระบวนการชำระเงินได้อย่างง่ายดาย พร้อมปรับเปลี่ยนลำดับได้อย่างง่ายดาย แม้ว่าผู้ใช้จะอยู่ในขั้นตอนการชำระเงินสุดท้ายแล้วก็ตาม แสดงรายละเอียดคำสั่งซื้อทั้งหมด ไม่ใช่แค่ข้อมูลสรุปแบบจำกัด ช่วยให้ผู้ใช้ปรับจำนวนสินค้าจากหน้าชำระเงินได้อย่างง่ายดาย สิ่งสำคัญที่ต้องทำเมื่อชำระเงินคือการหลีกเลี่ยงการขัดจังหวะความคืบหน้าในการได้รับ Conversion
นำสิ่งรบกวนออก
จำกัดจุดออกที่อาจเกิดขึ้นโดยการนําสิ่งรบกวนสายตาและสิ่งรบกวนอื่นๆ ออก เช่น การโปรโมตผลิตภัณฑ์ ผู้ค้าปลีกที่ประสบความสำเร็จจำนวนมากยังนำการนําทางและการค้นหาออกจากจุดชำระเงินด้วย
มุ่งเน้นที่เส้นทาง ช่วงเวลานี้ไม่ใช่เวลาที่ควรล่อลวงให้ผู้ใช้ทำอย่างอื่น
สำหรับผู้ใช้ที่กลับมา คุณสามารถทำให้ขั้นตอนการชำระเงินง่ายขึ้นได้ด้วยการซ่อนข้อมูลที่ผู้ใช้ไม่ต้องการเห็น เช่น แสดงที่อยู่สำหรับจัดส่งเป็นข้อความธรรมดา (ไม่ใช่ในแบบฟอร์ม) และอนุญาตให้ผู้ใช้เปลี่ยนที่อยู่ดังกล่าวผ่านลิงก์
ทำให้การป้อนชื่อและที่อยู่เป็นเรื่องง่าย
ขอเฉพาะข้อมูลที่ต้องการ
ก่อนเริ่มเขียนโค้ดแบบฟอร์มชื่อและที่อยู่ โปรดตรวจสอบว่าคุณเข้าใจว่าจำเป็นต้องใช้ข้อมูลใดบ้าง อย่าขอข้อมูลที่ไม่จำเป็นต้องใช้ วิธีที่ง่ายที่สุดในลดความซับซ้อนของแบบฟอร์มคือการนําช่องที่ไม่จําเป็นออก ซึ่งก็ส่งผลดีต่อความเป็นส่วนตัวของลูกค้าและช่วยลดค่าใช้จ่ายและความรับผิดด้านข้อมูลแบ็กเอนด์ได้
ใช้การป้อนชื่อเดียว
อนุญาตให้ผู้ใช้ป้อนชื่อโดยใช้อินพุตเดียว เว้นแต่คุณจะมีเหตุผลอันสมควรในการเก็บชื่อจริง นามสกุล คำนำหน้า หรือส่วนอื่นๆ ของชื่อแยกกัน การใช้อินพุตชื่อเดียวจะทำให้แบบฟอร์มมีความซับซ้อนน้อยลง ผู้ใช้สามารถตัดและวาง และทำให้ป้อนข้อความอัตโนมัติได้ง่ายขึ้น
โดยเฉพาะอย่างยิ่ง อย่าเพิ่มอินพุตแยกต่างหากสำหรับคำนำหน้าหรือคำนำหน้า (เช่น คุณ คุณนาย ดร. หรือลอร์ด) เว้นแต่คุณจะมีเหตุผลอันสมควร ผู้ใช้สามารถพิมพ์ชื่อลงไปได้ หากต้องการ นอกจากนี้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
ฟิลด์ ตัวอย่างเช่น ที่อยู่ในเมืองใหญ่ในสหราชอาณาจักรไม่มีเขต แต่เว็บไซต์หลายแห่งยังคงบังคับให้ผู้ใช้ป้อนเขต
การใช้บรรทัดที่อยู่ที่ยืดหยุ่น 2 บรรทัดสามารถทำงานได้ดีกับที่อยู่หลายรูปแบบ
<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
สำหรับ textarea ให้ใช้ 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
อนุญาตให้ผู้ใช้ใส่เว้นวรรคเมื่อป้อนหมายเลขบัตรสำหรับชำระเงินใหม่ เนื่องจากเป็นวิธีแสดงหมายเลขบนบัตรจริง วิธีนี้สะดวกสําหรับผู้ใช้มากกว่า (คุณไม่จําเป็นต้องบอกผู้ใช้ว่า "ผู้ใช้ทําผิด") มีแนวโน้มที่จะไม่ขัดจังหวะขั้นตอน Conversion และนําการเว้นวรรคในตัวเลขออกก่อนประมวลผลได้ง่ายๆ
ทดสอบในอุปกรณ์ แพลตฟอร์ม เบราว์เซอร์ และเวอร์ชันต่างๆ
คุณควรทดสอบแบบฟอร์มที่อยู่และแบบฟอร์มการชำระเงินในแพลตฟอร์มที่ผู้ใช้ของคุณใช้บ่อยที่สุด เนื่องจากฟังก์ชันการทำงานและลักษณะที่ปรากฏขององค์ประกอบแบบฟอร์มอาจแตกต่างกันไป และความแตกต่างของขนาดวิวพอร์ตอาจทําให้การวางตําแหน่งเกิดปัญหา BrowserStack ช่วยให้ทดสอบโปรเจ็กต์โอเพนซอร์สได้ฟรีในอุปกรณ์และเบราว์เซอร์ที่หลากหลาย
ใช้ Analytics และ RUM
การทดสอบความสามารถในการใช้งานและประสิทธิภาพในเครื่องอาจมีประโยชน์ แต่คุณต้องใช้ข้อมูลจริงเพื่อทําความเข้าใจประสบการณ์ของผู้ใช้เกี่ยวกับแบบฟอร์มการชําระเงินและที่อยู่อย่างถูกต้อง
ซึ่งคุณต้องใช้ข้อมูลวิเคราะห์และการตรวจสอบผู้ใช้จริง ซึ่งเป็นข้อมูลเกี่ยวกับประสบการณ์ของผู้ใช้จริง เช่น เวลาที่หน้าชำระเงินใช้เวลาโหลดหรือเวลาที่การชำระเงินเสร็จสมบูรณ์
- ข้อมูลวิเคราะห์หน้าเว็บ: การดูหน้าเว็บ อัตราตีกลับ และหน้าเว็บที่ออกสําหรับทุกหน้าที่มีแบบฟอร์ม
- การวิเคราะห์การโต้ตอบ: Funnel เป้าหมายและเหตุการณ์จะระบุตําแหน่งที่ผู้ใช้ออกจากขั้นตอนการชำระเงิน และการดำเนินการที่ผู้ใช้ทําเมื่อโต้ตอบกับแบบฟอร์ม
- ประสิทธิภาพของเว็บไซต์: เมตริกที่มุ่งเน้นผู้ใช้เป็นหลักจะบอกได้ว่าหน้าชำระเงินโหลดช้าหรือไม่ และหากเป็นเช่นนั้น สาเหตุคืออะไร
การวิเคราะห์หน้าเว็บ การวิเคราะห์การโต้ตอบ และการวัดประสิทธิภาพของผู้ใช้จริงจะมีประโยชน์อย่างยิ่งเมื่อรวมกับบันทึกของเซิร์ฟเวอร์ ข้อมูล Conversion และการทดสอบ A/B ซึ่งจะช่วยให้คุณตอบคําถามต่างๆ ได้ เช่น รหัสส่วนลดเพิ่มรายได้หรือไม่ หรือการเปลี่ยนแปลงเลย์เอาต์แบบฟอร์มช่วยเพิ่ม Conversion หรือไม่
ซึ่งจะช่วยให้คุณมีพื้นฐานที่มั่นคงในการให้ความสําคัญกับความพยายาม เปลี่ยนแปลง และตอบแทนความสําเร็จ
เรียนรู้ต่อไป
- แนวทางปฏิบัติแนะนำสำหรับแบบฟอร์มการลงชื่อเข้าใช้
- แนวทางปฏิบัติแนะนำสำหรับแบบฟอร์มการลงชื่อสมัครใช้
- ยืนยันหมายเลขโทรศัพท์บนเว็บด้วย WebOTP API
- สร้างแบบฟอร์มที่ยอดเยี่ยม
- แนวทางปฏิบัติแนะนำสำหรับการออกแบบแบบฟอร์มบนอุปกรณ์เคลื่อนที่
- การควบคุมแบบฟอร์มที่มีประสิทธิภาพมากขึ้น
- การสร้างแบบฟอร์มที่เข้าถึงได้
- การปรับปรุงขั้นตอนการลงชื่อสมัครใช้โดยใช้ API การจัดการข้อมูลเข้าสู่ระบบ
- Frank's Compulsive Guide to Postal Addresses มีลิงก์ที่เป็นประโยชน์และคำแนะนำที่ครอบคลุมเกี่ยวกับรูปแบบที่อยู่ในกว่า 200 ประเทศ
- รายชื่อประเทศมีเครื่องมือสำหรับดาวน์โหลดรหัสและชื่อประเทศในหลายภาษาและหลายรูปแบบ