เพิ่มจำนวน Conversion สูงสุดด้วยการช่วยให้ผู้ใช้กรอกที่อยู่และรูปแบบการชำระเงินได้อย่างรวดเร็วและง่ายดายที่สุด
แบบฟอร์มที่ออกแบบมาอย่างดีจะช่วยเหลือผู้ใช้และเพิ่มอัตรา Conversion การแก้ไขเพียงนิดเดียวก็สร้างความแตกต่างได้อย่างมาก
นี่คือตัวอย่างของรูปแบบการชำระเงินง่ายๆ ที่แสดงให้เห็นแนวทางปฏิบัติแนะนำทั้งหมด
นี่คือตัวอย่างของแบบฟอร์มที่อยู่ง่ายๆ ที่แสดงให้เห็นแนวทางปฏิบัติแนะนำทั้งหมด
เช็กลิสต์
- ใช้องค์ประกอบ HTML ที่มีความหมาย:
<form>
,<input>
,<label>
และ<button>
- ติดป้ายกำกับช่องแบบฟอร์มแต่ละช่องด้วย
<label>
- ใช้แอตทริบิวต์องค์ประกอบ HTML เพื่อเข้าถึงฟีเจอร์เบราว์เซอร์ในตัว โดยเฉพาะ
type
และautocomplete
ด้วยค่าที่เหมาะสม - หลีกเลี่ยงการใช้
type="number"
กับหมายเลขที่ไม่ได้เป็นส่วนเพิ่ม เช่น หมายเลขบัตรสำหรับชำระเงิน โปรดใช้type="text"
และinputmode="numeric"
แทน - หากมีค่าการเติมข้อความอัตโนมัติที่เหมาะสมสำหรับ
input
,select
หรือtextarea
คุณควรใช้ค่านี้ - หากต้องการให้เบราว์เซอร์ป้อนแบบฟอร์มอัตโนมัติ ให้ป้อนแอตทริบิวต์
name
และid
เป็นค่าคงที่ที่ไม่มีการเปลี่ยนแปลงระหว่างการโหลดหน้าเว็บหรือการทำให้เว็บไซต์ใช้งานได้ - ปิดใช้ปุ่มส่งเมื่อมีการแตะหรือคลิก
- ตรวจสอบข้อมูลระหว่างการป้อนข้อมูล ไม่ใช่แค่การส่งแบบฟอร์ม
- กำหนดให้การชำระเงินโดยไม่ลงชื่อเข้าใช้เป็นค่าเริ่มต้นและทำให้การสร้างบัญชีเป็นเรื่องง่ายเมื่อการชำระเงินเสร็จสมบูรณ์
- แสดงความคืบหน้าของกระบวนการชำระเงินเป็นขั้นตอนที่ชัดเจนพร้อมคำกระตุ้นให้ดำเนินการ (Call-To-Action) ที่ชัดเจน
- จำกัดจุดชำระเงินที่อาจเกิดขึ้นโดยการนำสิ่งของที่ยุ่งเหยิงและสิ่งเบี่ยงเบนความสนใจออก
- แสดงรายละเอียดคำสั่งซื้อทั้งหมดที่จุดชำระเงินและปรับเปลี่ยนคำสั่งซื้อได้อย่างง่ายดาย
- อย่าขอข้อมูลที่ไม่จำเป็น
- ขอชื่อด้วยการป้อนข้อมูลเพียงครั้งเดียว เว้นแต่คุณจะมีเหตุผลอันสมควรที่จะไม่ทำเช่นนั้น
- ไม่บังคับใช้อักขระละตินเท่านั้นกับชื่อและชื่อผู้ใช้
- อนุญาตให้ใช้ที่อยู่ได้หลายรูปแบบ
- ลองใช้
textarea
เดี่ยวสำหรับที่อยู่ - ใช้การเติมข้อความอัตโนมัติสำหรับที่อยู่สำหรับการเรียกเก็บเงิน
- ทำให้เป็นสากลและปรับให้เข้ากับท้องถิ่นตามความจำเป็น
- โปรดหลีกเลี่ยงการค้นหาที่อยู่ตามรหัสไปรษณีย์
- ใช้ค่าการเติมข้อมูลบัตรสำหรับชำระเงินที่เหมาะสมโดยอัตโนมัติ
- ใช้การป้อนหมายเลขบัตรเดียวสำหรับหมายเลขบัตรสำหรับชำระเงิน
- หลีกเลี่ยงการใช้องค์ประกอบที่กำหนดเองหากองค์ประกอบเหล่านั้นเสียหายในการใช้งานการป้อนข้อความอัตโนมัติ
- ทดสอบในภาคสนามและในห้องทดลอง: การวิเคราะห์หน้าเว็บ, การวิเคราะห์การโต้ตอบ และ การวัดประสิทธิภาพของผู้ใช้จริง
- ทดสอบในเบราว์เซอร์ อุปกรณ์ และแพลตฟอร์มต่างๆ
ใช้ HTML ที่สื่อความหมาย
ใช้องค์ประกอบและแอตทริบิวต์ที่สร้างสำหรับงาน ดังนี้
<form>
,<input>
,<label>
และ<button>
type
,autocomplete
และinputmode
รายการเหล่านี้จะช่วยให้ฟังก์ชันของเบราว์เซอร์มีในตัว ปรับปรุงการช่วยเหลือพิเศษ และเพิ่มความหมายให้กับมาร์กอัปของคุณ
ใช้องค์ประกอบ HTML ตามที่ตั้งใจไว้
ใส่แบบฟอร์มของคุณใน <แบบฟอร์ม>
คุณอาจไม่อยากรบกวนการรวมองค์ประกอบ <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"
สำหรับหมายเลขโทรศัพท์
สำหรับวันที่พยายามหลีกเลี่ยงการใช้องค์ประกอบ 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
ตรวจสอบความถูกต้องของข้อมูลในบรรทัดและส่งความคิดเห็นให้ผู้ใช้ขณะที่ป้อนข้อมูล แทนที่จะให้รายการข้อผิดพลาดเมื่อผู้ใช้คลิกปุ่มส่ง หากต้องการตรวจสอบข้อมูลในเซิร์ฟเวอร์หลังจากส่งแบบฟอร์ม ให้ระบุปัญหาทั้งหมดที่พบและไฮไลต์ทุกช่องของแบบฟอร์มที่มีค่าไม่ถูกต้องให้ชัดเจน ตลอดจนแสดงข้อความในบรรทัดข้างช่องที่มีปัญหาแต่ละช่องเพื่ออธิบายว่าต้องแก้ไขอะไรบ้าง ตรวจสอบบันทึกของเซิร์ฟเวอร์และข้อมูลการวิเคราะห์เพื่อหาข้อผิดพลาดที่พบบ่อย คุณอาจต้องออกแบบแบบฟอร์มใหม่
นอกจากนี้ คุณยังควรใช้ JavaScript เพื่อดำเนินการตรวจสอบที่มีประสิทธิภาพมากขึ้นในขณะที่ผู้ใช้ป้อนข้อมูลและส่งแบบฟอร์ม ใช้ Constraint Validation API (ซึ่งรองรับในวงกว้าง) เพื่อเพิ่มการตรวจสอบที่กําหนดเองโดยใช้ UI ของเบราว์เซอร์ในตัวเพื่อตั้งค่าโฟกัสและแสดงข้อความแจ้ง
ดูข้อมูลเพิ่มเติมในใช้ JavaScript สำหรับการตรวจสอบแบบเรียลไทม์ที่ซับซ้อนมากขึ้น
ช่วยให้ผู้ใช้ไม่พลาดข้อมูลที่จำเป็น
ใช้แอตทริบิวต์ required
กับอินพุตสำหรับค่าที่จำเป็น
เมื่อส่งแบบฟอร์ม เบราว์เซอร์ที่ทันสมัย
จะส่งข้อความแจ้งและตั้งโฟกัสไปที่required
ฟิลด์ที่ไม่มีข้อมูลโดยอัตโนมัติ และคุณสามารถใช้
:required
Pseudo-class เพื่อไฮไลต์ฟิลด์ที่จำเป็น ไม่ต้องใช้ JavaScript
ใส่เครื่องหมายดอกจันลงในป้ายกำกับสำหรับทุกๆ ช่องที่ต้องกรอก และใส่หมายเหตุไว้ที่ด้านหน้าของแบบฟอร์มเพื่ออธิบายความหมายของเครื่องหมายดอกจัน
ชำระเงินได้ง่ายขึ้น
ระวังช่องว่างด้านการค้าในอุปกรณ์เคลื่อนที่!
ลองจินตนาการว่าผู้ใช้ของคุณมีงบประมาณที่ไม่น่าพึงพอใจ หากใช้งานไปเรื่อยๆ ผู้ใช้ของคุณจะเลิกใช้บริการ
คุณจำเป็นต้องลดการรบกวนและทำให้โฟกัสอยู่เสมอ โดยเฉพาะอย่างยิ่งในอุปกรณ์เคลื่อนที่ เว็บไซต์จำนวนมากได้รับการเข้าชมบนอุปกรณ์เคลื่อนที่มากกว่า แต่ได้รับ Conversion เพิ่มขึ้นบนเดสก์ท็อป ซึ่งเป็นปรากฏการณ์ที่เรียกว่าช่องว่างของการค้าบนอุปกรณ์เคลื่อนที่ ลูกค้าอาจต้องการทำการซื้อให้เสร็จสมบูรณ์บนเดสก์ท็อป แต่อัตรา Conversion อุปกรณ์เคลื่อนที่ที่ลดลงก็เป็นผลจากประสบการณ์ของผู้ใช้ที่ไม่ดีเช่นกัน สิ่งที่คุณต้องทำคือลด Conversion ที่เสียไปบนอุปกรณ์เคลื่อนที่ และเพิ่ม Conversion สูงสุดในเดสก์ท็อป งานวิจัยแสดงให้เห็นว่านี่เป็นโอกาสอันยิ่งใหญ่ในการมอบประสบการณ์การใช้งานฟอร์มบนอุปกรณ์เคลื่อนที่ที่ดีขึ้น
ส่วนใหญ่แล้ว ผู้ใช้มักจะออกจากแบบฟอร์มที่ดูยาว ซับซ้อน และไม่มีเส้นทาง โดยเฉพาะอย่างยิ่งเมื่อผู้ใช้อยู่ในหน้าจอขนาดเล็ก มีสมาธิจดจ่อ หรือเร่งรีบ ขอข้อมูลให้น้อยที่สุดเท่าที่จะทำได้
กำหนดให้การชำระเงินโดยไม่ลงชื่อเข้าใช้เป็นค่าเริ่มต้น
สำหรับร้านค้าออนไลน์ วิธีที่ง่ายที่สุดในการลดความยุ่งยากของแบบฟอร์มคือการตั้งค่าการชำระเงินโดยไม่ลงชื่อเข้าใช้เป็นค่าเริ่มต้น อย่าบังคับให้ผู้ใช้สร้างบัญชีก่อนทำการซื้อ การไม่อนุญาตให้ชำระเงินโดยไม่ลงชื่อเข้าใช้เป็นเหตุผลหลัก ของการทิ้งรถเข็นช็อปปิ้งกลางคัน
คุณเสนอการลงชื่อสมัครใช้บัญชีหลังการชำระเงินได้ เมื่อถึงตอนนั้นคุณก็มีข้อมูลส่วนใหญ่ที่ต้องตั้งค่าบัญชีแล้ว ดังนั้นการสร้างบัญชีควรรวดเร็วและง่ายดายสำหรับผู้ใช้
แสดงความคืบหน้าในการชำระเงิน
คุณสามารถลดความซับซ้อนของกระบวนการชำระเงินโดยแสดงความคืบหน้าและอธิบายให้ชัดเจนว่าต้องดำเนินการอะไรต่อไป วิดีโอด้านล่างแสดงวิธีที่ผู้ค้าปลีกในสหราชอาณาจักร johnlewis.com บรรลุเป้าหมายนี้
คุณต้องรักษาโมเมนตัมเอาไว้ สำหรับขั้นตอนการชำระเงินในแต่ละขั้นตอน ให้ใช้ส่วนหัวของหน้าและค่าปุ่มที่สื่อความหมายเพื่อแสดงให้เห็นชัดเจนว่าต้องทำอะไรตอนนี้ และขั้นตอนต่อไปในการชำระเงินคือขั้นตอนใด
ใช้แอตทริบิวต์ enterkeyhint
ในอินพุตแบบฟอร์มเพื่อตั้งค่าป้ายกำกับแป้น Enter บนแป้นพิมพ์บนอุปกรณ์เคลื่อนที่ เช่น ใช้ enterkeyhint="previous"
และ enterkeyhint="next"
ภายในแบบฟอร์มหลายหน้า enterkeyhint="done"
สำหรับอินพุตสุดท้ายในแบบฟอร์ม และใช้ enterkeyhint="search"
สำหรับอินพุตการค้นหา
แอตทริบิวต์ enterkeyhint
รองรับใน Android และ iOS
ดูข้อมูลเพิ่มเติมได้ในคำอธิบาย Enterkeyhint
ช่วยให้ผู้ใช้กลับไปกลับมาในกระบวนการชำระเงินได้อย่างสะดวก เพื่อปรับคำสั่งซื้อได้อย่างง่ายดาย แม้ว่าจะอยู่ในขั้นตอนการชำระเงินสุดท้ายก็ตาม แสดงรายละเอียดทั้งหมดของคำสั่งซื้อ ไม่ใช่แค่สรุปสั้นๆ ช่วยให้ผู้ใช้ปรับจำนวนสินค้าจากหน้าการชำระเงินได้อย่างง่ายดาย ลำดับความสำคัญของคุณที่จุดชำระเงินคือ เพื่อหลีกเลี่ยงการขัดจังหวะความคืบหน้าของ Conversion
นำสิ่งที่ไม่ต้องการออก
จำกัดจุดที่ผู้เข้าชมอาจออกจากร้านด้วยการนำสิ่งรบกวนสายตาและสิ่งที่เบี่ยงเบนสายตาออก เช่น โปรโมชันของผลิตภัณฑ์ ผู้ค้าปลีกที่ประสบความสำเร็จหลายรายนำการนำทางและการค้นหาออกจากการชำระเงินด้วย
มุ่งเน้นไปที่การเดินทาง นี่ไม่ใช่เวลาที่จะล่อลวงให้ผู้ใช้ทำอย่างอื่น
สำหรับผู้ใช้ที่กลับมา คุณสามารถทำให้ขั้นตอนการชำระเงินง่ายขึ้นได้ โดยซ่อนข้อมูลที่ผู้ใช้ไม่จำเป็นต้องดู เช่น แสดงที่อยู่สำหรับจัดส่งเป็นข้อความธรรมดา (ไม่ใช่ในแบบฟอร์ม) และอนุญาตให้ผู้ใช้เปลี่ยนแปลงที่อยู่ดังกล่าวผ่านลิงก์ได้
ทำให้กรอกชื่อและที่อยู่ได้ง่าย
ขอเฉพาะข้อมูลที่คุณต้องการ
ก่อนที่จะเริ่มเขียนรหัสของแบบฟอร์มชื่อและที่อยู่ ควรทำความเข้าใจเกี่ยวกับข้อมูลที่จำเป็นก่อน อย่าขอข้อมูลที่คุณไม่ต้องการ วิธีที่ง่ายที่สุดในการลดความซับซ้อนของแบบฟอร์มคือการนำช่องที่ไม่จำเป็นออก และยังเป็นผลดีต่อความเป็นส่วนตัวของลูกค้า ทั้งยังสามารถลดต้นทุนและความรับผิดของข้อมูลแบ็กเอนด์ด้วย
ใช้การป้อนชื่อเดียว
อนุญาตให้ผู้ใช้ป้อนชื่อของตนเองโดยใช้ข้อมูลเดียว เว้นแต่คุณจะมีเหตุผลอันสมควรในการจัดเก็บชื่อจริง นามสกุล เกียรติยศ หรือส่วนอื่นๆ ของชื่อแยกต่างหาก การใช้ป้อนชื่อเดียวทำให้แบบฟอร์มซับซ้อนน้อยลง เปิดใช้ฟังก์ชันตัดและวาง และทำให้การป้อนข้อความอัตโนมัติง่ายขึ้น
โดยเฉพาะอย่างยิ่ง ยกเว้นในกรณีที่คุณมีเหตุผลอันควรที่จะไม่ทำเช่นนั้น ไม่ต้องเพิ่มข้อมูลแยกต่างหากสำหรับคำนำหน้าหรือชื่อ (เช่น 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} \-]+" ...>
อนุญาตสำหรับรูปแบบที่อยู่ที่หลากหลาย
เมื่อคุณออกแบบแบบฟอร์มที่อยู่ ให้คำนึงถึงรูปแบบที่อยู่ต่างๆ ที่ดูสับสนอยู่เสมอ แม้จะอยู่ในประเทศเดียวก็ตาม โปรดระวังอย่าคาดเดาที่อยู่ "ปกติ" (ดู 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 และรหัสธนาคาร
ตรวจสอบอย่างละเอียด
คุณควรตรวจสอบการป้อนข้อมูลทั้งแบบเรียลไทม์และก่อนส่งแบบฟอร์ม วิธีหนึ่งที่ทำได้คือการเพิ่มแอตทริบิวต์ pattern
ลงในอินพุตบัตรสำหรับชำระเงิน หากผู้ใช้พยายามส่งแบบฟอร์มการชำระเงินที่มีค่าที่ไม่ถูกต้อง เบราว์เซอร์จะแสดงข้อความเตือนและโฟกัสที่ข้อมูลที่ป้อน ไม่ต้องใช้ JavaScript
อย่างไรก็ตาม นิพจน์ทั่วไป pattern
ต้องยืดหยุ่นพอที่จะรองรับช่วงความยาวของหมายเลขบัตรสำหรับชำระเงิน ตั้งแต่ 14 หลัก (หรืออาจน้อยกว่านี้) จนถึง 20 (หรือมากกว่า) คุณสามารถดูข้อมูลเพิ่มเติมเกี่ยวกับการกำหนดโครงสร้างหมายเลขบัตรสำหรับชำระเงินได้จาก LDAPwiki
อนุญาตให้ผู้ใช้เว้นวรรคเมื่อป้อนหมายเลขบัตรสำหรับชำระเงินใหม่ เนื่องจากเป็นวิธีแสดงหมายเลขบนบัตรจริง วิธีนี้เป็นมิตรต่อผู้ใช้ (คุณไม่ต้องบอกว่า "ผู้ใช้ทำสิ่งผิด") มีโอกาสน้อยลงที่จะขัดจังหวะขั้นตอน Conversion และการนำช่องว่างในตัวเลขออกก่อนที่จะประมวลผลก็ทำได้ง่าย
ทดสอบด้วยอุปกรณ์ แพลตฟอร์ม เบราว์เซอร์ และเวอร์ชันต่างๆ
การทดสอบที่อยู่และแบบฟอร์มการชำระเงินในแพลตฟอร์มที่ผู้ใช้พบบ่อยที่สุดมีความสำคัญอย่างยิ่ง เนื่องจากฟังก์ชันการทำงานและลักษณะที่ปรากฏขององค์ประกอบแบบฟอร์มอาจแตกต่างกันไป และความแตกต่างของขนาดวิวพอร์ตอาจทำให้เกิดการวางตำแหน่งที่เป็นปัญหา BrowsingStack ช่วยให้สามารถทดสอบโปรเจ็กต์โอเพนซอร์สฟรีในอุปกรณ์และเบราว์เซอร์ต่างๆ
ใช้ Analytics และ RUM
การทดสอบความสามารถในการใช้งานและประสิทธิภาพในพื้นที่อาจเป็นประโยชน์ แต่คุณต้องมีข้อมูลจากการใช้งานจริงเพื่อให้เข้าใจประสบการณ์ของผู้ใช้ในแบบฟอร์มการชำระเงินและที่อยู่ของคุณอย่างเหมาะสม
คุณจำเป็นต้องมีข้อมูลการวิเคราะห์และการตรวจสอบผู้ใช้จริง เช่น ข้อมูลประสบการณ์การใช้งานของผู้ใช้จริง เช่น หน้าชำระเงินใช้เวลาโหลดนานเท่าใด หรือระยะเวลาการชำระเงินเสร็จสมบูรณ์
- การวิเคราะห์หน้าเว็บ: การดูหน้าเว็บ อัตราตีกลับ และการออกสำหรับทุกหน้าที่มีแบบฟอร์ม
- ข้อมูลวิเคราะห์การโต้ตอบ: ช่องทางเป้าหมายและเหตุการณ์ระบุจุดที่ผู้ใช้ออกจากขั้นตอนการชำระเงิน และสิ่งที่ผู้ใช้ทำเมื่อโต้ตอบกับแบบฟอร์ม
- ประสิทธิภาพเว็บไซต์: เมตริกที่เน้นผู้ใช้เป็นหลักจะบอกได้ว่าหน้าชำระเงินโหลดช้าหรือไม่ และหากใช่ เกิดจากอะไร
การวิเคราะห์หน้าเว็บ การวิเคราะห์การโต้ตอบ และการวัดประสิทธิภาพของผู้ใช้จริงมีประโยชน์อย่างยิ่งเมื่อใช้ร่วมกับบันทึกของเซิร์ฟเวอร์ ข้อมูล Conversion และการทดสอบ A/B ซึ่งจะช่วยให้คุณสามารถตอบคำถามต่างๆ เช่น รหัสส่วนลดช่วยเพิ่มรายได้ หรือการเปลี่ยนแปลงเลย์เอาต์ของแบบฟอร์มช่วยเพิ่ม Conversion ได้หรือไม่
ซึ่งจะทำให้คุณมีรากฐานที่มั่นคงสำหรับการจัดลำดับความสำคัญของความพยายาม ทำการเปลี่ยนแปลง และให้รางวัลกับความสำเร็จ
เรียนรู้อยู่เสมอ
- แนวทางปฏิบัติแนะนำสำหรับแบบฟอร์มลงชื่อเข้าใช้
- แนวทางปฏิบัติแนะนำสำหรับแบบฟอร์มลงชื่อสมัครใช้
- ยืนยันหมายเลขโทรศัพท์บนเว็บด้วย WebOTP API
- สร้างฟอร์มที่น่าทึ่ง
- แนวทางปฏิบัติแนะนำสำหรับการออกแบบแบบฟอร์มบนอุปกรณ์เคลื่อนที่
- การควบคุมแบบฟอร์มที่มีความสามารถมากขึ้น
- การสร้างแบบฟอร์มที่เข้าถึงได้
- การปรับปรุงขั้นตอนการลงชื่อสมัครใช้ด้วย API การจัดการข้อมูลเข้าสู่ระบบ
- คู่มือแนะนำเกี่ยวกับที่อยู่ไปรษณีย์ของ Frank มีลิงก์ที่เป็นประโยชน์และคำแนะนำที่ครอบคลุมเกี่ยวกับรูปแบบที่อยู่ในกว่า 200 ประเทศ
- รายชื่อประเทศมีเครื่องมือสำหรับดาวน์โหลดรหัสประเทศและชื่อในหลายภาษาในหลายรูปแบบ