วิน

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

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

นี่คือ Error Recovery ที่ผมคิดว่า PZ88X ควรสร้างเป็น Design Principle ระดับระบบ

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

อีกประเด็นคือระบบควร Fail Gracefully หากองค์ประกอบรองมีปัญหา เนื้อหาหลักควรยังอ่านได้ ตัวอย่างง่าย ๆ คือถ้าภาพ Hero โหลดไม่ได้ คนยังต้องเข้าถึง Navigation และหัวข้อหลักได้ ไม่ควรให้ส่วนตกแต่งหนึ่งชิ้นบล็อกทั้งหน้า

ผมยังมองเรื่อง Scalability ด้วย วันนี้ 13 หน้าอาจดูจัดการง่าย แต่ถ้าในอนาคตมีหมวดย่อยเพิ่ม การค้นหาเพิ่ม หรือมีสถานะผู้ใช้หลายแบบ Logic จะซับซ้อนขึ้น สิ่งที่ควรทำตั้งแต่ตอนนี้คือสร้างกฎว่า Component ไหนใช้ซ้ำได้ State ไหนต้องจำ และเมื่อข้อมูลไม่ครบแต่ละหน้าจะตอบสนองอย่างไร

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

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