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

เพิ่มจำนวน 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 เพียงอย่างเดียว

อย่าทำเช่นนั้น

<form> HTML ช่วยให้คุณเข้าถึงชุดฟีเจอร์ในตัวที่มีประสิทธิภาพในเบราว์เซอร์ที่ทันสมัยทั้งหมด และช่วยให้โปรแกรมอ่านหน้าจอและอุปกรณ์ช่วยเหลืออื่นๆ เข้าถึงเว็บไซต์ของคุณได้ นอกจากนี้ <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 หรือองค์ประกอบอื่นๆ ที่สุ่มขึ้นมาเพื่อทำหน้าที่เป็นปุ่ม องค์ประกอบปุ่มมีลักษณะการทำงานที่เข้าถึงได้ ฟังก์ชันการส่งแบบฟอร์มในตัว และจัดรูปแบบได้ง่าย

กำหนดค่าให้กับปุ่มส่งแบบฟอร์มแต่ละปุ่มเพื่อระบุว่าปุ่มนั้นทำอะไร สำหรับแต่ละขั้นตอนในการชำระเงิน ให้ใช้คำกระตุ้นให้ดำเนินการที่สื่อความหมายซึ่งแสดงความคืบหน้าและทำให้ขั้นตอนถัดไปชัดเจน เช่น ติดป้ายกำกับปุ่มส่งในแบบฟอร์มที่อยู่สำหรับจัดส่งว่าดำเนินการชำระเงิน แทนที่จะเป็นดำเนินการต่อหรือบันทึก

พิจารณาปิดใช้ปุ่มส่งเมื่อผู้ใช้แตะหรือคลิกปุ่มดังกล่าว โดยเฉพาะเมื่อผู้ใช้กำลังชำระเงินหรือสั่งซื้อ ผู้ใช้หลายคนคลิกปุ่มซ้ำๆ แม้ว่าปุ่มจะทำงานได้ดีก็ตาม ซึ่งอาจทำให้การชำระเงินเกิดข้อผิดพลาดและเพิ่มภาระให้กับเซิร์ฟเวอร์

const form = document.querySelector('form');
const submitButton = form.querySelector('button[type="submit"]');

form.addEventListener('submit', () => {
  submitButton.disabled = true;
  submitButton.textContent = 'Placing order…';
});

ในทางกลับกัน อย่าปิดใช้ปุ่มส่งเพื่อรอข้อมูลที่ครบถ้วนและถูกต้องจากผู้ใช้ ตัวอย่างเช่น อย่าปล่อยให้ปุ่มบันทึกที่อยู่ปิดใช้อยู่เพียงเพราะมีข้อมูลขาดหายไปหรือไม่ถูกต้อง ซึ่งไม่เป็นประโยชน์ต่อผู้ใช้ เนื่องจากผู้ใช้อาจแตะหรือคลิกปุ่มต่อไปและคิดว่าปุ่มเสีย แต่หากผู้ใช้พยายามส่งแบบฟอร์มที่มีข้อมูลไม่ถูกต้อง ให้อธิบายสิ่งที่ผิดพลาดและสิ่งที่ต้องทำเพื่อแก้ไข ซึ่งสำคัญอย่างยิ่งบนอุปกรณ์เคลื่อนที่ซึ่งการป้อนข้อมูลทำได้ยากกว่า และข้อมูลแบบฟอร์มที่ขาดหายไปหรือไม่ถูกต้องอาจไม่ปรากฏบนหน้าจอของผู้ใช้เมื่อพยายามส่งแบบฟอร์ม

ใช้ประโยชน์จากแอตทริบิวต์ HTML ให้มากที่สุด

ช่วยให้ผู้ใช้ป้อนข้อมูลได้ง่าย

ใช้แอตทริบิวต์ type ของอินพุตที่เหมาะสมเพื่อแสดงแป้นพิมพ์ที่ถูกต้องบนอุปกรณ์เคลื่อนที่ และเปิดใช้การตรวจสอบพื้นฐานในตัวโดยเบราว์เซอร์

เช่น ใช้ type="email" สำหรับอีเมล และ type="tel" สำหรับหมายเลขโทรศัพท์

