พื้นฐาน UX Research ฉบับ Nielsen Norman Group: เข้าใจผู้ใช้ก่อนเขียนโค้ด

ฟีเจอร์ที่สร้างโดยไม่ถามผู้ใช้คือการพนันราคาแพง บทความนี้สรุปแนวทางจาก UX Research Cheat Sheet ของ Nielsen Norman Group อธิบายวิธีเลือกวิธีวิจัยให้ตรงคำถาม และเทคนิคทดสอบ Usability กับผู้ใช้เพียง 5 คนที่ทีมเล็กก็ทำได้

ทำไมต้องทำ UX Research ทั้งที่มีเดดไลน์

ความผิดพลาดที่แพงที่สุดในการพัฒนาซอฟต์แวร์คือการสร้างสิ่งที่ไม่มีใครใช้ การแก้ปัญหาการออกแบบหลังจากพัฒนาเสร็จแล้วมีต้นทุนสูงกว่าการแก้ตั้งแต่ขั้นออกแบบหลายเท่า เพราะต้องรื้อทั้งโค้ด เทสต์ และเอกสาร ขณะที่การคุยกับผู้ใช้ 5 คนก่อนเริ่มพัฒนาใช้เวลาเพียงไม่กี่วัน

Nielsen Norman Group (NN/g) ซึ่งเป็นสถาบันวิจัย UX ชั้นนำที่ก่อตั้งโดย Jakob Nielsen และ Don Norman ย้ำว่างานวิจัยผู้ใช้ควรทำต่อเนื่องตลอดวงจรผลิตภัณฑ์ ไม่ใช่พิธีการครั้งเดียวตอนเริ่มโครงการ คำถามที่ควรถามไม่ใช่ "มีเวลาทำวิจัยไหม" แต่คือ "คำถามไหนที่ถ้าตอบผิดแล้วเสียหายที่สุด"

เลือกวิธีวิจัยให้ตรงคำถาม: Qualitative กับ Quantitative

NN/g แบ่งวิธีวิจัยตามสองแกน แกนแรกคือเชิงคุณภาพ (ทำไม-อย่างไร) กับเชิงปริมาณ (เท่าไร-กี่คน) แกนที่สองคือทัศนคติ (สิ่งที่คนพูด) กับพฤติกรรม (สิ่งที่คนทำจริง) เช่น การสัมภาษณ์บอกได้ว่าผู้ใช้คิดอะไร แต่ Analytics บอกได้ว่าพวกเขาทำอะไรจริง ซึ่งสองอย่างนี้ขัดแย้งกันบ่อยกว่าที่คิด

หลักเลือกใช้แบบง่ายคือ ช่วงค้นหาปัญหา (Discovery) ใช้การสัมภาษณ์เชิงลึกและการสังเกตการทำงานจริง ช่วงออกแบบใช้การทดสอบ Usability กับ Prototype ช่วงหลังเปิดตัวใช้ Analytics, A/B Testing และแบบสำรวจ เพื่อวัดผลในสเกลใหญ่ การผสมทั้งสองฝั่งให้ภาพที่ครบกว่าการพึ่งวิธีเดียว

ทดสอบกับผู้ใช้แค่ 5 คนก็พอ

งานวิจัยคลาสสิกของ Jakob Nielsen แสดงว่าการทดสอบ Usability กับผู้ใช้เพียง 5 คน สามารถค้นพบปัญหาการใช้งานได้ราว 85% ของปัญหาที่มีอยู่ การทดสอบกับคนมากกว่านั้นในรอบเดียวให้ผลตอบแทนลดลง สู้เอางบไปทดสอบหลายรอบ รอบละ 5 คน หลังแก้ไขแต่ละครั้งดีกว่า

รูปแบบการทดสอบที่แนะนำคือให้ผู้ใช้ทำงานจริง เช่น "ลองสั่งซื้อสินค้าชิ้นนี้และเลือกจ่ายแบบเก็บเงินปลายทาง" พร้อมขอให้คิดออกเสียง (Think Aloud) ผู้ดำเนินการทดสอบต้องอดทนไม่ช่วย ไม่ชี้นำ และจดว่าผู้ใช้ติดตรงไหน เพียง 5 เซสชัน เซสชันละ 30-45 นาที ทีมจะได้รายการปัญหาที่จัดลำดับความสำคัญได้ทันที

สัมภาษณ์ผู้ใช้อย่างไรไม่ให้ได้คำตอบลวง

ข้อผิดพลาดยอดฮิตคือถามคำถามนำ เช่น "ฟีเจอร์นี้ดีไหม" ซึ่งผู้ใช้ชาวไทยส่วนใหญ่จะตอบว่าดีเพราะเกรงใจ เทคนิคที่ถูกต้องคือถามถึงพฤติกรรมในอดีตที่เกิดขึ้นจริง เช่น "ครั้งล่าสุดที่สั่งของออนไลน์ เล่าให้ฟังหน่อยว่าทำอย่างไรบ้าง ติดตรงไหน" เพราะสิ่งที่คนเคยทำทำนายพฤติกรรมได้ดีกว่าสิ่งที่คนบอกว่าจะทำ

ใช้คำถามปลายเปิด ตามด้วยการเจาะลึกว่า "ทำไม" และปล่อยให้ความเงียบทำงาน อย่ารีบเติมคำตอบให้ บันทึกเสียงหรือวิดีโอ (โดยขอความยินยอมตามหลัก PDPA) เพื่อให้ทีมกลับมาดูซ้ำได้ และสรุปเป็นประเด็น (Affinity Mapping) ร่วมกันทั้งทีมแทนที่จะให้คนเดียวตีความ

เปลี่ยนข้อมูลวิจัยเป็นการตัดสินใจของทีม

งานวิจัยจะไร้ค่าถ้าจบที่รายงานยาว ๆ ที่ไม่มีใครอ่าน NN/g แนะนำให้สรุปเป็นสิ่งที่ทีมใช้ตัดสินใจได้จริง เช่น รายการปัญหา Usability จัดลำดับตามความรุนแรง, Persona ที่สรุปจากข้อมูลจริงไม่ใช่จินตนาการ และ Journey Map ที่ชี้จุดที่ผู้ใช้ติดขัดมากที่สุด

วิธีที่ได้ผลที่สุดคือดึงทีมพัฒนาและผู้มีอำนาจตัดสินใจเข้ามาดูการทดสอบสด ๆ อย่างน้อยคนละ 1-2 เซสชัน เพราะการได้เห็นผู้ใช้จริงงุนงงกับหน้าจอที่ตัวเองสร้าง เปลี่ยนใจคนได้มากกว่าสไลด์สรุปสิบหน้า จากนั้นแปลงข้อค้นพบเป็น Backlog Item ที่มีเจ้าของและกำหนดเวลาชัดเจน