UX และ HTML5: มาช่วยให้ผู้ใช้กรอกแบบฟอร์มมือถือของคุณ (ตอนที่ 1)

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

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

การอ่านที่แนะนำ : World Wide Web, Not Wealthy Western Web

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

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

หมายเหตุ : แม้ว่าการปรับปรุงโค้ดส่วนใหญ่ในบทความนี้จะเกี่ยวข้องกับเว็บ (เพราะฉันไม่รู้จัก Swift หรือ Java) แต่แนวทางปฏิบัติที่ดีที่สุดในด้านความสามารถในการใช้งานถือเป็นจริงสำหรับแอปพลิเคชันบนมือถือ

การออกแบบแบบฟอร์ม 101: จัดลำดับความสำคัญของความสามารถในการสแกนและการอ่าน

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

สถาปัตยกรรมสารสนเทศที่แข็งแกร่ง

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

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

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

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

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

การวางฉลากและการเพิ่มประสิทธิภาพอินพุต

เค้าโครงคอลัมน์เดียวทำงานได้ดีที่สุด

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

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

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการจัดวางฉลาก โปรดดู "ความสามารถในการใช้งานแบบฟอร์มบนมือถือ: วางป้ายกำกับไว้เหนือฟิลด์" ของสถาบัน Baymard

ฉลากควรมีความชัดเจนและมองเห็นได้และทำงานได้โดยไม่มีบริบท

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

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

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

แนวทางปฏิบัติที่ดีที่สุดสำหรับขนาดอินพุต

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

การใช้มาสก์เพื่อหลีกเลี่ยงการแยกอินพุตบนมือถือ

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

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

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

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

คำอธิบายฟิลด์ที่มีประสิทธิภาพ

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

คำอธิบายสามารถใช้ทำอะไรได้บ้าง?

คำอธิบายสามารถช่วยผู้ใช้ได้หลายวิธี นี่คือตัวอย่างบางส่วน

• คุณต้องการอะไรกันแน่?
  

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

  

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

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

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

  

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



• “ฉันควรจัดรูปแบบข้อมูลอย่างไร”
  บางฟิลด์ต้องมี รูปแบบเฉพาะ ในกรณีนี้ ให้ใช้คำอธิบายเพื่อให้ผู้ใช้ทราบกฎการจัดรูปแบบล่วงหน้า นี่คือตัวอย่างบางส่วน:
  • หมายเลขโทรศัพท์: ต้องใส่รหัสโทรระหว่างประเทศ (+xx) หน้าสนามหรือไม่?
  • มีความยาวสูงสุดหรือไม่? Twitter บนมือถือทำงานได้ดีกับสิ่งนั้น
  • เมื่อจัดการกับจำนวนเงิน รูปแบบที่มีเครื่องหมายจุลภาค (เช่น 10,000) หรือการเว้นวรรค (เช่น 10,000) หรือไม่
  • คุณคาดหวังรูปแบบใดสำหรับวันที่ ฉันจะให้คุณตรวจสอบในวิกิพีเดียว่าฝันร้ายนั้นเป็นอย่างไร ความแตกต่างระหว่าง DD MM YY และ MM DD YY อาจทำให้ผู้ใช้ *จำนวนมาก* มีปัญหาเมื่อจองออนไลน์
  โปรดทราบว่าปัญหาการจัดรูปแบบจำนวนมากสามารถแก้ไขได้ด้วยรูปแบบการป้อนข้อมูล เราจะมาพูดถึงเรื่องนี้ในภายหลัง (หรือคุณสามารถกระโดดเข้าไปได้เลยหากคุณใจร้อน)

  

วิธีการแสดงคำอธิบาย

ในตัวอย่างข้างต้น เราเห็นวิธีแสดงคำอธิบายฟิลด์สองสามวิธี นี่คือบทสรุปของสิ่งที่ต้องทำ:

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

ระวังตัวยึดตำแหน่ง

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

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

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

หากคุณต้องการเจาะลึกในหัวข้อนี้ มีบทความดีๆ ที่ชื่อว่า "Placeholder Attribute Is Not A Label และ Joshua Winn และ FeedbackGuru จะลงรายละเอียดว่าเหตุใดจึงเป็นแนวคิดที่ไม่ดี Nielsen Norman Group ยังเขียนบทความในหัวข้อนี้ว่า “ตัวยึดตำแหน่งในฟิลด์แบบฟอร์มเป็นอันตราย”

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

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

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

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

การลดต้นทุนการโต้ตอบสำหรับแบบฟอร์มที่ประสบความสำเร็จ

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

การศึกษาเวทมนตร์บนอินเทอร์เน็ตบอกฉันให้ลดจำนวนเขตข้อมูล

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

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

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

