ทำไม User Testing ที่เหมาะสมต้องมีแค่ 5 คน ?
ก่อนจะไปพูดกันถึงเรื่อง User Testing บางคนคงอาจจะยังไม่คุ้นชิน หรือคุ้นเคยกับการทำ User Testing มาก่อน ถ้างั้นเรามาเริ่มต้นทำความเข้าใจ User Testing กันสักนิด
User Testing คืออะไร? เราทำไปทำไม? ถ้าสรุปเอาง่าย ๆ มันคือการที่เราทำการทดสอบการใช้งาน หรือความต้องการ, ปัญหา, เป้าหมายการใช้เว็บไซต์ หรือแอปพลิเคชันต่าง ๆ ของผู้ใช้ที่มีอยู่ในปัจจุบันแล้ว หรือยังไม่มีก็ตาม เราสามารถทำ User Testing ตามวัตถุประสงค์ในแต่ละหัวข้อที่เราต้องการได้ โดยการทำ Test ก็มีหลายวิธีมาก ๆ ในวงการ UX/UI ไม่ว่าจะเป็นการทำ A/B Testing, User Interview หรือการทำ Survey Form เป็นต้น
แล้วการทำ User Testing ได้ประโยชน์อะไร?
ต้องขอเท้าความย้อนกลับไปก่อนสัก 10-20 ปีที่แล้ว สมัยที่ UX/UI ยังไม่เป็นที่รู้จักขนาดนี้ ต้องบอกว่าช่วงยุคแรกของการออกแบบเว็บไซต์ หรือแอปพลิเคชัน เราเริ่มด้วยวิธีการที่คล้ายการกับสร้างตึก คือ
- เราต้องมีการคุย Scope งานกันให้ชัด
- หาสถาปนิกมาออกแบบวางแผนผังของตึก
- หาทีมวิศวกรรมมาคำนวณให้ตึกนี้มีความเป็นไปได้ที่จะสร้างได้เสร็จภายในระยะเวลาเท่าไหร่
- แล้วทีมก่อสร้างช่วยกันเนรมิตตึกนี้ให้ออกมาอย่างที่สถาปนิกออกแบบไว้
ทั้งหมดนี้เราจะเห็น plattern การทำงานที่ค่อนข้างชัดเจนต้องแต่เริ่มวางแผน วางระยะเวลา เลือกหาทีมงาน หาวัสดุมาใช้ ต่าง ๆ นา ๆ จนตึกนี้สำเร็จเสร็จสิ้นออกมาเป็นตึก 1 ตึก แต่คำถามอยู่ที่ว่าแล้วถ้าตึกใบนี้การใช้งานที่ไม่เหมาะกับผู้อยู่อาศัยหละ เราสามารถปรับเปลี่ยนได้ไหม คำตอบคือได้ แต่บางทีเราอาจต้องทุบบางอย่างออก แล้วเทปูนทับขึ้นไปใหม่ โอ้ แม่เจ้า
Construction Worker, Unsplash
เช่นเดียวกันงานออกแบบเว็บไซต์ หรือแอปพลิเคชัน ในช่วงยุคแรกก็มีขั้นตอนการทำงานเหมือนการสร้างตึกในอดีต แล้วปัญหาที่ตามมาคือ เราสร้าง product ออกมาแล้วไม่มีผู้ใช้ หรือผู้ใช้พบว่าใช้การใช้งานมันค่อนข้างมีปัญหา ซับซ้อน ยากซะเหลือเกิน แล้วเราในเหล่าผู้พัฒนาสามารถปรับเปลี่ยนแก้ไขได้ไหม ในเมื่อทรัพยากรที่เรามีไม่ว่าจะเป็น เงินลงทุน หรือเวลา ที่ใช้มาตั้งแต่ต้น project มันกำลังจะติดลบแล้ว ท้ายสุดที่สุดหลาย product ที่ถูกสร้างออกมาสู่ตลาดก็ต้องยอมปล่อยออกมาก่อนทั้ง ๆ ที่คุณภาพยังไม่ถึงอย่างที่ตั้งไว้ด้วยข้อจำกัดทางด้านเงินลงทุน และเวลาที่มีอยู่จำกัดนั่นเอง
ปัจจุบันปัญหาเรื่องของการสร้าง product ออกมาแล้วไม่ตรงตามเป้าหมายที่วางไว้ก็ค่อย ๆ จางหายไปด้วยการเปลี่ยน process การทำงานให้เริ่มมีการทำ User Testing ควบคู่ไปด้วยกับช่วงการพัฒนา product เลยหรือวิธีการทำงานแบบนี้หลายคนอาจจะคุ้นเคยในคำที่ว่า Agile
แต่ Agile หลายคนบอกว่ามันคือ Culture ของการทำงานรูปแบบหนึ่งในทีม หรือมันคือวิธีการทำงานในรูปแบบหนึ่งที่เน้นการพูดคุย สื่อสารเป็นหลัก เมื่อสื่อสารกันบ่อยทีมก็จะเข้าใจกันยิ่งขึ้น เมื่อทีมเข้าใจกันยิ่งขึ้น ปัญหาที่มีในโปรเจกต์นั้น ๆ ก็จะได้รับการหาสาเหตุและแก้ไขได้รวดเร็วตามคำว่า Agility ก็แล้วแต่สำนักที่นิยามคำว่า Agile ออกไป แต่ที่สำคัญถ้าทุกคนอ่านมาถึงตรงนี้ ไม่ว่า Agile จะอยู่ในรูปแบบไหนของแต่ละองค์กร เราไม่ควรไปตัดสินว่านี่คือ Agile นี่ไม่ใช่ Agile เพราะจากประสบการณ์ที่ทำงานในสายงานนี้มาต้องบอกว่า Agile ไม่ใช่ 0 หรือ 1 แต่มันสามารถวัดค่าได้ด้วยปริมาณ (Volumn) บางองค์กรมีมาก มีน้อย แค่นั้นเอง แต่มีน้อยไม่ได้แปลว่าผิด หรือไม่ใช่ Agile
เอาหละมาถึงตรงนี้กันแล้วเราจะเข้าเรื่องกันเลยละกันว่า
ทำไมการทำ User Testing ถึงต้องมี(แค่) 5 คน?
สำหรับสายงาน UX/UI มักเจอคำถามว่าการทำ User Testing ต้องใช้คนกี่คน และแต่ละคนต้องมีนิสัย หรือหน้าที่การทำงานที่ต่างกันไหม ถ้าต่างกันมากน้อยขนาดไหน? เรามีงบให้คุณทำ research นะ เอามากกว่า 5 คนได้ไหม? และเหล่า Designer ก็มักจะยืนยันคำเดิมและตอบว่า 5 คน เพราะเลขนี้คือ “The Magic Number” ของการทำ User Testing ที่ถูกใช้ และพูดกันอย่างแพร่หลายในวงการของ UX/UI Design
Meeting People, Unsplash
โดยตัวเลข 5 นี้เกิดมาจากวิจัยของ Jakob Nielsen กูรูด้าน Usability Engineering และ Thomas K. Landauer ชื่อ A Mathematical Model of the Finding of Usability Problems ที่ตีพิมพ์ในปี 1993
ในงานวิจัย Jakob Nielsen ได้ทำการทดลองหาตัวเลขที่เหมาะสมของการทำ User Testing โดยเขาได้เลือกทำ Usability Testing (ทดสอบการใช้งานเพื่อหาปัญหาการใช้งานของ User เพื่อนำมาพัฒนาและปรับปรุงแก้ไขต่อไป) ของ product ชิ้นหนึ่ง ผลสรุปความสัมพันธ์ของจำนวน Usability Issue และจำนวน User ที่เข้าร่วมทดสอบ พบว่าจำนวนของปัญหาจะมีมากขึ้นเรื่อย ๆ ในช่วง 1-5 คนแรก จากนั้นคน 6 เป็นต้นไป การพบปัญหาจะเป็นการพบปัญหาซ้ำ ๆ แต่จะมีปัญหาใหม่เพิ่มขึ้นมาบ้างเล็กน้อยกว่า 1-5 คนก่อนหน้
กราฟแสดงสัดส่วนของปัญหาการใช้งาน Interface แบบ การประเมินแบบฮิวริสติก (heuristic evaluation) โดยใช้ผู้ประเมินจำนวนต่างกัน ส่วนเส้นโค้งแสดงถึงค่าเฉลี่ยของ 6 กรณีศึกษาของ heuristic evaluation (Image: nngroup.com)
หลังจากได้ข้อสรุปนี้ Jacob Nielsen จึงนำเอาจำนวน Usability Issue ที่เจอมาเทียบกับราคาการทำ Usability Test และได้ข้อสรุปว่า การทำ Usability Test ให้คุ้มค่ากับเงินลงทุนที่เสียไปมากที่สุด จะอยู่ที่ 3.2 คนต่อรอบ และหากใช้วิธีการทำ Heuristic Evaluation จะต้องใช้ 4.4 คนต่อรอบ
กราฟแสดงจำนวนครั้งของ benefit หรือผลประโยชน์ที่มากกว่าต้นทุนสำหรับการประเมินแบบฮิวริสติก จำนวนผู้ประเมินที่เหมาะสมที่สุดในตัวอย่างนี้คือ 4 คน โดยมีผลประโยชน์มากกว่าต้นทุน 62 เท่า (Image: nngroup.com)
สรุปแบบเข้าใจง่าย
การทำ User Testing ในแต่ละรอบนั้นต้องใช้ทรัพยากรที่มีอยู่ของทีมไม่ว่าจะเป็นเงินลงทุน (ค่ารถ ค่าอาหาร ค่าเสียเวลาของผู้ที่ถูกสัมภาษณ์) หรือเวลาที่เสียไป ทำให้การทำ User Testing ในจำนวนที่เกิน 5 คนขึ้นไปมันทำให้ไม่คุ้มค่ากับทรัพยากรที่เสียไปเมื่อแลกกับผลลัพธ์ที่ได้มา
ไม่ใช่ว่าการทำ User Testing จำนวน 5 คนจะได้ Usability Issue ที่มากกว่าการทำ User Testing จำนวน 6-10 คนต่อรอบ แต่เป็นเพราะการทำ User Testing คนที่ 6 ขึ้นไปเป็นการหา Usability Issue ใหม่ ๆ ที่ได้มาค่อนข้างไม่คุ้มค่าเท่ากับการทำ User Testing 1-5 คนแรกนั่นเอง
Reference :
- How to Conduct a Heuristic Evaluation
- A Mathematical Model of the Finding
- Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods.
![Senna Labs](/_next/image?url=%2Fsenalabs.jpg&w=3840&q=75)
![](/_next/image?url=%2Fimages%2Fsubscribe.webp&w=3840&q=75)
Subscribe to follow product news, latest in technology, solutions, and updates
บทความอื่นๆ
Let’s build digital products that are simply awesome !
We will get back to you within 24 hours!ติดต่อเรา![](/_next/image?url=%2Fimages%2Ftell-us-arrow.webp&w=384&q=75)
![Contact ball](/_next/image?url=%2Fimages%2Fcontact-ball.webp&w=3840&q=75)
![Contact us bg 2](/_next/image?url=%2Fimages%2Fcontact-us-bg-2.webp&w=3840&q=75)
![Contact us bg 4](/_next/image?url=%2Fimages%2Fcontact-us-bg-4.webp&w=3840&q=75)
![Contact us bg 1](/_next/image?url=%2Fimages%2Fcontact-us-bg-1.webp&w=3840&q=75)
![Ball left](/_next/image?url=%2Fimages%2Fball-left.png&w=1080&q=75)
![Ball right](/_next/image?url=%2Fimages%2Fball-right.png&w=1920&q=75)
![Ball left](/_next/image?url=%2Fimages%2Fball-left.png&w=256&q=75)
![Ball right](/_next/image?url=%2Fimages%2Fball-right.png&w=384&q=75)
![Sennalabs gray logo](/_next/image?url=%2Fimages%2Fsennalabs-gray-logo.webp&w=256&q=75)