แนวทางปฏิบัติแนะนำเกี่ยวกับแบบฟอร์มการชำระเงินและที่อยู่

เพิ่มจำนวน Conversion สูงสุดด้วยการช่วยผู้ใช้ให้กรอกแบบฟอร์มการชำระเงินและที่อยู่ได้อย่างรวดเร็วและง่ายดายที่สุด

Sam Dutton

แบบฟอร์มที่ออกแบบมาอย่างดีจะช่วยผู้ใช้และเพิ่มอัตรา 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 ประเทศ
• รายชื่อประเทศมีเครื่องมือสำหรับดาวน์โหลดรหัสและชื่อประเทศในหลายภาษาและหลายรูปแบบ

รูปภาพโดย @rupixen จาก Unsplash