นอกจากนี้ อย่าสุ่มสี่สุ่มห้าเชื่อทุกสถิติและการศึกษาที่คุณพบบนอินเทอร์เน็ต จำการศึกษา 11-fields-to-4 ได้หรือไม่? ผลการศึกษาล่าสุดอีกชิ้นหนึ่งแสดงให้เห็นว่าการลดฟิลด์จาก 9 เป็น 6 การแปลงลดลง 14% น่าตกใจใช่มั้ยล่ะ? ทำไม? พวกเขาลบฟิลด์ที่มีส่วนร่วมมากที่สุด เรื่องสั้นโดยย่อ พวกเขากลับไปที่ 9 ฟิลด์ วางที่สำคัญที่สุดไว้บนสุด และ voila การแปลงเพิ่มขึ้น 19.21%

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

แล้วคุณทำอะไรได้บ้าง? ทดสอบ. ทดสอบ. และทดสอบ!

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

การเพิ่มประสิทธิภาพการโต้ตอบแบบสัมผัส

ทำให้การควบคุมสัมผัสได้ง่าย

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

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

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

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการออกแบบเพื่อการสัมผัส คุณสามารถอ่านสิ่งต่อไปนี้:

• “การออกแบบที่เป็นมิตรกับนิ้ว: ขนาดเป้าหมายหน้าจอมือถือในอุดมคติ”
• “The Thumb Zone: การออกแบบสำหรับผู้ใช้มือถือ”

ให้ข้อเสนอแนะ

ผู้ใช้มือถือไม่มีเมาส์ (ล้อเล่น) ดังนั้นพวกเขาจึงไม่ได้รับคำติชม "คลิก" ที่ผู้ใช้เดสก์ท็อปได้รับเมื่อกดปุ่ม ผู้ใช้ฟอร์มมือถือต้องการคำติชมที่ชัดเจนเมื่อโต้ตอบกับองค์ประกอบ:

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

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

ให้เกียรติคำสั่งปุ่มถัดไปและก่อนหน้า

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

หลีกเลี่ยงการดรอปดาวน์บนมือถือถ้าเป็นไปได้

ดรอปดาวน์ (องค์ประกอบการเลือก HTML) บนเว็บต้องการแท็บและการโต้ตอบจำนวนมาก ดังนั้น ดังที่ Luke Wroblewski กล่าว พวกเขาควรเป็น UI ของทางเลือกสุดท้าย ส่วนประกอบ UI อื่นๆ จำนวนมากทำงานได้ดีกว่าดรอปดาวน์ในหลาย ๆ สถานการณ์

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

รายชื่อประเทศ เป็นตัวเลือกที่ดีสำหรับส่วนประกอบ ดรอปดาวน์จากกว่าร้อยประเทศเป็นฝันร้ายของการโต้ตอบบนมือถือ ไม่เป็นไรหากคุณกำลังมองหาอัฟกานิสถาน (ตอนต้นของรายการ) หรือซิมบับเว (จุดสิ้นสุดของรายการ) หากคุณกำลังมองหาลักเซมเบิร์ก คุณจะจบลงด้วยเกมที่ต้องเลื่อนไปจนกลางรายการ ไปไกลเกินกว่าตัวอักษร M พยายามกลับมาที่ L และอื่นๆ

ดรอปดาวน์แบบยาวสามารถแทนที่ด้วยฟิลด์ป้อนข้อความที่คาดเดา ได้ เมื่อผู้ใช้เริ่มพิมพ์ L อินเทอร์เฟซจะเสนอเก้าประเทศ หากพวกเขาเพิ่ม U — voila! — ลักเซมเบิร์ก. การโต้ตอบสี่ครั้งแทนที่จะเป็นสองครั้ง เทียบกับการโต้ตอบแบบเลื่อนได้มากถึงหกหรือเจ็ดรายการกับเมนูแบบเลื่อนลง

หากคุณต้องการให้ผู้ใช้ เลือกวันที่ ลืมแบ่งวันที่ออกเป็นวัน เดือน และปี เหมือนที่คนคุ้นเคยในแบบฟอร์มกระดาษ แทนที่รายการแบบเลื่อนลงของวันที่หลายรายการด้วยตัวเลือกวันที่ type=date ใช้งานได้ในกรณีส่วนใหญ่ แต่คุณอาจมีความต้องการพิเศษบางอย่างและจบลงด้วยการสร้างเครื่องมือเลือกวันที่ของคุณเองใน JavaScript โดยเฉพาะอย่างยิ่งหากคุณอยู่ในธุรกิจการจอง (โรงแรม รถยนต์ เที่ยวบิน)

ในบทความ "Mobile DropDowns Revisited" ของเขา Klaus Schaefers อธิบายว่าการใช้เครื่องมือเลือกวันที่สำหรับวันที่มาถึงและวันที่ออกเดินทางทำให้การโต้ตอบเร็วขึ้น 60% ได้อย่างไร

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

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

ฉลาดขึ้นด้วยการเติมข้อความอัตโนมัติ

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

สถานที่และที่อยู่

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

คุณสามารถใช้:

• Google สถานที่ API
• Algolia Places ซึ่งอิงตาม OpenStreetMap

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

บัตรเครดิต

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

การใช้การเติมข้อความอัตโนมัติ HTML5 (ป้อนอัตโนมัติ)

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

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