สำหรับวันที่ ให้พยายามหลีกเลี่ยงการใช้องค์ประกอบ select ที่กำหนดเอง ซึ่งจะทำให้ประสบการณ์การป้อนข้อความอัตโนมัติเสียหายหากไม่ได้ติดตั้งใช้งานอย่างถูกต้อง และจะไม่ทำงานในเบราว์เซอร์รุ่นเก่า สำหรับตัวเลข เช่น ปีเกิด ให้พิจารณาใช้องค์ประกอบ input แทน select เนื่องจากการป้อนตัวเลขด้วยตนเองอาจง่ายกว่าและมีแนวโน้มที่จะเกิดข้อผิดพลาดน้อยกว่าการเลือกจากรายการแบบเลื่อนลงที่ยาว โดยเฉพาะในอุปกรณ์เคลื่อนที่ ใช้ inputmode="numeric" เพื่อให้แน่ใจว่าแป้นพิมพ์ที่ถูกต้องบนอุปกรณ์เคลื่อนที่ และเพิ่มคำแนะนำในการตรวจสอบความถูกต้องและรูปแบบด้วยข้อความหรือตัวยึดตำแหน่งเพื่อให้แน่ใจว่าผู้ใช้ป้อนข้อมูลในรูปแบบที่เหมาะสม

ใช้การเติมข้อความอัตโนมัติเพื่อปรับปรุงการช่วยเหลือพิเศษและช่วยให้ผู้ใช้ไม่ต้องป้อนข้อมูลซ้ำ

การใช้ค่า autocomplete ที่เหมาะสมจะช่วยให้เบราว์เซอร์ช่วยเหลือผู้ใช้ได้ด้วยการจัดเก็บข้อมูลอย่างปลอดภัยและป้อนค่า input, select และ textarea โดยอัตโนมัติ ซึ่งสำคัญอย่างยิ่งบนอุปกรณ์เคลื่อนที่ และจำเป็นต่อการหลีกเลี่ยงอัตราการหยุดกรอกแบบฟอร์มกลางคันที่สูง นอกจากนี้ การเติมข้อความอัตโนมัติยังมีประโยชน์ด้านการช่วยเหลือพิเศษหลายประการ

หากมีค่าการเติมข้อความอัตโนมัติที่เหมาะสมสำหรับช่องแบบฟอร์ม คุณควรใช้ค่านั้น เอกสารประกอบเกี่ยวกับเว็บของ MDN มีรายการค่าและคำอธิบายทั้งหมดเกี่ยวกับวิธีใช้ค่าเหล่านั้นอย่างถูกต้อง

ค่าที่เสถียร

ที่อยู่สำหรับการเรียกเก็บเงิน

โดยค่าเริ่มต้น ให้ตั้งค่าที่อยู่สำหรับการเรียกเก็บเงินให้เหมือนกับที่อยู่สำหรับจัดส่ง ลดความยุ่งเหยิงของภาพโดยระบุลิงก์เพื่อแก้ไขที่อยู่สำหรับการเรียกเก็บเงิน (หรือใช้องค์ประกอบ summary และ details) แทนการแสดงที่อยู่สำหรับการเรียกเก็บเงินในแบบฟอร์ม

ใช้ค่าการเติมข้อความอัตโนมัติที่เหมาะสมสำหรับที่อยู่สำหรับการเรียกเก็บเงิน เช่นเดียวกับที่ใช้สำหรับที่อยู่สำหรับจัดส่ง เพื่อให้ผู้ใช้ไม่ต้องป้อนข้อมูลมากกว่า 1 ครั้ง เพิ่มคำนำหน้าให้กับแอตทริบิวต์การเติมข้อความอัตโนมัติหากคุณมีค่าที่แตกต่างกันสำหรับอินพุตที่มีชื่อเดียวกันในส่วนต่างๆ

<input autocomplete="shipping address-line1" ...>
<!-- Other fields omitted. -->
<input autocomplete="billing address-line1" ...>

ช่วยให้ผู้ใช้ป้อนข้อมูลที่ถูกต้อง

พยายามหลีกเลี่ยงการ "ตำหนิ" ลูกค้าเนื่องจาก "ทำสิ่งผิดพลาด" แต่ให้ช่วยผู้ใช้กรอกแบบฟอร์มได้เร็วและง่ายขึ้นโดยช่วยแก้ไขปัญหาที่เกิดขึ้น ในขั้นตอนการชำระเงิน ลูกค้าพยายามจ่ายเงินให้บริษัทของคุณเพื่อซื้อผลิตภัณฑ์หรือบริการ หน้าที่ของคุณคือการช่วยเหลือ ไม่ใช่การลงโทษ

