วิจัยผู้ใช้ก่อนออกแบบ เพื่อไม่เดาโจทย์ผิด

ทำ Research เมื่อไหร่ ก่อนลงดีไซน์

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

ถ้าโครงสร้างและ Flow ชัดอยู่แล้ว อาจข้ามไปขั้นออกแบบหน้าจอได้ โดยไม่ต้องวิจัยยาวทุกครั้ง

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

หลังสัมภาษณ์และสังเคราะห์โจทย์ พบว่าคนหาแพ็กเกจและสถานะไม่เจอในเส้นทางหลัก เมื่อแยกโซนขายกับโซนสมาชิกและออกแบบ flow เคลมสั้นลง — สายถามสถานะลด 38% ใน 90 วัน และเคลมใหม่ 62% เริ่มจากเว็บ

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

สิ่งที่ต้องเคลียร์ก่อนเริ่มเก็บข้อมูล

ก่อนนัดสัมภาษณ์ ควรมีคำถามธุรกิจที่อยากได้คำตอบ และกลุ่มคนที่ควรคุย

การเก็บข้อมูลโดยไม่มีคำถามนำมักได้โน้ตเยอะแต่สรุปไม่ได้

01

สิ่งที่ควรเคลียร์ก่อนเก็บข้อมูล

แกนเหล่านี้ทำให้ research ไม่กลายเป็นคุยเล่น

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

ขอบเขตงานที่ส่งมอบจริง

สิ่งที่ได้หลังจบงานควรใช้ต่อได้ทันที: insight ที่เรียงลำดับ และคำแนะนำว่าขั้นถัดไปควรเป็น IA, Flow หรือ UI — ไม่ใช่สไลด์ยาวที่ไม่มีคนกล้าตัดสินใจ

เราวางแผนวิธีเก็บข้อมูล สัมภาษณ์หรือสำรวจตามขอบเขต สังเคราะห์เป็นรายการปัญหา แล้วส่งต่อทีมออกแบบพร้อมขอบเขตแนะนำ

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

ลำดับงาน และสิ่งที่มักพังถ้าข้าม Research

ลำดับที่คุ้มคือ คำถามธุรกิจ → เก็บข้อมูล → สังเคราะห์ → เวิร์กช็อปสั้นกับทีม → ส่งต่อ IA/Flow

ถ้าข้ามไปออกแบบเลย มักเจอว่าต้องรื้อโครงหลังผู้ใช้จริงเข้ามาใช้ — ต้นทุนสูงกว่าการเก็บหลักฐานรอบสั้นตอนต้น