เก็บตกคู่มือการเทส จาก Usability Testing Workshop

เนื้อหาของตอนนี้จะเป็นการเก็บตกในจุดที่คิดว่ามีประโยชน์จากการที่ได้ถลำตัวไป Workshop การทำ Usability testing มา แต่ก็เกือบพลาดไปแล้วงานมี 10 โมงเจอน้ำท่วมบางกอกไปเลทกระจุย ซึ่งการ Workshop ครั้งนี้จัดโดย UX Bangkok และ Fungjai โดยตัวงานแบ่งเป็นช่วงเช้าบ่าย เช้าเป็นโหมดฟังๆจดๆ ช่วงบ่ายก็มามือเลอะกันเพราะเราต้องคิด เขียน และทำ ใช้หัวเรื่องในการที่จะทำ Usability กันเป็นการทดสอบ Feature ใหม่บนแอพฟังเพลงของฟังใจนี่แหละ แต่อย่างที่บอกก็แค่เก็บตกประเด็นน่าสนใจ คงไม่ได้เขียนบรรยายบรรยากาศหรือเรียงความไทม์ไลน์ของงานหรอก (แต่ดูท่าจะยาว)

เริ่ม!

ข้อมูล / บริบท / ผู้ใช้งาน → สามสิ่งนี้คือสิ่งสำคัญที่จะต้องรู้ในการออกแบบ

Heuristic Review
หรือ Heuristic Evaluation หรือ Usability Heuristic คือการประเมินและเช็คการออกแบบโปรดักส์ของเรา ไม่ว่าจะเป็นเว็บหรือแอพ การประเมินนี้เราทำเพื่อหาสาเหตุเบื้องต้นของปัญหาที่ควรแก้ไขปรับปรุง ขั้นตอนนี้เราจะทำก่อนที่จะเอาไปทำ Testing จริงๆ

Guerilla Testing

มันคือ Usability Testing ร่างจิ๋วราคาประหยัด ไม่ต้องเตรียมอุปกรณ์หรือสถานที่มากเน้นความเร็ว ซึ่ง User ที่จะมาเทสเป็นใครก็ได้เพื่อนนั่งข้างๆก็ยังโอเค เน้นเก็บ Feedback แบบเร็วๆ ที่มีวิธีการนี้มาก็เพราะ บางทีการ Test จริงๆมันแพงเราก็เลยมีเจ้าตัวนี้มาก่อนเพราะอย่างที่บอกมันถูก นิยามของมันง่ายๆก็คือ The main goal of guerrilla testing is to find errors and fix them as quickly as possible. หาจุดที่เจ๊งและแก้ให้เร็วที่สุด แนะนำว่าให้ทำเจ้านี้ก่อนไปทำ Test จริงๆด้วย อ่านเพิ่มเกี่ยวกับ Guerilla Testing →

Usability Testing

:กระบวนการทดสอบไอเดียและ Interaction ในกลุ่มของผู้ใช้งานจริง ว่ามันใช้ได้จริงหรือเปล่า เพื่อให้ตอบโจทย์ Business ของเรา

ข้อควรจำในการทำ Usability Testing