กล่าวโดยย่อ เมื่อคุณต้องเลือกระหว่างระบบต่างๆ ให้นับจำนวนการโต้ตอบที่ระบบต้องการ

เกิดข้อผิดพลาด: การจัดการข้อผิดพลาดในแบบฟอร์มมือถือ

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

หลีกเลี่ยงข้อผิดพลาดขณะกรอกแบบฟอร์ม

“การป้องกันดีกว่าการรักษา” แม่ของฉันเคยพูด การออกแบบแบบฟอร์มก็เช่นกัน: การป้องกันข้อผิดพลาดจะปรับปรุงประสบการณ์การใช้แบบฟอร์มบนมือถือของคุณ

ข้อจำกัดรูปแบบที่ชัดเจน

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

หากคุณคิดว่าคุณจำเป็นต้องจำกัดสิ่งที่ผู้ใช้สามารถป้อนลงในฟิลด์ได้ ให้เริ่มด้วยการถามตัวเองว่า "ทำไม" ในด้านประสบการณ์ผู้ใช้ เรามีเทคนิคที่เรียกว่า "เหตุผลสามประการ" ถ้าคำตอบคือ “เพราะฐานข้อมูล blah blah” อาจถึงเวลาต้องเปลี่ยนแปลงสิ่งต่างๆ ตัวอย่างเช่น เหตุใดคุณจึงปฏิเสธอักขระพิเศษ เช่น e, a และ o ในช่องชื่อผู้ใช้ ฉันเขียนบทความอธิบายว่ารูปแบบที่หยาบคายสำหรับฉันเป็นอย่างไรเมื่อฉันพยายามป้อน "Stephanie" เป็นชื่อผู้ใช้ ฉันยังคงพยายามหาเหตุผลที่ดีสำหรับสิ่งนั้น (นอกเหนือจากเหตุผลของฐานข้อมูล)

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

การทำเครื่องหมายฟิลด์บังคับ (และฟิลด์ตัวเลือก)

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

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

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

ค่าเริ่มต้นที่เหมาะสม

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

ระวังเรื่องเพศด้วย อีกครั้ง มีตัวเลือกสำหรับผู้ที่ไม่ต้องการเปิดเผย ทำให้ชัดเจนว่าทำไมคุณถึงขอเพศ ยังดีกว่าขอคำสรรพนามหรือไม่ถามว่าคุณไม่จำเป็นต้องทำจริงๆ If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don't auto-check the first choice, otherwise people won't be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

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

  

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

  

  อย่างที่คุณเห็น มีช่องว่างสำหรับการปรับปรุงอยู่เสมอ

การตรวจสอบแบบอินไลน์

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

แต่ข้อความแสดง ข้อผิดพลาดควรอยู่ใกล้กับข้อผิดพลาดนั้นเอง

การตรวจสอบตามเวลาจริง

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

เคล็ดลับบางประการ:

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

หมายเหตุ : *Mihael Konjevic ได้เขียนบทความดีๆ เกี่ยวกับ “Inline Validation in Forms: Designing the Experience” เขาอธิบายแนวคิดของ " ให้รางวัลก่อน ลงโทษช้า "*

“หากผู้ใช้กำลังป้อนข้อมูลในฟิลด์ที่อยู่ในสถานะ ที่ถูกต้อง ให้ดำเนินการตรวจสอบหลังจากการป้อนข้อมูล”

“หากผู้ใช้กำลังป้อนข้อมูลในฟิลด์ที่อยู่ในสถานะที่ ไม่ถูกต้อง ให้ดำเนินการตรวจสอบระหว่างการป้อนข้อมูล”

เรื่องสี

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

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

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

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

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

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

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

คุณไม่ใช่หุ่นยนต์ และไม่ใช่ผู้ใช้ของคุณ

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

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

ระวังภาษาที่คุณใช้ในข้อความ

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

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

เคล็ดลับเล็กน้อยคือ อ่านข้อความของคุณเองออกมาดังๆ มันจะช่วยให้คุณได้ยินว่ามันใช้ได้ผลหรือรุนแรงเกินไปหรือไม่เป็นทางการเกินไป ฯลฯ

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

เพื่อช่วยให้คุณเขียนข้อความแสดงข้อผิดพลาดได้ดีขึ้น เราขอแนะนำให้คุณอ่านข้อมูลต่อไปนี้:

• “รายการตรวจสอบ Microcopy 6 จุดสำหรับทีมผลิตภัณฑ์ที่ไม่มี UX Writer”
• “ศิลปะแห่งข้อความแสดงข้อผิดพลาด: การเขียนให้ชัดเจน สำเนาที่เป็นประโยชน์เมื่อเกิดข้อผิดพลาด”

เวลาในการส่งแบบฟอร์ม

ผู้ใช้กรอกแบบฟอร์มแล้วไม่มีข้อผิดพลาดอีกต่อไปและทุกอย่างดูดี ในที่สุดก็ถึงเวลาส่งแบบฟอร์ม!

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

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

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

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

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

บทสรุป

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

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

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