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

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

Sam Dutton

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

นี่คือตัวอย่างของรูปแบบการชำระเงินง่ายๆ ที่แสดงให้เห็นแนวทางปฏิบัติแนะนำทั้งหมด

นี่คือตัวอย่างของแบบฟอร์มที่อยู่ง่ายๆ ที่แสดงให้เห็นแนวทางปฏิบัติแนะนำทั้งหมด

เช็กลิสต์

ใช้ HTML ที่มีความหมาย

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

  • <form>, <input>, <label> และ <button>
  • type, autocomplete และ inputmode

รายการเหล่านี้จะช่วยให้ฟังก์ชันของเบราว์เซอร์มีในตัว ปรับปรุงการช่วยเหลือพิเศษ และเพิ่มความหมายให้กับมาร์กอัปของคุณ

ใช้องค์ประกอบ HTML ตามที่ตั้งใจไว้

ใส่แบบฟอร์มของคุณใน <แบบฟอร์ม>

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

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

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

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

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

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

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

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

ภาพหน้าจอ 2 ภาพของโทรศัพท์ Android แสดงแป้นพิมพ์ที่เหมาะสำหรับการป้อนอีเมล (โดยใช้ type=email) และการป้อนหมายเลขโทรศัพท์ (พร้อม type=tel)
แป้นพิมพ์ที่เหมาะสำหรับอีเมลและโทรศัพท์

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

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

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

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

ค่าคงที่

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

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

ตัวอย่างหน้าชำระเงินที่แสดงลิงก์สำหรับเปลี่ยนที่อยู่สำหรับการเรียกเก็บเงิน
เพิ่มลิงก์เพื่อตรวจสอบการเรียกเก็บเงิน

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

<input autocomplete="shipping address-line-1" ...>
...
<input autocomplete="billing address-line-1" ...>

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

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

คุณเพิ่มแอตทริบิวต์จำกัดในองค์ประกอบของแบบฟอร์มเพื่อระบุค่าที่ยอมรับได้ เช่น min, max และ pattern สถานะความถูกต้องขององค์ประกอบจะได้รับการกำหนดโดยอัตโนมัติโดยขึ้นอยู่กับว่าค่าขององค์ประกอบถูกต้อง เช่น คลาส Pseudo-class ของ :valid และ :invalid ซึ่งใช้เพื่อจัดรูปแบบองค์ประกอบด้วยค่าที่ถูกต้องหรือไม่ถูกต้อง

เช่น HTML ต่อไปนี้จะระบุอินพุตสำหรับปีเกิดระหว่าง 1900 ถึง 2020 การใช้ type="number" จะจํากัดค่าอินพุตเป็นตัวเลขเท่านั้น ภายในช่วงที่ระบุโดย min และ max หากคุณพยายามป้อนหมายเลขนอกช่วง ระบบจะตั้งค่าอินพุตให้เป็นสถานะที่ไม่ถูกต้อง

ตัวอย่างต่อไปนี้ใช้ pattern="[\d ]{10,30}" เพื่อให้แน่ใจว่ามีหมายเลขบัตรสำหรับชำระเงินที่ถูกต้อง แต่อนุญาตให้เว้นวรรค

เบราว์เซอร์ที่ทันสมัยยังทำการตรวจสอบขั้นพื้นฐานสำหรับอินพุตที่มีประเภท email หรือ url อีกด้วย

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

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

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

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

ดูข้อมูลเพิ่มเติมในใช้ JavaScript สำหรับการตรวจสอบแบบเรียลไทม์ที่ซับซ้อนมากขึ้น

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

ใช้แอตทริบิวต์ required กับอินพุตสำหรับค่าที่จำเป็น

เมื่อส่งแบบฟอร์ม เบราว์เซอร์ที่ทันสมัย จะส่งข้อความแจ้งและตั้งโฟกัสไปที่requiredฟิลด์ที่ไม่มีข้อมูลโดยอัตโนมัติ และคุณสามารถใช้ :required Pseudo-class เพื่อไฮไลต์ฟิลด์ที่จำเป็น ไม่ต้องใช้ JavaScript

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

ชำระเงินได้ง่ายขึ้น

ระวังช่องว่างด้านการค้าในอุปกรณ์เคลื่อนที่!

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

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

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