Persona: คนที่จะนำมาเป็นผู้ถูกทดสอบ ตัว Persona หรือลักษณะบุคคลของกลุ่มเป้าหมายเรา(ที่จะทำให้เชิง Business มัน Success) ได้มาจากPattern ของ Data ที่เราสังเกตุได้ไม่ว่าจะเป็นพฤติกรรม การใช้ชีวิต ไลฟ์สไตล์ต่างๆ รวมไปถึงข้อมูลและช่วงอายุของเขา ซึ่งปกติแล้วการทำ Persona เนี่ยทำได้ทั้งสองวิธี ไม่ว่าจะ Research ก่อนแล้วเอาข้อมูลมาทำหรือจะสมมุติสุ่มๆไปเลย แต่จะแนะนำว่าให้ Research ก่อนนั้นแหละ ถึงจะใช้เวลากว่าการเดาสุ่มแต่ก็ Play safe ถ้ามันเกิดไม่ตรงขึ้นมานี่เสียเวลากว่าไป Research แต่แรกอีก
Think aloud: คิดอะไรก็พูดมาซะดีๆ เป็นการบอก(สอน)ให้ผู้ถูกทดสอบเห็นอะไรคิด สงสัยอะไรหรือกำลังจะทำอะไรในเวลาเทส ให้พูดออกมาให้หมด เล่ามาเป็น Story (Journey) คิดซะว่าเหมือนคุยคนเดียว ถ้าเขากั๊กเราจะไม่ได้รู้เหตุผลจริงๆของการกระทำนั้นๆเลย เทคนิคก็คือ ลองให้เขาเล่าถึงเหตุการณ์ชีวิตประจำวันที่คุ้นเคยเป็นฉากๆออกมา หรือลองให้เขาเล่นแอพหรือเว็บอื่นและให้เขาพูดๆเล่าๆดูก่อนที่จะมาเทสแอพของเรา
แค่ Task ที่จำเป็น: ปกติเวลาเทสที่ให้ผู้ใช้ใช้แอพของเราเนี่ย เฉลี่ยแล้วเราไม่ควรให้มันเกิน 45 นาที ด้วยเวลาที่จำกัดและความเหนื่อยเราควรเอาเฉพาะ Task ที่จำเป็นหรือสำคัญที่จะเอามาเทสเท่านั้น เช่น Feature ใหม่
ไม่ไกด์คำตอบ: เราต้องจำไว้เสมอว่าเราไม่ควรไกด์ แนะนำ หรือพูดโน้มน้าวเอนเอียงไปในทางที่จะให้ User ทำอะไรซักอย่างที่เราคิดว่าควรจะทำ ถ้าไกด์ก็เหมือนบอกเฉลย เราจะวัดอะไรไม่ได้จากการทดสอบเลย ให้แค่โจทย์ กับ End Goal ก็พอ
คำถามเชิงบวก: ‘ทำยังไงพี่จะชอบมันมากขึ้น’,‘ทำยังไงมันจะพัฒนาให้มันดีขึ้น’ อย่าถามคำถามเชิงลบเช่น ‘แอพเราแย่ยังไง’ บางทีเขาจะเกรงใจเราและไม่กล้าตอบ

การวัดผล

Single Ease Question: ถามง่ายๆว่า ‘สรุปแอพเราเนี่ยใช้ง่ายหรือยากแค่ไหน ถ้าให้เป็นคะแนน 1-5 เรียงใช้ง่ายไปยากให้กี่คะแนน’
Net Promoter Score:วัดความพึงพอใจของแอพเรา คนอยากแชร์ต่อหรือเปล่า
System Usability Scale: แบบสอบถามวัดความรู้สึกหลังจากใช้ จะมีประมาณ 10 คำถาม (10 template questions) และวัด 1–5 มากไปน้อย คำถามเช่น คิดว่าระบบซับซ้อนไหม?, คิดว่าจะกลับมาใช้หรือเปล่า? อะไรทำนองนี้
Time On Task: จับเวลาแล้วดูว่าแต่ละ Task ที่เขาทำเขาใช้เวลานานเกินไปกว่าที่ควรจะเป็นหรือเปล่า เขาไปหลงตรงไหนมาไหม?
Task Completion Rate: Task ทั้งหมดมีเท่าไหร่แล้วในนั้นมี Task ย่อยกี่อัน สรุปแล้วทำเสร็จกี่เปอร์เซ็นต์

Usability Test Plan Dashboard

