ต้องทำ User Test กี่คนถึงจะพอ?
ผมเชื่อว่าคนในสายงาน UX Design มักจะต้องเจอกับคำถามนี้บ่อย เวลาต้องทำ user test: “ระบบเรามีคนใช้ตั้ง X คน แต่ทำ Test กับแค่ Y คน จะเพียงพอหรอ”
ในที่นี้ X จะเท่ากับ หมื่น, แสน, หรือ ล้าน คน ก็ขึ้นอยู่กับ Product ที่คุณทำ
แต่สำหรับ Y นั้น UX Designer หลายๆ ท่าน จะตอบว่า 5 คน เพราะตัวเลขนี้คือ “The Magic Number” ของการทำ User Test ที่ถูกใช้ และพูดกันอย่างแพร่หลายในวงการของพวกเรา ในบทความนี้เรามาทำความเข้าใจกับตัวเลขนี้กัน แต่หากคุณยังไม่คุ้นเคยกับคำว่า User Test หรือ Usability Testing ผมแนะนำให้อ่านบทความ Usability Testing 101 by Kate Moran ก่อน
ที่มาของเลข 5 “The Magic Number”
ที่มาของแนวคิด ที่ว่าทดสอบกับจำนวน 5 คนนั้นเพียงพอ นั้นเริ่มมาจากบทวิจัยของ Jakob Nielsen ผู้เป็นกูรูด้าน Usability Engineering และ Thomas K. Landauer ชื่อ A Mathematical Model of the Finding of Usability Problems ที่ตีพิมพ์ในปี 1993
ในงานวิจัยนั้น Jakob Nielsen ได้นำผลสรุปจากการทำ Usability Test จำนวน 11 ครั้ง มาใส่สูตรคณิตศาสตร์ เพื่อดูถึงความสัมพันธ์ของจำนวน Usability Issue และจำนวน User ที่เข้าร่วมทดสอบ ว่าจะเป็นอย่างไร ผลสรุปตามที่แสดงในกราฟด้านล่างคือ จำนวนปัญหา Usability Issue ที่เจอจะเพิ่มขึ้นเรื่อยๆ ในช่วงคนแรกๆ ที่เราทำการทดสอบด้วย แต่หลังจากนั้น เราจะพบจำนวนปัญหาใหม่น้อยลงไปเรื่อยๆ
หลังจากได้ข้อสรุปนี้ Jacob Nielsen จึงนำเอาจำนวน Usability Issue ที่เจอมาเทียบกับราคาการทำ Usability Test ณ เวลานั้น และได้ข้อสรุปว่า การทำ Usability Test เพื่อให้ได้จำนวนปัญหาที่คุ้มค่ากับเงินที่เสียไปมากที่สุด จะอยู่ที่ 3.2 คนต่อรอบ และหากใช้วิธีการทำ Heuristic Evaluation จะต้องใช้ 4.4 คนต่อรอบ ตามภาพประกอบด้านล่าง
ในบทวิจัยนั้น จะมีกราฟและสมการอีกหลายอัน ที่ผมนั่งอ่านแล้วอ่านอีก ก็ยังต้องเกาหัวและไม่เจอคำตอบที่ผมตามหา ผมจึงตัดสินใจทำการทดลองด้วยตัวเอง ตามคำโบราณที่ว่า “สิบปากว่าไม่เท่าตาเห็น”
ลงมือลองทำจริง
เราทำการทดสอบโดยใช้การทำ Formative Usability Test กับ user จำนวน 15 คน และทำการนับจำนวน Usability Issues ที่ได้เจอจากการทดสอบแต่ละครั้ง ซึ่งเราตั้งสมมติฐานไว้ว่า หาก 5 คน คือ“The Magic Number” จริง หลังจากที่เราทดสอบกับคนที่ 5 เสร็จ เราไม่ควรเจอปัญหา Usability Issues ใหม่ๆ (ที่ยังไม่เคยเจอใน 1–4 คนแรก) เพิ่มขึ้นมากนัก
เพื่อให้สิ่งที่เราทำเป็นประโยชน์กับคอมมูนิตี้ Thai Gov Design ไปด้วย เราจึงเลือกทำการทดสอบบน เว็บไซต์ และ แอพพลิเคชั่น ของภาครัฐ โดยโจทย์ที่เราใช้ในการทดสอบคือ
- ใช้เว็บไซต์กรมควบคุมโรค ดูสถานการณ์โควิท 19 ในประเทศไทย
- ใช้เว็บของกรมสรรพากร หาวิธีคำนวณภาษีเงินได้บุคคลธรรมดา
- ทำการจองคิวเพื่อ ทำใบขับขี่ผ่านแอพฯ DLT Smart Queue
เราทำการทดสอบครั้งนี้ตอนช่วง เดือนธันวาคม 2020 และ ณ ปัจจุบัน หลายๆ เว็บได้ปรับเป็น version ใหม่แล้ว รวมถึง insight ต่างๆ ที่เกี่ยวกับโควิท 19 ก็มีการเปลี่ยนแปลงไปตามสถานการณ์ในปัจจุบัน
ผลการทดสอบเว็บไซต์กรมควบคุมโรค
โจทย์ของเราคือ ใช้เว็บไซต์กรมควบคุมโรค เพื่อดูสถานการณ์โควิท 19 ในประเทศไทย
ผลจากการทดสอบกับ User 5 คนแรก เราเจอ 10 ปัญหา, เมื่อครบ 10 คน พบจำนวน 13 ปัญหา และ เมื่อครบ 15 คน เราพบทั้งหมด 15 ปัญหา (ปัญหาที่พบซ้ำ จะนับรวมกันเป็น 1 ปัญหา)
ใน 3 คนแรก ปัญหาซ้ำๆ ที่เราพบได้ เช่น เรื่องของ User แยกความแตกต่างของข้อมูลลำบาก การใช้สีชมพูในหน้าจอมากเกินไปและมีความใกล้เคียงกับสีแดง และอีกปัญหาคือ User ความเข้าใจต่อคำว่า “สตม.แจ้งวัฒนะ” ว่าทำไมถึงเป็นตัวเลขผู้คัดกรองสะสม ทั้งๆ ที่อยู่ในกรุงเทพฯ แต่ไม่ใช่ชายแดน
ผลการทดสอบเว็บกรมสรรพากร
โจทย์ของเราคือ ให้ใช้เว็บของกรมสรรพากร เพื่อหาวิธีคำนวณภาษีเงินได้บุคคลธรรมดาที่ต้องยื่นตอนสิ้นปี
ในการทดสอบกับ User 5 คนแรก เราเจอ 24 ปัญหา เมื่อครบ 10 คน จะเจอ 32 ปัญหา และเมื่อครบ 15 คน เราพบทั้งหมด 34 ปัญหา
ซึ่งโจทย์ที่เราให้ในเว็บกรมสรรพากรนั้น จะซับซ้อนและยากกว่าโจทย์ของเว็บไซต์กรมควบคุมโรค เพราะตัวเว็บเองก็มีหลายหน้าจอและมีทางแยกหลายวิธีที่จะทำให้ task สำเร็จ จึงไม่แปลกใจ ที่เราจะพบปัญหาเยอะมากกว่าเดิม ปัญหาที่เราพบซ้ำๆ กัน ตั้งแต่การทดสอบครั้งแรก มีหลายปัญหา เช่น…
User ไม่รู้ว่าตัวเองต้องเลือกยื่นด้วย ภ.ง.ด. อันไหน ปัญหานี้เราพบตั้งแต่ User คนแรก และเจอซ้ำๆ กันทั้งหมด 5 คน
ในหน้า Landing Page, User คาดหวังที่จะหาของที่ต้องการใน 4 ปุ่มหลัก โดยไม่ได้คิดถึงการเข้าหน้าหลัก หรือ การคุยผ่าน Chat Bot ซึ่งปัญหานี้เราเริ่มเจอใน User คนที่สอง และเจอปัญหาซ้ำกัน 5 คน
User หาทางกลับไปหน้าจอเดิมไม่ได้ เพราะ link ที่กดจะเปิด Tab ใหม่อัตโนมัติ โดยไม่รู้ตัว ซึ่งปกติการที่ user จะเปิด tab ใหม่ จะเป็นคนทำด้วยตัวเอง ไม่ได้คาดหวังอะไรที่เป็น อัตโนมัติ ซึ่งเราเริ่มเจอปัญหานี้กับ User คนที่ห้าและปัญหาเจอซ้ำกัน 3 คน
ผลการทดสอบแอพฯ DLT Smart Queue
โจทย์ของเราคือ ให้ทำการจองคิวทำใบขับขี่ผ่านแอพฯ DLT Smart Queue
ผลการทดสอบแอพฯ DLT Smart Queue กับ User 5 คนแรก เราเจอ 28 ปัญหา เมื่อครบ 10 คน เราพบ 35 ปัญหา และเมื่อครบ 15 คน เราพบ 40 ปัญหา
ปัญหาใหญ่ๆ ส่วมมากของแอพนี้เราเจอตั้งแต่การทดสอบกับ 3 คนแรก เช่น…
User ไม่เข้าใจ UI สำหรับการเลือกเวลา ซึ่งเราเริ่มเจอปัญหานี้ตั้งแต่ User คนแรกและเจอปัญหานี้ซ้ำกัน 6 คน
เมื่อคนเลือกผิดแล้วมาปุ่ม Back ไม่ได้เลยต้อง Kill app แล้วเข้าใหม่ ซึ่งเราเริ่มเจอปัญหานี้กับ User คนที่ 2 และเราเจอซ้ำกัน 3 คน
คนเข้าใจ Icon ที่ใช้แทนวันเกิดผิด คิดว่าเป็นวันที่ให้ตัวเลือก ซึ่งเราเจอเริ่มปัญหากับ User คนแรกและเจอซ้ำถึงกัน 7 คน
ข้อสรุปการผลการทดสอบครั้งนี้
ในกราฟผมเอาจำนวน Usability Issue ที่เจอจากการทดสอบ User 15 คนเป็นตัวตั้ง และนำจำนวนของ Usability Issue ในแต่ละช่วงมาหารเป็น Percentage เพื่อที่จะเทียบกันได้ ซึ่งเราจะพบว่า…
- เมื่อทำการทดสอบกับ User 5 คน เราจะเจอปัญหาอยู่ที่ประมาณ 70% ของทั้งหมด
- เมื่อทดสอบครบ 7 คน เราจะเจอปัญหาอยู่ที่ 80–85%
- หลังการทดสอบกับคนที่ 11 เราแทบไม่เจอปัญหาใหม่อีกเลย
นั่นแปลได้ว่า 7 คน คือ “The New Magic Number” ไหม? ตัวผมเองไม่คิดว่าการทดสอบกับ 2 websites และ 1 application นั้นจะช่วยยืนยันได้ชัดเจนว่า ตัวเลข 5 คือถูกต้องจริงๆ หรือไม่ (ในบทวิจัยของ Jakob Nielsen เขาสรุปจากผลการทดสอบ 11 ครั้ง) แต่ที่สิ่งที่พบได้ชัดเจนจากการทดลองนี้ คือคือ ตัวเลข Magic Number นั้นอยู่ในช่วง 5 ถึง 10 คน และการทดสอบมากกว่านั้นมันไม่คุ้มกับเงินและเวลาในการหา Usability Issue แล้ว
ณ ตอนนี้เหมือนคุณจะได้คำตอบแล้วใช่ไหม? แต่!! อย่าพึ่งไปไหนกัน ถ้าคุณไม่ได้อ่าน Important Note ด้านล่างนี้ มันจะเหมือนกับการที่คุณกินยาโดยไม่ได้อ่านฉลาก
Important Note!
- อย่าแปลผิดว่ากับ Product ตัวหนึ่ง คุณแค่ทดสอบมันกับ User 5–10 คน แล้วจะไม่ต้องทดสอบอีกเลย ซึ่งในความเป็นจริง ตัวเลขนี้มีไว้สำหรับใช้กับการทดสอบ 1 รอบ นั่นแปลว่า หากคุณมีงบสำหรับทำการทดสอบกับ User 30 คน แทนที่คุณทำ Test กับ User 30 คนในรอบเดียวให้เสร็จ คุณอาจจะแบ่งเป็นหลายรอบ รอบเล็กๆ รอบละ 5–10 คน เพื่อทดสอบ ซึ่งในแต่ละรอบของการทดสอบ ให้ปรับ Product ของคุณ ตาม Feedback ที่ได้รับในแต่ละรอบ เพื่อให้ iteration การพัฒนาที่เร็วขึ้น และพร้อมกับการทดสอบรอบต่อๆไป
- การทดสอบครั้งนี้ เป็นการทำแบบ Formative Test นั้นคือ เป็นการทดสอบเพื่อหาจำนวนปัญหา Usability Issue ที่มีในระบบปัจจุบัน ซึ่งจะต่างกับ Summative Test ที่เป็นหาว่า Issue ที่มีอยู่นั้น สร้างผลกระทบให้กับ user ทั้งหมดที่ใช้งานมากน้อยแค่ไหน เพื่อให้ได้ผลที่เชื่อถือ ต้องทำการทดสอบกับ User จำนวนเยอะขึ้นมาก จากประสบการณ์ของผม จะใช้ User ประมาณ 20–30 คน ต่อการทำการทดสอบ 1 task หากถ้าสนใจเรื่องนี้เพิ่มเติม ผมแนะนำให้อ่านหนังสือชื่อ Quantifying the User Experience : Practical Statistics for User Research
- ไม่ใช่ทุก Usability Issue ที่เราเจอจะมีความสำคัญเท่ากัน บางปัญหาเป็นเรื่องใหญ่ที่ส่งผลกับสิ่งที่ User ต้องการจะทำโดยตรง บางปัญหาเป็นเรื่องเล็กที่แค่สร้างความรำคาญใจให้กับ User ที่ใช้งาน ในการทดสอบกับเว็บของกรมสรรพากรและ แอพฯ DLTSmartQueue เราพบว่าปัญหาใหญ่มักจะถูกเจอกับ User ที่ทดสอบด้วยคนแรกๆ และมักจะเจอซ้ำๆ กันจนไปถึง User คนสุดท้าย แต่ในการทดสอบเว็บไซต์กรมควบคุมโรคเราไม่เจอ Pattern แบบนี้ ซึ่งอาจจะเป็นเพราะโจทย์ที่ให้ค่อนข้างตรงไปตรงมาจึงทำให้ไม่เจอปัญหาใหญ่มากนัก
- ไม่ว่าจะเป็นการ Test แบบไหนก็ตาม คุณต้อง Test กับ User ให้ถูกกลุ่ม ถ้าคุณทำเว็ปขายรองเท้าสกี ต่อให้คุณไปทำ Test ทำ Gamer 100 คนที่ไม่สนใจกีฬาเลย ก็ไม่มีดีเท่ากับการ test กับนักสกี 1 คน และในการทดสอบแต่ละครั้ง คุณควรจะต้องควบคุมและคัดกรองกลุ่มคนที่จะมาทำ test ให้เหมือนกัน และตรงกับกลุ่มที่ product ของคุณต้องการจริงๆ เพื่อมั่นใจว่าปัญหาที่เกิดขึ้นไม่ได้เกิดจากคนที่มีความต่างกันเกินไป
- กลุ่มคนที่มาทดสอบครั้งนี้เป็นคนทำงานอยู่ในช่วงอายุ 25–40 ปี ที่ไม่มีความคุ้นชินกับสิ่งที่เรานำมาทดสอบ ดั้งนั้น Insight ที่เราได้จากการทดสอบครั้งนี้จะไม่ควบคุมที่กับทุกกลุ่มคน เช่นถ้าเราเอากลุ่มเด็กนักเรียน ม.ปลาย มาทดสอบเว็บกรมสรรพากรเรามีโอกาสปัญหาใหม่ที่ไม่ได้เจอใน 15 คนที่ทดสอบด้วย จะต้องทดสอบกับกี่กลุ่มนั้นก็ขึ้นอยู่กับการให้ความสำคัญกับแต่ละกลุ่มใน Product ของคุณ คำแนะนำของผมคือให้เริ่มจากกลุ่มที่สำคัญที่สุดก่อน บางปัญหาที่เราเจอแล้วมองว่ามันเป็นปัญหา Universal ก็ให้รีบแก้ได้ทันทีเลย แล้วค่อยสอบกับกลุ่มอื่นเพิ่มในรอบต่อๆ ไป
- Process การ test ที่ถูกต้อง, คน Facilitate การ test, สภาพแวดล้อมของที่จัด test, ระยะเวลาการทดสอบ, ความร่วมมือของ user และความรู้สึกของ user ณ ตอนนั้น ทั้งหมดล้วนมีผลกระทบกับผลทดสอบที่คุณจะได้รับ
Thank youuuu 🙏
การวิจัยครั้งนี้จะไม่สำเร็จได้ถ้าไม่มีคนเหล่านี้…
- อ.มุก Thippaya Chintakovid จาก จุฬาลงกรณ์มหาวิทยาลัย ที่ค่อยให้เป็นที่ปรึกษาเรื่องยากๆ ให้กับการทดลองครั้งนี้
- งานนี้จะไม่สำเร็วถ้าได้ไม่มี Noon Thapanee Srisawat, Nan, Millie จาก Ahancer Team
- Get User Nows ที่ช่วยสนับสนุนด้านการหา user มาให้ทดสอบในครั้งนี้
- Sank Dhanakorn Ocharoenchai & ตึก KX ที่ให้ส่วนลดในการเช่าสถานที่
- Users ทุกท่านที่สละเวลามาทดสอบกับเราในครั้งนี้
จบแล้วครับ หวังว่าคราวหน้าที่คุณเจอคำถามว่า “ต้องทำ User Test กี่คน?” คุณจะสามารถตอบได้อย่างมั่นใจขึ้นครับ สิ่งที่สำคัญมากกว่าจำนวนกี่คนนั้นคือการเริ่มทำครับ และทำ User Test ให้บ่อยครั้ง ต่อให้รอบละไม่กี่คนก็ตาม
Reference:
Nielsen, J. & Landauer, T. K. (1993). A Mathematical Model of the Finding of Usability Problems. In Proceedings of the INTERACT ’93 and CHI ’93 Conference on Human Factors in Computing Systems (206–213). Association for Computing Machinery. https://doi.org/10.1145/169059.169166