คุณสามารถเพิ่มแอตทริบิวต์ข้อจำกัดลงในองค์ประกอบของแบบฟอร์มเพื่อระบุค่าที่ยอมรับได้ ซึ่งรวมถึง 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 ของเบราว์เซอร์ในตัวเพื่อตั้งค่าโฟกัสและแสดงข้อความแจ้ง

ดูข้อมูลเพิ่มเติมได้ในการตรวจสอบความถูกต้องของแบบฟอร์มฝั่งไคลเอ็นต์

ช่วยผู้ใช้หลีกเลี่ยงการไม่มีข้อมูลที่จำเป็น

ใช้แอตทริบิวต์ 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-line1" id="address-line1" ...>
<input autocomplete="address-line2" id="address-line2" ...>

เพิ่มป้ายกำกับให้ตรงกับ:

<label for="address-line1">
Address line 1 (or company name)
</label>
<input autocomplete="address-line1" id="address-line1" ...>

<label for="address-line2">
Address line 2 (optional)
</label>
<input autocomplete="address-line2" 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 เมื่อเป็นไปได้ ตัวอย่างเช่น ที่อยู่ในหลายประเทศไม่มีรหัสไปรษณีย์ และที่อยู่ในชนบทอาจไม่มีชื่อถนนหรือชื่อซอย
• ใช้การตั้งชื่อที่ครอบคลุม เช่น "ประเทศ/ภูมิภาค" ไม่ใช่ "ประเทศ" และ "รหัสไปรษณีย์" ไม่ใช่ "รหัสไปรษณีย์ (ZIP)"

ยืดหยุ่นเข้าไว้ ตัวอย่างแบบฟอร์มที่อยู่แบบง่ายด้านบนสามารถปรับให้ทำงานได้ "ดีพอ" สำหรับหลายภาษา

พิจารณาหลีกเลี่ยงการค้นหาที่อยู่ด้วยรหัสไปรษณีย์

บางเว็บไซต์ใช้บริการเพื่อค้นหาที่อยู่ตามรหัสไปรษณีย์ ซึ่งอาจเป็นเรื่องที่สมเหตุสมผลสำหรับกรณีการใช้งานบางกรณี แต่คุณควรตระหนักถึงข้อเสียที่อาจเกิดขึ้น

คำแนะนำที่อยู่รหัสไปรษณีย์ใช้ไม่ได้กับทุกประเทศ และในบางภูมิภาค รหัสไปรษณีย์อาจรวมที่อยู่ที่เป็นไปได้จำนวนมาก

ผู้ใช้เลือกที่อยู่จากรายการยาวๆ ได้ยาก โดยเฉพาะในอุปกรณ์เคลื่อนที่หากผู้ใช้กำลังรีบหรือเครียด การอนุญาตให้ผู้ใช้ใช้ประโยชน์จากการป้อนข้อความอัตโนมัติและป้อนที่อยู่ทั้งหมดด้วยการแตะหรือคลิกเพียงครั้งเดียวจะช่วยให้ผู้ใช้ป้อนข้อมูลได้ง่ายขึ้นและมีข้อผิดพลาดน้อยลง

ลดความซับซ้อนของแบบฟอร์มการชำระเงิน

แบบฟอร์มการชำระเงินเป็นส่วนที่สำคัญที่สุดในขั้นตอนการชำระเงิน การออกแบบแบบฟอร์มการชำระเงินที่ไม่ดีเป็นสาเหตุที่พบบ่อยของการละทิ้งรถเข็นช็อปปิ้งกลางคัน รายละเอียดเล็กๆ น้อยๆ ก็สำคัญ: ข้อบกพร่องเล็กๆ น้อยๆ อาจทำให้ผู้ใช้เลิกซื้อได้ โดยเฉพาะในอุปกรณ์เคลื่อนที่ งานของคุณคือการออกแบบแบบฟอร์มเพื่อให้ผู้ใช้ป้อนข้อมูลได้ง่ายที่สุด

ช่วยให้ผู้ใช้ไม่ต้องป้อนข้อมูลการชำระเงินซ้ำ

ตรวจสอบว่าได้เพิ่มค่า autocomplete ที่เหมาะสมในแบบฟอร์มบัตรสำหรับชำระเงิน ซึ่งรวมถึงหมายเลขบัตรสำหรับชำระเงิน ชื่อบนบัตร วันที่หมดอายุ และรหัสความปลอดภัย ดังนี้

• cc-number
• cc-name
• cc-exp หรือ cc-exp-month และ cc-exp-year สำหรับฟิลด์แยกกัน
• cc-csc