เรามีตัวช่วยในการร่างแปลนคร่าวๆ ก่อนที่จะเริ่มทำ Testing จริงๆและยังเป็นตัวที่จะทำให้เราเขียน Scrpit วันเทสจริงได้ง่ายและดีขึ้นด้วย ถ้าจะรวบรัดแต่ละตัวง่ายๆ
– Product Under Test: เราจะเทสบนเครื่องมืออะไร
– Business Case: ทำไมต้องทำเทสครั้งนี้, ถ้าไม่ทำจะมีผลกระทบอะไรต่อ Business (เอาไว้บอกพวกใหญ่ๆโตๆว่าเทสไปทำอะไร)
– Test Objective: อะไรคือ Goal ของการเทสครั้งนี้ อยากจะได้อะไรจากการเทส
– Participants: Persona ของผู้ถูกทดสอบคืออะไร (ดูว่าคนที่จะมาเป็นผู้ใช้ใหม่หรือเคยใช้มาแล้ว ดูว่า Task ควรเป็นแบบไหน)
– Equipments: อุปกรณ์ที่ใช้ในการทดสอบ รวมไปถึง ปากกา กระดาษ กล้อง(ใช้อัด Interact และ Emotion ของผู้ถูกทดสอบด้วย)
– Test Task: โจทย์ Task ที่จะเทสเพื่อหาคำตอบของแอพเรา ต้องกำหนดจุดเริ่มต้นและจุดจบให้เคลียร์
– Responsibilities: ใครจะเป็นคนรับผิดชอบตำแหน่งไหนในการเทส คนสัม,คนเทส,คนเซ็ทกล้อง
– Location & Dates: เวลา + สถานที่
– Procedure: ขั้นตอนรันตั้งแต่ ผู้ถูกทดสอบมา, เซ็นสัญญายินยอมและอนุญาต เลย

พักตากับต้นไม้เขียวๆแปปนึง รู้สึกเนื้อหาเริ่มเยอะ (Photo: psychqx)

How to create a testing script

:ขั้นตอนคำพูดที่จะต้องใช้พูดกับผู้ถูกทดสอบ ที่จะให้เขากล้าเปิดเผยข้อมูลกับเรามากที่สุด

How to create a usability testing script

Introduction: เป็นการเกรินพูดคุยเพื่อให้ Relax คุยเล่นๆเพื่อหาว่าเขาตรง Persona เราแค่ไหน แต่จะลืมพวกนี้ไปไม่ได้ก็คือ
– บอกว่าการทดสอบนี้เทสแอพไม่ใช่เทสคน ฉะนั้นไม่ต้องกังวลว่าจะทำผิด
– ระหว่างทดสอบถามได้นะ แต่เราจะตอบตอนจบการเทสเพราะเราอยากเห็นเหตุผลจริงๆที่คุณกำลังทำกับแอพของเรา
– คุณสามารถหยุดพักหรือเลิกเมื่อไหร่ก็ได้
– เซ็นใบขออณุญาตและยินยอมเรื่องการเปิดเผยข้อมูล
Think aloud intro: บอกตัวอย่างว่าควรจะเล่าสิ่งที่กำลังทำหรือกำลังคิดออกมายังไง (รายละเอียดตามข้างบนนู้นหัวข้อ ‘ข้อควรจำในการทำ Usability Testing’ )
Task: บอกภาพรวมของการทดสอบว่าจะมีอะไรบ้าง → เริ่มนำโจทย์ทั้งในรูปแบบ Scenario Task หรือ Verb base Task บางอันมาให้เขาอ่านให้ฟังเพื่อเช็คความเข้าใจก่อน แล้วค่อยทำ อย่าลืมย้ำเรื่องเราจะไม่ได้ตอบระหว่างทำการทดสอบด้วยล่ะ
Single ease question: เหมือนที่เขียนในหัวข้อข้างบน (การวัดผล) เราจะให้เขาบอกคะแนนยากง่ายหลังจากทำเสร็จในแต่ละ Task เผื่อให้อารมณ์เขายังสดใหม่อยู่ จะได้เรียลๆ
Follow up question: ต่อจากการวัดคะแนนแล้วก็ เป็นการถามคำถามหาเหตุผลในการกระทำของ User เช่น ตะกี้ทำไมคุณถึงกดปุ่มนั้น, คุณเห็นปุ่มนั้นแล้วคิดว่าเป็นอะไร, ทำไมคุณถึงไม่เลือกกดปุ่มนี้ อะไรทำนองนี้ (ถ้า User ทำไม่จบ Flow ก็เฉลยไป) หลังจาก Follow up เสร็จแล้วก็ให้เริ่ม Task ต่อไปได้เลย
Debrief: เมื่อสิ้นสุดการทดสอบแล้ว ให้เขาสรุปความรู้สึกของการทดสอบครั้งนี้ และเราก็ขอบคุณ ล่ำลา พร้อมกับให้ของตอบแทน (ถ้าคนไหนเข้าตา ลองแย๊ปๆไปว่าถ้าครั้งหน้ามีอีกสนใจไหม แล้วเก็บ Contact ไว้)