กำหนดให้การชำระเงินโดยไม่ลงชื่อเข้าใช้เป็นค่าเริ่มต้น

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

สาเหตุของการละทิ้งรถเข็นช็อปปิ้งกลางคันระหว่างการชำระเงิน
จาก baymard.com/checkout-usability

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

แสดงความคืบหน้าในการชำระเงิน

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

แสดงความคืบหน้าในการชำระเงิน

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

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

ใช้แอตทริบิวต์ enterkeyhint ในอินพุตแบบฟอร์มเพื่อตั้งค่าป้ายกำกับแป้น Enter บนแป้นพิมพ์บนอุปกรณ์เคลื่อนที่ เช่น ใช้ enterkeyhint="previous" และ enterkeyhint="next" ภายในแบบฟอร์มหลายหน้า enterkeyhint="done" สำหรับอินพุตสุดท้ายในแบบฟอร์ม และใช้ enterkeyhint="search" สำหรับอินพุตการค้นหา

ภาพหน้าจอ 2 ภาพของแบบฟอร์มที่อยู่ใน Android ซึ่งแสดงให้เห็นว่าแอตทริบิวต์อินพุต Enterkeyhint เปลี่ยนไอคอนปุ่มแป้น Enter อย่างไร
ปุ่ม "Enter" ใน Android: "next" และ "done"

แอตทริบิวต์ enterkeyhint รองรับใน Android และ iOS ดูข้อมูลเพิ่มเติมได้ในคำอธิบาย Enterkeyhint

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

นำสิ่งที่ไม่ต้องการออก

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

ภาพหน้าจอ 2 ภาพบนอุปกรณ์เคลื่อนที่ซึ่งแสดงความคืบหน้าผ่านการชำระเงิน johnlewis.com การค้นหา การนำทาง และสิ่งรบกวนอื่นๆ จะถูกนำออก
นำการค้นหา การนำทาง และสิ่งรบกวนอื่นๆ ออกจากการชำระเงิน

มุ่งเน้นไปที่การเดินทาง นี่ไม่ใช่เวลาที่จะล่อลวงให้ผู้ใช้ทำอย่างอื่น

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

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

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

ทำให้กรอกชื่อและที่อยู่ได้ง่าย

ขอเฉพาะข้อมูลที่คุณต้องการ

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

ใช้การป้อนชื่อเดียว

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

โดยเฉพาะอย่างยิ่ง ยกเว้นในกรณีที่คุณมีเหตุผลอันควรที่จะไม่ทำเช่นนั้น ไม่ต้องเพิ่มข้อมูลแยกต่างหากสำหรับคำนำหน้าหรือชื่อ (เช่น Mrs, Dr หรือ Lord) ผู้ใช้สามารถพิมพ์คำนั้นด้วยชื่อของพวกเขาได้ถ้าต้องการ นอกจากนี้ ปัจจุบันการเติมข้อความอัตโนมัติ honorific-prefix ยังใช้งานไม่ได้ในเบราว์เซอร์ส่วนใหญ่ ดังนั้น การเพิ่มช่องสำหรับคำนำหน้าชื่อหรือชื่อจะทำให้ประสบการณ์การป้อนข้อมูลในแบบฟอร์มที่อยู่ของผู้ใช้ส่วนใหญ่ใช้งานไม่ได้

เปิดใช้การป้อนชื่ออัตโนมัติ

ใช้ name สำหรับชื่อเต็ม:

<input autocomplete="name" ...>

หากคุณมีเหตุผลอันสมควรในการแยกส่วนต่างๆ ของชื่อออก ให้ใช้ค่าการเติมข้อความอัตโนมัติที่เหมาะสม ดังนี้

  • honorific-prefix
  • given-name
  • nickname
  • additional-name-initial
  • additional-name
  • family-name
  • honorific-suffix

อนุญาตให้ใช้ชื่อต่างประเทศ

คุณอาจต้องตรวจสอบความถูกต้องของป้อนชื่อ หรือจำกัดอักขระที่อนุญาตสำหรับข้อมูลชื่อ อย่างไรก็ตาม คุณต้องไม่เข้มงวดกับการใช้ตัวอักษร เป็นการหยาบคายที่จะบอกว่าชื่อของคุณ "ไม่ถูกต้อง"!

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

