𝗗𝗼𝗻'𝘁 𝗨𝘀𝗲 𝗢𝗻𝗲 𝗚𝗲𝗻𝗲𝗿𝗶𝗰 𝗘𝗺𝗽𝘁𝘆 𝗦𝘁𝗮𝘁𝗲 𝗙𝗼𝗿 𝗬𝗼𝘂𝗿 𝗗𝗮𝘁𝗮 𝗧𝗮𝗯𝗹𝗲𝘀

ตารางข้อมูลส่วนใหญ่มักมาพร้อมกับข้อความเพียงอย่างเดียวคือ: "ไม่มีข้อมูล"

มันอาจจะดูดีในการรีวิวงานออกแบบ แต่กลับสร้างปัญหาจนต้องเปิด Support Ticket เมื่อใช้งานจริง

ตารางที่ว่างเปล่ามีความหมายที่แตกต่างกันถึงสามอย่าง ซึ่งแต่ละกรณีต้องการการออกแบบ ข้อความ และการดำเนินการที่เฉพาะเจาะจง

นี่คือสามกรณีที่คุณต้องออกแบบแยกจากกัน:

  1. การใช้งานครั้งแรก (ยังไม่มีข้อมูลอยู่เลย) ผู้ใช้เป็นผู้ใช้ใหม่ พวกเขาต้องการทราบว่าตารางนี้มีไว้ทำอะไรและจะเริ่มต้นได้อย่างไร • เป้าหมาย: ช่วยแนะนำการใช้งาน (Onboard) ให้กับผู้ใช้ • ข้อความ: อธิบายวัตถุประสงค์ของตาราง • การดำเนินการ: มีปุ่มสำหรับสร้างรายการแรกหรือนำเข้าข้อมูล • สิ่งที่ควรหลีกเลี่ยง: ข้อความที่ทำให้ไปต่อไม่ได้ เช่น "ไม่มีข้อมูล"

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

  3. โหลดข้อมูลล้มเหลว (คำขอทำงานผิดพลาด) เซิร์ฟเวอร์ส่งข้อความแสดงข้อผิดพลาดกลับมา หรือเครือข่ายขัดข้อง • เป้าหมาย: ช่วยให้ผู้ใช้สามารถกู้คืนสถานะหรือดำเนินการต่อได้ • ข้อความ: อธิบายว่าการโหลดข้อมูลล้มเหลว พร้อมแสดงเวลาที่เกิดเหตุหรือรหัสข้อผิดพลาด (error code) • การดำเนินการ: มีปุ่มสำหรับลองใหม่อีกครั้ง (Retry) • สิ่งที่ควรหลีกเลี่ยง: การบอกผู้ใช้ว่า "ไม่มีข้อมูล" ทั้งที่ปัญหาจริงๆ คือข้อผิดพลาดทางเทคนิค

ทำไมทีมต่างๆ ถึงพลาดเรื่องนี้:

  • พวกเขาออกแบบ Empty State ช้าเกินไปในกระบวนการทำงาน
  • พวกเขาทดสอบด้วยข้อมูลตัวอย่าง (Demo data) เท่านั้น จึงไม่เคยเห็นสถานะว่างเปล่าเลย
  • พวกเขามองว่า Empty State เป็นเพียงกรณีพิเศษ (Edge cases)

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

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

ที่มา: https://dev.to/137foundry/why-the-empty-states-in-a-data-table-deserve-three-separate-designs-instead-of-one-generic-message-1il4