ข้อควรจำในการวิเคราะห์ผล

ระวัง Bias ของตัวเอง (ระวังจะเข้าข้างตัวเอง)
เก็บและจดทุกอย่าง อย่าคิดว่าเราจำได้ทุกอย่าง
อย่าลืม Follow up ถาม Why เยอะๆหาต้นตอของปัญหามาให้ได้
ทำอย่างมีแบบแผน จดหรือเก็บข้อมูลอะไรให้เป็นระเบียบจะได้ง่ายในการนำมาวิเคราะห์

ควรทำตอนไหนบ้าง?

ก่อนเริ่ม Design
ก่อนเริ่ม Development
ก่อน Launch
หลัง Launch (เพื่อเอา Feedback หลังใช้)
แต่ถ้าถ้าทีมไม่ใหญ่มากควรทำเดือนละครั้ง หรือ ยืดหยุ่นกว่านั้นได้

Your product will be user tested whether you like it or not — ไม่ว่าคุณจะชอบไหม ยังไงโปรดักท์ของคุณก็จะโดน User เทสอยู่ดี แล้วทำไมถึงไม่เอา User มาเทสให้คุณดูซะเลยล่ะ

จับฉ่าย

เวลาทดสอบควรพูดโดยใช้น้ำเสียงในระดับเดียวกับผู้ถูกทดสอบ เพื่อให้เขารู้สึกเป็นกันเองและกล้าพูดสิ่งที่คิดออกมา และบอกว่าไม่ใช่ความผิดเขาถ้าเขาทำพลาด
กรณีสมมุติถ้าสถิติกลุ่มผู้ใช้เว็บเป็น ช 30%, ญ 70% แต่ว่าในทาง Business เราอยากให้ทั้งคู่ใช้เหมือนกัน เราจะใช้วิธีเทสทั้งสองกลุ่ม(Persona ช ญ)แล้วดูความแตกต่างกันแล้วเอาผลเทสที่ได้มาปรับปรุง แต่เราจะเอนเอียงผลลัพธ์ไปทางฝั่งที่มีผู้ใช้มากกว่า(กรณีนี้คือฝั่ง ญ )
ใน Design Guideline ของแต่ละ OS มีผลแต่การออกแบบมาก บางทีออกแบบโดยใช้ Guideline ของ Android แต่ผู้ใช้ iOS มาใช้แล้วไม่รู้จักเลยก็มี เราเลยต้องเทสว่าผู้ใช้ในแต่ละ Device เข้าใจ Ui นั้นๆของเราหรือเปล่า
เวลาตั้งโจทย์ Scenario ของ Task เราต้องตั้งเป็นประโยคคำสั่งไม่ใช่คำถามและไม่ไกด์ให้ผู้ถูกทดสอบ ex. ‘ถ้าจะลอง Add เพลงนี้ไว้ใน Favorite จะต้องทำยังไง’ → ‘ถ้าคุณชอบเพลงนึงมากๆ เราเลยอยากจะให้คุณเก็บเพลงนั้นไว้เป็นเพลงโปรดเผื่อจะได้มาฟังมันบ่อยๆ’
เราต้องเผื่อ Task สำรองไว้เสมอ ถ้าผู้ถูกทดสอบทำเสร็จเร็วและเวลาเหลือ หรือไม่งั้นก็เอาเวลาที่เหลือนั้นไปถาม Follow Up ให้เยอะๆก็ได้
เราสามารถเอาแอพอื่นหรือแอพคู่แข่งมาเทสได้ ให้เขา Think aloud ดูว่าเป็นยังไงต่าง เราจะไดมาวิเคราะห์ว่าต่างจากของเรายังไงและมีจุดไหนที่น่าสนใจ (แนะนำว่าถ้าจะให้เทสของคนอื่น ต้องเทสของเราก่อนเพราะเขาจะได้ยังไม่มี Know how แอพประเภทเดียวกันมาก่อน)
ในการเทสใช้เป็น Paper Prototype หรือตัวอย่างแอพที่เป็นกระดาษ ถ้าเขากดในจุดอื่นที่ไม่ได้เตรียมมาเราก็บอกเขาไปเลยว่าเราไม่ได้ทำในส่วนนี้มาให้ลองวิธีอื่นดู และ Paper Prototype ควรปริ้นเป็นขาวดำมาเพราะนอกจากเผื่อคนตาบอดสีแล้ว ยังเป็นการมั่นใจว่าแอพเราจะใช้งานได้ตั้งแต่ยังไม่เป็นสี
ในการทำ Testing เราควรต้องเอาคนที่ตรงกับ Persona เรามาเพื่อความถูกต้องและแม่นยำของผลลัพธ์ที่ได้ แต่ถ้าหาไม่ได้จริงๆก็ต้องไม่เอาคนที่ไม่ใช่กลุ่มเป้าหมายเรามาเด็ดขาด