ไม่ควรทำ
<!-- Names with non-Latin characters (such as Françoise or Jörg) are 'invalid'. -->
<input pattern="[\w \-]+" ...>
ควรทำ
<!-- Accepts Unicode letters. -->
<input pattern="[\p{L} \-]+" ...>
การจับคู่ตัวอักษร Unicode เปรียบเทียบกับการจับคู่ตัวอักษรละตินเท่านั้น

อนุญาตสำหรับรูปแบบที่อยู่ที่หลากหลาย

เมื่อคุณออกแบบแบบฟอร์มที่อยู่ ให้คำนึงถึงรูปแบบที่อยู่ต่างๆ ที่ดูสับสนอยู่เสมอ แม้จะอยู่ในประเทศเดียวก็ตาม โปรดระวังอย่าคาดเดาที่อยู่ "ปกติ" (ดู UK Address Oddities! ถ้าไม่มั่นใจ!)

ทำให้แบบฟอร์มที่อยู่มีความยืดหยุ่น

อย่าบังคับให้ผู้ใช้พยายามบีบที่อยู่ของตนเองลงในช่องของแบบฟอร์มที่ไม่เหมาะสม

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

โปรดระวังช่องที่อยู่ 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

สำหรับพื้นที่ข้อความ ให้ใช้ street-address เป็นค่าการเติมข้อความอัตโนมัติ

ต่อไปนี้คือตัวอย่างของแบบฟอร์มที่แสดงการใช้ textarea รายการเดียวสำหรับที่อยู่

ปรับแบบฟอร์มที่อยู่ให้เป็นสากลและปรับให้เข้ากับท้องถิ่น

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

โปรดทราบว่าการตั้งชื่อส่วนต่างๆ ของที่อยู่จะแตกต่างกันไป เช่นเดียวกับรูปแบบที่อยู่ แม้จะเป็นภาษาเดียวกันก็ตาม

    ZIP code: US
 Postal code: Canada
    Postcode: UK
     Eircode: Ireland
         PIN: India

การแสดงแบบฟอร์มที่ไม่ตรงกับที่อยู่หรือไม่ได้ใช้คำที่คุณคาดไว้อาจทำให้รู้สึกรำคาญหรือสับสน

การปรับแต่งแบบฟอร์มที่อยู่สำหรับหลายภาษาอาจจำเป็นสำหรับเว็บไซต์ของคุณ แต่การใช้เทคนิคต่างๆ เพื่อเพิ่มความยืดหยุ่นของรูปแบบให้ได้สูงสุด (ตามที่อธิบายไว้ข้างต้น) อาจเพียงพอแล้ว หากคุณไม่แปลแบบฟอร์มที่อยู่ ให้ทำความเข้าใจลำดับความสำคัญหลักๆ เพื่อรับมือกับรูปแบบที่อยู่ต่างๆ ดังนี้ * หลีกเลี่ยงการเจาะจงเกี่ยวกับส่วนต่างๆ ของที่อยู่มากเกินไป เช่น การยืนกรานชื่อถนนหรือบ้านเลขที่ * หากเป็นไปได้ โปรดหลีกเลี่ยงการสร้างช่อง required ตัวอย่างเช่น ที่อยู่ในหลายประเทศไม่มีรหัสไปรษณีย์ และที่อยู่ชนบทอาจไม่มีชื่อถนนหรือชื่อถนน * ใช้การตั้งชื่อที่ครอบคลุม: "ประเทศ/ภูมิภาค" ไม่ใช่ "ประเทศ" "รหัสไปรษณีย์" ไม่ใช่ "ZIP"

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

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

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

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

รหัสไปรษณีย์อาจมีที่อยู่จำนวนมาก

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

การป้อนชื่อเดียวจะช่วยให้ป้อนที่อยู่ได้ด้วยการแตะเพียงครั้งเดียว (คลิกเดียว)

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

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

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

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

  • cc-number
  • cc-name
  • cc-exp-month
  • cc-exp-year

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

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

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

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

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

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

ภาพหน้าจอของแบบฟอร์มการชำระเงินที่แสดงช่องบัตรเครดิตที่แบ่งออกเป็น 4 องค์ประกอบ
อย่าใช้ข้อมูลที่ป้อนหลายรายการสำหรับหมายเลขบัตรเครดิต

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

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

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

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

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

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

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

ใช้ Analytics และ RUM

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

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

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

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

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

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

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