ซึ่งจะช่วยให้เบราว์เซอร์ช่วยเหลือผู้ใช้ได้โดยการจัดเก็บรายละเอียดบัตรสำหรับชำระเงินอย่างปลอดภัยและป้อนข้อมูลในแบบฟอร์มอย่างถูกต้อง หากไม่มีการเติมข้อความอัตโนมัติ ผู้ใช้อาจมีแนวโน้มที่จะจดบันทึกรายละเอียดบัตรสำหรับชำระเงินไว้ในกระดาษหรือจัดเก็บข้อมูลบัตรสำหรับชำระเงินไว้ในอุปกรณ์อย่างไม่ปลอดภัย

หลีกเลี่ยงการใช้องค์ประกอบที่กำหนดเองสำหรับวันที่ในบัตรสำหรับชำระเงิน

หากออกแบบไม่ถูกต้อง องค์ประกอบที่กำหนดเองอาจขัดจังหวะขั้นตอนการชำระเงินโดยทำให้การป้อนข้อความอัตโนมัติใช้งานไม่ได้ และจะไม่ทำงานในเบราว์เซอร์รุ่นเก่า หากรายละเอียดอื่นๆ ทั้งหมดของบัตรสำหรับชำระเงินพร้อมใช้งานจากการเติมข้อความอัตโนมัติ แต่ผู้ใช้ถูกบังคับให้ค้นหาบัตรสำหรับชำระเงินจริงเพื่อดูวันที่หมดอายุเนื่องจากการป้อนข้อความอัตโนมัติไม่ทำงานสำหรับองค์ประกอบที่กำหนดเอง คุณก็อาจสูญเสียยอดขายไป ลองใช้องค์ประกอบ HTML มาตรฐานแทน และจัดรูปแบบให้เหมาะสม

ใช้ช่องป้อนข้อมูลเดียวสำหรับบัตรสำหรับชำระเงินและหมายเลขโทรศัพท์

สำหรับบัตรสำหรับชำระเงินและหมายเลขโทรศัพท์ ให้ใช้อินพุตเดียว โดยอย่าแยกหมายเลขออกเป็นส่วนๆ ซึ่งช่วยให้ผู้ใช้ป้อนข้อมูลได้ง่ายขึ้น ทำให้การตรวจสอบง่ายขึ้น และช่วยให้เบราว์เซอร์ป้อนข้อความอัตโนมัติได้ พิจารณาทำเช่นเดียวกันกับข้อมูลตัวเลขอื่นๆ เช่น PIN และรหัสธนาคาร

ตรวจสอบอย่างละเอียด

คุณควรตรวจสอบความถูกต้องของข้อมูลที่ป้อนทั้งแบบเรียลไทม์และก่อนส่งแบบฟอร์ม วิธีหนึ่งในการดำเนินการนี้คือการเพิ่มแอตทริบิวต์ pattern ลงในอินพุตบัตรสำหรับชำระเงิน หากผู้ใช้พยายามส่งแบบฟอร์มการชำระเงินที่มีค่าไม่ถูกต้อง เบราว์เซอร์จะแสดงข้อความเตือนและโฟกัสที่อินพุต ไม่ต้องใช้ JavaScript

อย่างไรก็ตาม patternนิพจน์ทั่วไปต้องมีความยืดหยุ่นเพียงพอที่จะรองรับช่วงความยาวของหมายเลขบัตรสำหรับชำระเงินตั้งแต่ 14 หลัก (หรืออาจน้อยกว่านั้น) ไปจนถึง 20 หลัก (หรือมากกว่านั้น) ดูข้อมูลเพิ่มเติมเกี่ยวกับโครงสร้างหมายเลขบัตรสำหรับชำระเงินได้จาก LDAPwiki

อนุญาตให้ผู้ใช้เว้นวรรคเมื่อป้อนหมายเลขบัตรสำหรับชำระเงินใหม่ เนื่องจากหมายเลขบนบัตรจริงจะแสดงในลักษณะนี้ ซึ่งเป็นมิตรกับผู้ใช้มากกว่า (คุณไม่ต้องบอกผู้ใช้ว่า "ทำอะไรผิด") มีโอกาสน้อยที่จะขัดจังหวะขั้นตอน Conversion และการนำช่องว่างในตัวเลขออกก่อนประมวลผลก็เป็นเรื่องที่ตรงไปตรงมา

ทดสอบในอุปกรณ์ แพลตฟอร์ม เบราว์เซอร์ และเวอร์ชันต่างๆ