usability testing book — Rocket Surgery Made Easy by Steve Krug & Handbook of Usability Testing

เผื่อถ้าใครอยากศึกษาเรื่อง Usability Test เพิ่มเติม มีหนังสือมาแนะนำสองเล่ม
1. Rocket Surgery Made Easy by Steve Krug (ผู้เขียนเดียวกับ Don’t Make Me Think) เล่มนี้มีแปลป็นไทยแล้วนะ ซื้อได้ที่ Don’t Make Me Think (ฉบับภาษาไทย)

2. Handbook of Usability Testing by Jeffrey Rubin and Dana Chisnell เล่มนี้ยังไม่มีแปลไทยจ้า

Workshop จบลงรวมทั้งสิ้นเกือบ 8 ชม. คุ้มค่ามากๆครับ ปลากรอบกับได้ลองทดสอบกับโปรดักส์ของฟังใจจริงๆ นับว่าเป็นเคสศึกษาที่ดีมากเลย ต้องขอบคุณทั้งสองทีมนี้มากๆแล้วอย่าลืมไปติดตามความเคลื่อนไหวของทั้งสองคณะนี้ ถ้าอยากตามข่าวหรือ Workshop UX แบบนี้อีกตามไปที่ UX Bangkok และถ้าอยากฟังเพลงที่ที่ไหนก็หาฟังไม่ได้ เพลงล้ำๆนอกกระแสสุดโหดก็ซบมาที่ฟังใจ Fungjai หรือ fungjai.com (แพลตฟอร์มฟังเพลงระบบ Music Streaming) ได้เลย

อ่านอะไรต่อดี
สรุป UX Meetup: สร้างองค์กรแนวหน้า ผ่านแนวคิด UX Design
Zara: A Usability Case Study
A Guerilla Test on Dropbox Photos
Crafting Useful User Personas (Part 1 — Research)

🦍