"ขอเพิ่มช่องขนาดเสื้ออีกช่องหนึ่งได้ไหม" — คำของ่าย ๆ ที่ผู้จัดงานถามกันทุกงาน แต่ในระบบลงทะเบียนสำเร็จรูปหลายเจ้า คำตอบคือต้องส่งเรื่องให้ทีมพัฒนา รอคิว รออนุมัติงบ แล้วกว่าจะได้ใช้จริงก็เลยกำหนดเปิดรับสมัครไปแล้ว
ปัญหาของแบบฟอร์มลงทะเบียนแบบตายตัว
ระบบลงทะเบียนงานอีเวนต์ส่วนใหญ่ถูกออกแบบมาโดยเดาว่า "ทุกงานถามเหมือนกัน" — ชื่อ นามสกุล อีเมล เบอร์โทร หน่วยงาน จบ แต่ความจริงคืองานแต่ละประเภทต้องการข้อมูลคนละชุดกันโดยสิ้นเชิง
เมื่อฟอร์มแก้เองไม่ได้ ผู้จัดงานจึงต้องหาทางออกนอกระบบ ซึ่งสร้างปัญหาใหม่ตามมาเสมอ
- ใช้ Google Form คู่ไปด้วย — ได้ข้อมูลครบ แต่อยู่คนละที่กับระบบเช็คอิน ต้องมานั่ง VLOOKUP จับคู่กันเองก่อนวันงาน
- ยัดทุกอย่างลงช่อง "หมายเหตุ" — ข้อมูลกลายเป็นข้อความยาวเหยียดที่กรองไม่ได้ นับไม่ได้ ทำรายงานไม่ได้
- ถามทางโทรศัพท์ทีหลัง — เสียเวลาทีมงานและได้ข้อมูลไม่ครบทุกคน
แบบฟอร์มที่สร้างเองได้ทำงานอย่างไร
ระบบลงทะเบียนที่ออกแบบมาถูกต้องจะไม่กำหนดฟิลด์ตายตัวไว้ล่วงหน้าเลย แต่ให้ผู้จัดงานประกอบฟอร์มเองจากชนิดฟิลด์พื้นฐาน แล้วหน้าลงทะเบียนจริงจะสร้างขึ้นตามนั้นทันที
เงื่อนไขการแสดงผล ทำให้ฟอร์มไม่ยาวเกินจำเป็น
ฟอร์มที่ถามทุกอย่างกับทุกคนคือฟอร์มที่คนกรอกไม่จบ การตั้งให้ช่อง "แพ้อาหารอะไร" แสดงเฉพาะเมื่อผู้ลงทะเบียนติ๊กว่าต้องการอาหารพิเศษ ช่วยให้คนส่วนใหญ่เห็นฟอร์มสั้น ๆ ขณะที่ผู้จัดงานยังได้ข้อมูลครบจากคนที่จำเป็นต้องให้
กำหนดได้ว่าข้อมูลไหนไปโผล่ที่ไหน
ไม่ใช่ทุกฟิลด์ที่ควรแสดงในทุกหน้าจอ แต่ละฟิลด์จึงควรตั้งได้ว่า
- แสดงในตารางรายชื่อ — สำหรับข้อมูลที่ทีมงานต้องเห็นตอนค้นหา เช่น หน่วยงาน
- แสดงตอนเช็คอิน — สำหรับข้อมูลที่เจ้าหน้าที่หน้างานต้องเห็นทันทีที่สแกน เช่น ข้อจำกัดด้านอาหาร หรือรุ่นที่ลงแข่ง
- รวมในไฟล์ส่งออก — สำหรับข้อมูลที่ต้องใช้ทำรายงาน แต่ไม่จำเป็นต้องรกหน้าจอระหว่างงาน
ผลที่ได้เมื่อฟอร์มปรับเองได้
- เปิดรับสมัครได้เร็วขึ้น — จากที่ต้องรอทีมพัฒนาเป็นสัปดาห์ เหลือตั้งค่าเองไม่ถึงสิบนาที
- ข้อมูลอยู่ที่เดียว — ไม่ต้องจับคู่ไฟล์จากหลายแหล่งก่อนวันงาน
- กรองและทำรายงานได้จริง — เมื่อข้อมูลอยู่ในฟิลด์ที่ถูกต้อง ระบบจะสร้างตัวกรองให้อัตโนมัติ เช่น กรองตามจังหวัดหรือประเภทผู้เข้าร่วม
- ใช้ซ้ำกับงานหน้าได้ — ฟอร์มที่ออกแบบไว้ดีแล้วนำไปเป็นต้นแบบของงานถัดไปได้