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

เพิ่มจํานวน 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> ของตนเอง เช่น หากคุณมี Search และลงชื่อสมัครใช้ในหน้าเดียวกัน ให้ใส่แต่ละรายการใน <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 รายการเดียว

รูปแบบ 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
• สร้างแบบฟอร์มที่ยอดเยี่ยม
• แนวทางปฏิบัติแนะนำสำหรับการออกแบบแบบฟอร์มบนอุปกรณ์เคลื่อนที่
• การควบคุมแบบฟอร์มที่มีประสิทธิภาพมากขึ้น
• การสร้างแบบฟอร์มที่เข้าถึงได้
• ปรับปรุงขั้นตอนการลงชื่อสมัครใช้โดยใช้ Credential Management API
• Frank's Compulsive Guide to Postal Addresses มีลิงก์ที่เป็นประโยชน์และคำแนะนำที่ครอบคลุมเกี่ยวกับรูปแบบที่อยู่ในกว่า 200 ประเทศ
• รายชื่อประเทศมีเครื่องมือสำหรับดาวน์โหลดรหัสและชื่อประเทศในหลายภาษาและหลายรูปแบบ

รูปภาพโดย @rupixen ใน Unsplash