การทดสอบแบบฟอร์มที่อยู่และการชำระเงินบนแพลตฟอร์มที่ผู้ใช้ใช้บ่อยที่สุดเป็นสิ่งสำคัญอย่างยิ่ง เนื่องจากฟังก์ชันการทำงานและลักษณะที่ปรากฏขององค์ประกอบแบบฟอร์มอาจแตกต่างกัน และความแตกต่างของขนาดวิวพอร์ตอาจทำให้เกิดปัญหาในการจัดตำแหน่ง BrowserStack ช่วยให้ทดสอบโปรเจ็กต์โอเพนซอร์สได้ฟรีในอุปกรณ์และเบราว์เซอร์ต่างๆ

ใช้ Analytics และ RUM

การทดสอบความสามารถในการใช้งานและประสิทธิภาพในเครื่องอาจเป็นประโยชน์ แต่คุณต้องมีข้อมูลในชีวิตจริงเพื่อทำความเข้าใจอย่างถูกต้องว่าผู้ใช้มีประสบการณ์อย่างไรกับแบบฟอร์มการชำระเงินและที่อยู่

คุณจึงต้องใช้ข้อมูลวิเคราะห์และการตรวจสอบผู้ใช้จริง ซึ่งเป็นข้อมูลเกี่ยวกับประสบการณ์ของผู้ใช้จริง เช่น ระยะเวลาที่ใช้ในการโหลดหน้าชำระเงินหรือระยะเวลาที่ใช้ในการชำระเงินจนเสร็จสมบูรณ์

• ข้อมูลวิเคราะห์หน้าเว็บ: การดูหน้าเว็บ อัตราตีกลับ และการออกจากหน้าเว็บที่มีแบบฟอร์ม
• ข้อมูลวิเคราะห์การโต้ตอบ: Funnel เป้าหมายและเหตุการณ์จะระบุจุดที่ผู้ใช้ออกจากขั้นตอนการชำระเงิน และการกระทำที่ผู้ใช้ทำเมื่อโต้ตอบกับแบบฟอร์ม
• ประสิทธิภาพของเว็บไซต์: เมตริกที่เน้นผู้ใช้เป็นศูนย์กลางจะบอกได้ว่าหน้าชำระเงินโหลดช้าหรือไม่ และหากช้า สาเหตุคืออะไร

ข้อมูลวิเคราะห์หน้าเว็บ ข้อมูลวิเคราะห์การโต้ตอบ และการวัดประสิทธิภาพของผู้ใช้จริงจะมีคุณค่าอย่างยิ่งเมื่อรวมกับบันทึกของเซิร์ฟเวอร์ ข้อมูล Conversion และการทดสอบ A/B ซึ่งจะช่วยให้คุณตอบคำถามต่างๆ ได้ เช่น รหัสส่วนลดช่วยเพิ่มรายได้หรือไม่ หรือการเปลี่ยนแปลงเลย์เอาต์ของแบบฟอร์มช่วยปรับปรุง Conversion หรือไม่

ซึ่งจะช่วยให้คุณมีรากฐานที่มั่นคงในการจัดลำดับความสำคัญของความพยายาม ทำการเปลี่ยนแปลง และให้รางวัลแก่ความสำเร็จ

เรียนรู้อยู่เสมอ

• แนวทางปฏิบัติแนะนำสำหรับแบบฟอร์มลงชื่อเข้าใช้
• แนวทางปฏิบัติแนะนำสำหรับแบบฟอร์มลงชื่อสมัครใช้
• ยืนยันหมายเลขโทรศัพท์บนเว็บด้วย WebOTP API
• สร้างแบบฟอร์มที่น่าทึ่ง
• แนวทางปฏิบัติแนะนำสำหรับการออกแบบแบบฟอร์มบนอุปกรณ์เคลื่อนที่
• การควบคุมแบบฟอร์มที่มีประสิทธิภาพมากขึ้น
• การสร้างแบบฟอร์มที่เข้าถึงได้
• การปรับปรุงขั้นตอนการลงชื่อสมัครใช้ให้มีประสิทธิภาพมากขึ้นโดยใช้ Credential Management API
• คู่มือที่ครอบคลุมเกี่ยวกับที่อยู่ทางไปรษณีย์ของ Frank มีลิงก์ที่เป็นประโยชน์และคำแนะนำที่ครอบคลุมสำหรับรูปแบบที่อยู่ในกว่า 200 ประเทศ
• Countries Lists มีเครื่องมือสำหรับดาวน์โหลดรหัสและชื่อประเทศในหลายภาษาและหลายรูปแบบ

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