เวลาส่งฟอร์มแล้วมีข้อความว่าข้อมูลไม่ถูกต้อง คนกรอกยังต้องรู้ต่อว่าผิดช่องไหน ต้องเปลี่ยนเป็นอะไร และข้อมูลที่กรอกไปส่วนอื่นยังอยู่หรือไม่ ถ้าเว็บบอกเพียงส่งไม่สำเร็จแล้วปล่อยให้ค้นเอง ก็อาจต้องลองส่งซ้ำหลายรอบโดยไม่เข้าใจกติกาที่ระบบต้องการ
ปัญหายังมีหลายแบบด้วยกัน ทั้งรูปแบบข้อมูลไม่ผ่าน ข้อมูลขัดกับเงื่อนไขของระบบ และเครือข่ายที่ขาดระหว่างส่ง หากใช้ข้อความเดียวกับทุกกรณี คนอาจกลับไปแก้ field ที่ถูกอยู่แล้ว หรือส่งงานเดิมซ้ำทั้งที่ปลายทางอาจรับไปเรียบร้อยแล้ว
การออกแบบ error จึงควรเป็นส่วนของการพาคนทำงานให้จบครับ เริ่มจากชื่อช่องกับคำแนะนำที่ชัด แล้วบอกผลตรวจพร้อมทางกลับไปแก้ให้ตรงสาเหตุ ไม่รอเพิ่มข้อความทั่วไปไว้ท้ายหน้าเมื่อเกิดปัญหาแล้ว
Label ที่ผูกกับ field อย่างถูกต้องช่วยระบุว่าช่องนั้นคือข้อมูลใด ส่วนคำแนะนำควรบอกเงื่อนไขที่จำเป็น เช่น รูปแบบหรือขอบเขตที่ระบบรองรับ ไม่ใช้ placeholder เป็นที่เก็บคำอธิบายเพียงแห่งเดียวจนพอพิมพ์แล้วข้อมูลช่วยหายไป
ควรแยกชื่อ field ออกจากตัวอย่าง เช่น ช่องรหัสอุปกรณ์ควรมีชื่อที่คงอยู่ แล้ววางรูปแบบตัวอย่างในข้อความช่วยตามความเหมาะสม หากต้องมี field ที่บังคับกรอก ก็ควรสื่อด้วยข้อความหรือความหมายที่เข้าถึงได้ ไม่ใช้เพียงสีหรือสัญลักษณ์ที่ไม่มีคำอธิบาย
ใน HTML สามารถเชื่อม label กับ input และเชื่อมข้อความช่วยกับ field ผ่าน attribute ที่เกี่ยวข้องได้ ตัวอย่างด้านล่างเป็น fragment สมมติในสถานะที่พบข้อผิดพลาด ไม่ใช่ฟอร์มส่งข้อมูลจริงหรือผลตรวจผู้ใช้รายใด
<label for="device-code">รหัสอุปกรณ์</label>
<input
id="device-code"
name="deviceCode"
aria-invalid="true"
aria-describedby="device-code-help device-code-error"
/>
<p id="device-code-help">ใช้รหัสจากรายการอุปกรณ์ของโครงการนี้</p>
<p id="device-code-error">ไม่พบรหัสนี้ในโครงการ กรุณาตรวจรหัสอีกครั้ง</p>
ข้อความ error ต้องตรงกับผลตรวจจริง และไม่ควรเปิดเผยข้อมูลที่ผู้กรอกไม่มีสิทธิ์รู้จากการเดารหัส การทำให้เข้าใจง่ายยังต้องรักษาขอบเขตข้อมูลของผู้ใช้ตามระบบด้วย
ถ้ารูปแบบไม่ถูก ควรบอกเงื่อนไขที่ต้องการในภาษาที่ตรงกับ field ไม่ส่งชื่อ exception ภายในหรือรหัสฐานข้อมูลขึ้นมาเป็นคำแนะนำ เช่น ข้อความที่บอกว่าขาดวันที่เริ่มช่วยแก้ได้มากกว่าข้อมูล validation ที่มีเพียงชื่อ property ของ API
หากมีหลาย field ผิด สามารถมีสรุปข้อผิดพลาดพร้อมทางไปยังแต่ละช่อง และมีข้อความใกล้ field นั้นด้วย คนจะได้รู้ทั้งภาพรวมว่าต้องแก้อีกเท่าไรกับรายละเอียดของจุดที่กำลังกรอก ไม่ต้องเลื่อนกลับไปดูสรุปทุกครั้ง
แต่ summary กับข้อความรายช่องควรใช้คำตรงกัน หากเรียก field คนละชื่อหรือสรุปกว้างเกินไปก็ยังตามยาก และลิงก์จาก summary ต้องพาไปจุดที่แก้ได้จริง ไม่ชี้เพียงกล่องตกแต่งที่มีข้อความอยู่ข้างๆ
ข้อมูลที่ถูกต้องแล้วควรถูกเก็บไว้เท่าที่เหมาะกับบริบท ไม่ล้างทุกช่องเมื่อพบ error หนึ่งจุด เพราะเพิ่มงานให้คนกรอกและเสี่ยงทำให้ข้อมูลส่วนที่เคยถูกเปลี่ยนผิดในรอบถัดไป ส่วนข้อมูลละเอียดอ่อนต้องวางการเก็บกับแสดงซ้ำตามขอบเขตของมันต่างหาก
การแจ้งผิดขณะคนยังพิมพ์ไม่จบอาจทำให้หน้ากระพริบหรือแสดง error ที่ยังไม่ใช่ปัญหาจริง จึงควรเลือกจังหวะตามชนิดข้อมูล เช่น ตรวจหลังออกจากช่อง หรือหลังส่งครั้งแรกแล้วช่วยอัปเดตผลเมื่อแก้
ถ้าต้องตรวจแบบเรียก server ระหว่างกรอก ต้องแยกผลของคำขอเก่าที่กลับมาช้ากว่าข้อมูลใหม่ ไม่ให้คำตอบของค่าก่อนหน้ามาเขียนทับสถานะของค่าที่คนแก้แล้ว และควรมีสถานะกำลังตรวจที่ไม่สับสนกับตรวจผ่าน
ฝั่ง client ช่วยตรวจและให้คำแนะนำได้เร็ว แต่ข้อมูลยังต้องถูกตรวจบน server ด้วย เพราะคำขออาจถูกส่งจากทางอื่นหรือเปลี่ยนระหว่างทาง การเห็น field ถูกต้องบนหน้าจอจึงไม่ได้เป็นสิทธิ์ให้ server รับข้อมูลโดยข้ามเงื่อนไขทั้งหมด
เงื่อนไขบางอย่างเปลี่ยนตามเวลาหรือสถานะระบบ เช่น รหัสที่เคยใช้ได้ถูกย้ายโครงการ จึงควรให้ผลจาก server ถูกอธิบายกลับมาอย่างเข้ากับหน้าฟอร์ม ไม่ใช้ข้อความว่าระบบผิดพลาดกับทุกกรณีที่ขัดกติกาทางธุรกิจ
ถ้า server ตอบชัดว่าข้อมูลไม่ผ่าน สามารถพากลับไปแก้ตามรายการได้ แต่ถ้าการเชื่อมต่อขาดหลังส่ง คำขออาจถึง server แล้ว จึงไม่ควรบอกแน่นอนว่าระบบไม่ได้รับอะไรและชวนกดส่งใหม่โดยไม่ดูวิธีตรวจผลเดิม
ในงานสร้างรายการ ควรมีรหัสคำขอหรือกลไกป้องกันผลซ้ำตามข้อตกลงของระบบ แล้วใช้ช่วยตรวจว่ารอบก่อนสำเร็จหรือยัง การปิดปุ่มระหว่างส่งช่วยการกดซ้อนในหน้าหนึ่งได้ แต่ไม่ครอบคลุมการ reload หรือส่งจากอีกแท็บทั้งหมด
หากสำเร็จแล้ว ต้องยืนยันผลที่คนใช้ตามต่อได้ เช่น เลขรายการกับสถานะจริง ไม่แสดงสำเร็จเพียงเพราะปุ่มถูกกดหรือคำขอถูกเข้าคิว หากยังอยู่ในขั้นประมวลผลควรบอกสถานะนั้นตามความหมาย
กรณีที่บริการยังใช้ไม่ได้ ควรมีทางกลับมาและรักษางานที่เหมาะสม เช่น ให้ลองใหม่จากข้อมูลเดิมโดยไม่ต้องกรอกซ้ำทั้งหมด แต่การเก็บร่างต้องอยู่ในขอบเขตข้อมูลและอุปกรณ์ที่ระบบตั้งใจรองรับ ไม่คัดลอกข้อมูลส่วนตัวไปเก็บถาวรใน browser โดยไม่มีเหตุผลของงาน
ทดสอบการส่งฟอร์มว่าง ข้อมูลผิดรูปแบบ ข้อมูลขัดเงื่อนไข และเหตุการณ์เครือข่ายที่จำลองในระบบแยก แล้วดูว่า field กับ summary อธิบายตรงกันหรือไม่ และคนกลับไปแก้พร้อมส่งต่อได้จากจุดใด
ตรวจด้วย keyboard และเครื่องมือช่วยอ่านในชุดที่รองรับ เพื่อให้ error ที่เพิ่มมาใหม่ถูกค้นพบและมีชื่อผูกกับ field ไม่เห็นเพียงสีแดงหรือไอคอน ส่วนการย้าย focus ต้องเหมาะกับขนาดการเปลี่ยน ไม่ดึงคนออกจากช่องที่กำลังแก้ทุกครั้งที่ผลตรวจอัปเดต
เมื่อคนแก้ผ่านแล้ว ควรเอาสถานะผิดเดิมออกให้ตรงข้อมูลปัจจุบัน และตรวจว่าคำตอบเก่าไม่ย้อนมาทับ ถ้ามีการ retry ให้ตรวจด้วยว่าเกิดรายการปลายทางกี่รายการตามคำขอที่ตั้งใจ ไม่จบการทดสอบที่ข้อความสำเร็จบนหน้าจออย่างเดียว
Error ของฟอร์มควรเชื่อมจากชื่อช่องกับกติกา ไปสู่ผลตรวจที่อธิบายและแก้ได้ พร้อมรักษาข้อมูลกับสถานะการส่งอย่างตรงความหมาย เมื่อแยก validation ออกจากปัญหาเครือข่ายและออกแบบทางกลับให้ใช้งานได้หลายช่องทาง คนกรอกก็จะทำงานต่อได้โดยไม่ต้องเดาว่าระบบต้องการให้เปลี่ยนอะไรหรือส่งซ้ำไปแล้วกี่ครั้ง