การทดสอบการใช้งานมีชื่อเสียงที่ไม่น่าสนใจในการแพงและช้า เมื่อผู้คนได้ยินคำว่า "การวิจัยผู้ใช้" พวกเขาจะนึกภาพว่ามีกระจกเงา วิทยากร ที่มีคลิปบอร์ด และกำหนดเวลาสองสัปดาห์ เวอร์ชันนั้นของการทดสอบมีอยู่และมีประโยชน์ของมัน แต่นั่นไม่ใช่เวอร์ชันที่ทีมผลิตภัณฑ์ส่วนใหญ่จำเป็นต้องใช้
เวอร์ชันที่ทีมส่วนใหญ่ต้องการนั้นง่ายกว่า: ผู้ใช้ห้าคน โปรโตไทป์ Figma หรือสภาพแวดล้อมการเตรียมการ สายวิดีโอ และ 45 นาทีต่อเซสชัน เมื่อทำได้ดี นี่คือพื้นผิวส่วนใหญ่ของปัญหาการใช้งานที่ร้ายแรง ก่อนการจัดส่ง ทำได้อย่างสม่ำเสมอ — แม้ว่าเพียงครั้งต่อ sprint — มันจะสร้างปรับปรุงแบบประนีประนวมในคุณภาพผลิตภัณฑ์ที่ไม่มีวิเคราะห์หลังการเปิดตัวใด ๆ สามารถเลียนแบบได้
นี่คือวิธีการดำเนินการตั้งแต่เริ่มต้น
ผู้เข้าร่วมห้าคนเป็นจำนวนที่ถูกต้องสำหรับการทดสอบการใช้งานส่วนใหญ่ งานวิจัยของ Jakob Nielsen ได้กำหนดว่าผู้ใช้ห้าคนค้นพบปัญหาการใช้งานประมาณ 85% โดยมีผลตอบแทนลดลงหลังจากนั้น การเรียกใช้เซสชันสามเซสชันของผู้ใช้ห้าคนที่จุดต่างๆ ในกระบวนการออกแบบจะมีคุณค่ามากกว่าเซสชันเดียวที่มีสิบห้า
เกณฑ์สำหรับการสรรหามีความสำคัญมากกว่าจำนวน การทดสอบการใช้งานด้วยคนห้าคนที่ตรงกับบุคลิกภาพผู้ใช้เป้าหมายของคุณจะเปิดเผยปัญหาจริง การทดสอบกับสิบห้าคนที่ไม่ตรงกันจะสร้างเสียงรบกวน กำหนดเกณฑ์การคัดกรองสองหรือสามข้อ — บทบาท บริบทของการใช้งาน ระดับความสะดวกสบายทางเทคนิค — และปฏิบัติตามเกณฑ์เหล่านั้น
เส้นทางการสรรหาที่เร็วที่สุดสำหรับทีมส่วนใหญ่คืออีเมลผู้ใช้ที่มีอยู่ซึ่งได้รับการติดต่ออนุญาต เสนอแรงจูงใจที่เล็กน้อย — บัตรของขวัญ 20 ปอนด์นั้นเพียงพอสำหรับเซสชัน 45 นาที พยายามกำหนดตารางเซสชันภายในสัปดาห์เดียวกัน ยิ่งช่องว่างระหว่างการสรรหาและการทดสอบนานเท่าไหร่ อัตราการไม่เข้าร่วมก็จะสูงขึ้นเท่านั้น
ข้อผิดพลาดในการเขียนสคริปต์ที่พบบ่อยที่สุดคือการเขียนงานเป็นคำแนะนำ: "คลิกที่ การตั้งค่า จากนั้นนำทางไปที่ การแจ้งเตือน และเปลี่ยนค่ากำหนดของคุณเป็น..." สิ่งนี้บอกผู้ใช้ว่าต้องทำอะไร ซึ่งหมายความว่าคุณกำลังทดสอบว่าพวกเขาสามารถทำตามคำแนะนำได้หรือไม่ ไม่ว่าอินเทอร์เฟซจะใช้งานได้ง่ายหรือไม่
เขียนงานเป็นสถานการณ์แทน: "ลองนึกภาพว่าคุณกำลังรับการแจ้งเตือนมากเกินไปและต้องการได้รับการแจ้งเตือนเพียงเมื่อใครบางคนพูดถึงคุณโดยตรง แสดงให้ฉันเห็นว่าคุณจะทำอะไร" สิ่งนี้ให้ผู้ใช้เป้าหมายที่สมจริง และช่วยให้คุณสังเกตการณ์ว่าพวกเขาเดินทางไปอย่างไร — รวมถึงที่พวกเขาสับสน
ส่วนที่ยากที่สุดของการดำเนินการเซสชันการทดสอบการใช้งานคือการต้านทานแรงปรารถนาที่จะช่วย เมื่อผู้ใช้สับสน สัญชาตญาณทุกอย่างบอกให้กระโดดเข้าไปและแสดงว่าต้องคลิกที่ไหน แต่ความสับสนนั้นคือข้อมูล ผู้ใช้ที่ดิ้นรนกำลังบอกคุณว่ามีบางอย่างผิด ๆ กับอินเทอร์เฟซ — และในช่วงเวลาที่คุณแทรกแซง คุณจะสูญเสียสัญญาณ
ขอให้ผู้ใช้คิดออกเสียงตลอดเซสชัน: "ขณะที่คุณไป เพียงบอกฉันว่าคุณกำลังดูอะไรและคิดอะไร" สิ่งนี้ทำให้เกิดกระแสข้อมูลต่อเนื่องเกี่ยวกับแบบจำลองจิตใจของพวกเขา สังเกตการณ์ไม่ใช่เพียงข้อผิดพลาด แต่ยังหยุดชั่วขณะด้วย — ผู้ใช้ที่หยุดชั่วขณะเป็นเวลาสามวินาทีก่อนคลิกปุ่มที่ถูกต้องยังคงเผยให้เห็นปัญหาการออกแบบ แม้ว่าพวกเขาจะสำเร็จในที่สุด
ขั้นตอนการสังเคราะห์คือที่สร้างมูลค่าส่วนใหญ่ — และที่ทีมส่วนใหญ่ลดจุด หมายเหตุดิบจากเซสชันห้าเซสชันไม่ใช่สิ่งที่ค้นพบ พวกเขากลายเป็นผลการค้นพบเมื่อคุณหารือ ระดับปกติกลุ่มการสังเกตการณ์ และกำหนดอัตราความรุนแรง
ดำเนินการกลับมาหารือในวันเดียวกับเซสชัน ในขณะที่การสังเกตการณ์ยังสด จัดกลุ่มปัญหาเป็นสามกลุ่ม: วิกฤต (ผู้ใช้ไม่อาจทำงานให้เสร็จสิ้น) ปานกลาง (ผู้ใช้ทำงานให้เสร็จสิ้น แต่มีความยากลำบากหรือข้อผิดพลาดที่มีนัยสำคัญ) และรองแรม (การแปลกแยกที่ไม่ได้ป้องกันการเสร็จสิ้น) ปัญหาวิกฤตจำเป็นต้องแก้ไขก่อนการเปิดตัว ปัญหาปานกลางควรจัดลำดับความสำคัญในการพิมพ์ถัดไป ปัญหารองแรมไปอยู่ในการสำรองข้อมูล
เขียนผลการค้นพบในหนึ่งหน้า: ปัญหาวิกฤตสามอันดับแรก โดยมีหลักฐานจากผู้เข้าร่วมอย่างน้อยสองคน และการเปลี่ยนแปลงการออกแบบที่เสนอสำหรับแต่ละอัน สิ่งใดที่ต้องการพื้นที่มากกว่านั้นจะอยู่ในเอกสารแยกต่างหาก