แชร์ประสบการณ์ทำ Testing ในมุมของ UI Designer
Usability Testing เป็นเครื่องมือในการทำ Testing แบบหนึ่งที่นิยมพอสมควร เพราะช่วยให้เราได้รู้ถึงพฤติกรรมที่ User ลองทดสอบกับ Product ของเราจริงๆ และได้รับรู้ว่า User Flow ที่เราวางหรือการจัด UI Layout ต่างๆ นั้นมีปัญหาหรือไม่ รวมถึงเราอาจจะได้ไอเดียใหม่ๆ ไปต่อยอดจาก Feedback ของผู้ร่วมทดสอบ
วันนี้ผมจึงอยากจะมาแชร์การทำ Unmoderated Usability Testing สำหรับฟีเจอร์ QR EMV (K Scan to Pay) ของ K PLUS ซึ่งอาจจะไม่ได้ลงดีเทลมาก แต่เน้นถึงภาพรวมของ Process ครับ
จุดเริ่มต้นของการทำ Usability Testing
เริ่มจากตอนที่ผมได้รับโจทย์ทำฟีเจอร์ QR EMV (K Scan to Pay) หรือการสแกนจ่าย QR ชำระผ่านบัตรเครดิต โดยสโคปตอนแรกที่ได้รับมอบหมายนั้นเป็นการออกแบบ เพื่อส่งต่อไปให้ทาง Developer พัฒนาตามปกติ แต่พอออกแบบไปได้ประมาณ 2–3 แบบ ก็มีความคิดเห็นหลากหลาย ทั้งตัวผมเองหรือทีมงานที่เกี่ยวข้อง ทั้งยังมี Feedback ส่วนอื่นๆ จาก User ในอดีต สุดท้ายจบที่ให้ลองเอาไปทำ Test เพื่อจะได้นำ Testing Result มาพูดคุยกันต่อ ซึ่งในโปรเจคนี้สโคปการทำ Test ไม่ได้ใหญ่มาก จึงได้มีโอกาสทำด้วยตัวเองร่วมกับพี่ Senior Designer ในโปรเจค และได้พี่ๆ หลายคนจากฝั่ง Research มาช่วยรีวิวในบางส่วนด้วยครับ
ก่อนจะเริ่มลงมือทำ Test เราได้มีการพูดคุยกันระหว่างฝั่ง Designer และ DB ที่ดูแลฟีเจอร์นี้ว่ามีเวลาให้เท่าไหร่ แล้วตกลง Goal และ Objective ร่วมกันว่าเราทำไปทำไม ทำไปเพื่ออยากรู้อะไรครับ ซึ่งส่วนนี้ผมคิดว่าค่อนข้างสำคัญ เนื่องจากระหว่างทางที่ทำอาจจะมีจังหวะที่หลุดจากสิ่งที่เราอยากรู้จริงๆ ได้ อย่างตัวผมก็มีย้อนกลับมาดู Objective เรื่อยๆ เพื่อให้การทดสอบนี้ได้ผลลัพธ์ออกมาเป็นสิ่งที่เราจะเอาไปใช้งานต่อได้ ถัดไปคือต้องตัดสินใจว่าจะทำ Usability Testing แบบ Moderated หรือ Unmoderated โดยแต่ละแบบจะมีข้อดีข้อเสียต่างกัน
Moderated Usability Testing
เป็นการทดสอบการใช้งานที่มีผู้ดูแลหรือผู้ควบคุมคอยชี้แนะและสอบถามผู้ใช้งานระหว่างการทดสอบ
ข้อดี สามารถควบคุมและแก้ไขปัญหาที่อาจจะเกิดขึ้นระหว่างทดสอบได้มากกว่าและสามารถที่จะถามตอบกับผู้ทดสอบได้มากกว่า
ข้อเสีย ผู้ร่วมทดสอบจะต้องใช้เวลามากขึ้น ซึ่งอาจส่งผลให้ผู้ทดสอบต้องใช้เงินและเวลามากขึ้นในการทดสอบ รวมถึงการที่ต้องทดสอบ 1 on 1 นั้นอาจทำให้ผู้ร่วมทดสอบมีความกดดันมากขึ้น
Unmoderated Usability Testing
เป็นการทดสอบการใช้งานที่ไม่มีผู้ดูแลหรือควบคุมอยู่ในระหว่างการทดสอบ ผู้ใช้งานจะทำการทดสอบด้วยตัวเองตามคำแนะนำและขั้นตอนที่ได้เตรียมไว้ล่วงหน้า
ข้อดี ประหยัดเวลาและค่าใช้จ่าย รวมถึงสามารถกระจายตัว Usability Testing ให้ผู้ทำแบบทดสอบได้มากขึ้นและกว้างขึ้น แถมยังมีอิสระมากขึ้นในเรื่องของเวลาหรือการทำแบบทดสอบ
ข้อเสีย ถ้าเราออกแบบการทดสอบมาไม่ดีพอ อาจจะไม่ได้ข้อมูลที่ต้องการเพียงพอหรือเราอาจตกหล่นข้อมูลบางจุดที่น่าสนใจไป และมีโอกาสที่ผลลัพธ์ของผู้ทดสอบบางส่วนจะใช้งานไม่ได้ เนื่องจากเราไม่ได้อยู่ควบคุม เช่น ผู้ร่วมทดสอบ Drop-off ระหว่างทาง
ด้วยระยะเวลาและปัจจัยหลายๆ อย่าง ผมเลือกทำเป็นแบบ Unmoderated Usability Testing เนื่องจากใช้ระยะเวลาการทำจนถึงได้ผลลัพธ์น้อยกว่า ประกอบกับส่วนตัวมองว่าค่อนข้าง Handle ได้ง่ายกว่าสำหรับ Designer ที่ยังมีประสบการณ์ด้านนี้ไม่เยอะมากครับ แต่จริงๆ ขึ้นอยู่กับบริบทหรือสถานการณ์ของแต่ละโปรเจคด้วยครับ อย่างที่กล่าวข้างต้นว่าทั้งสองแบบมีข้อดีและข้อเสียที่แตกต่างกัน
จากนั้นเราจะกำหนด Participant Criteria เพื่อกำหนดสโคปกลุ่มเป้าหมายให้แคบลงและตรงกับกลุ่มที่เราต้องการ รวมถึงออกแบบคำถามและตัวแบบทดสอบ เสร็จแล้วก็ไปเริ่มทำบน Useberry (โปรแกรมสำหรับทำ Usability Testing) ซึ่งในขณะที่ทำตัว Test นั้นก็ทำ Prototype บน Figma ควบคู่กันไปด้วย เพื่อนำมาลิงก์กับ Useberry ครับ โดยผมจะกำหนด Task ให้ User Follow ดังนี้
ระหว่างทางผมได้มีการนำไป Dry-run กับพี่ๆ ในทีมและทีมอื่นๆ ทำให้ได้รับ Feedback หลายๆ อย่าง ทั้งในมุมของตัวคำถาม โจทย์ ไปจนถึง Prototype ซึ่งต้องใช้เวลาแก้ประมาณนึง แต่ก็ดีกว่าผิดพลาดตอนไป Test จริงครับ
ตัวอย่างปัญหาที่ผมเจอแล้วคิดว่าบางคนอาจเจอเหมือนกัน คือเรามี Design สองแบบ ถ้าเป็นโจทย์เดียวกัน จะพบว่า User ทำ Test ของ Design B ได้คล่องกว่า Design A เพราะคุ้นชินกับตัวแพลตฟอร์ม Useberry และได้เห็น Flow จากการทดสอบ Design A แล้ว ดังนั้นวิธีที่ผมเลือกใช้แก้ในเรื่องนี้จึงเป็นการ Randomize ให้ User เจอลำดับการ Test ที่แตกต่างกัน โดยกลุ่มแรกจะเจอ Design A -> Design B และกลุ่มสองจะเจอ Design B -> Design A ให้ผลลัพธ์ออกมาแฟร์มากยิ่งขึ้น
หลังจากทำ Test เสร็จ ก็เข้าสู่ช่วงวิเคราะห์และสรุปผลครับ ซึ่งในส่วนของข้อมูลหรือ Feedback ต่างๆ ผมจะนำมาจัดกลุ่มแบบ Affinity Diagram เพื่อให้ข้อมูลที่กระจัดกระจายมีความเรียบร้อยขึ้นและง่ายต่อการสรุปผลครับ
และในช่วงท้ายสุดของการ Test ผมทำ Presentation Deck นำผลลัพธ์ไปเล่าให้ทีมฟัง เพื่อหาข้อสรุปและตัดสินใจ ซึ่ง Deck นี้ใช้เล่าให้หลายส่วนฟัง ทั้ง Designer, Dev, BA, DB และอื่นๆ เนื่องจากเวลาใน Meeting มีจำกัด จึงต้องพยายามทำให้เนื้อหากระชับและเข้าใจง่ายสำหรับทุกฝ่าย
พอครบทุกขั้นตอน ก็นำบทสรุปมาปรับใน Design เพิ่ม Flow ให้สมบูรณ์ แล้วอัพเดต New Component ขึ้น Design System ครับ
Summary
จากที่ใช้เวลาพอสมควรทีเดียวตั้งแต่ต้นจนถึงงานขึ้น Production ก็ได้เรียนรู้อะไรหลายๆ อย่างจากข้อผิดพลาดระหว่างทาง หรือสิ่งที่ทำได้โอเคแล้วแต่ยังโอเคได้มากกว่านี้อีก รวมถึงการทำ Test ในสโคปเล็ก-กลางได้นั้นถือเป็นจุดเริ่มต้นที่ดี เพื่อจะให้งานที่ Deliver ออกไปดียิ่งขึ้นและตอบสนองความต้องการของ User ได้ตรงยิ่งขึ้น
งานส่วนใหญ่ของเรามีการทำ Research & Testing โดยทีม Research ของ Beacon Interface อยู่แล้ว แต่อาจจะไม่ใช่ทุกโปรเจคหรือฟีเจอร์ครับ
และในฐานะ UI Designer ที่ได้มีโอกาสทำ Research ก็ได้เข้าใจและรับรู้ถึงมุมมองของ User มากยิ่งขึ้น เพราะปกติตอนที่เราดีไซน์ User Interface นั้นอาจจะไม่ได้ใกล้ชิด User มาก ข้อมูลที่ได้จึงจะเป็นข้อมูลที่สรุปมาแล้วจากทีมอื่นๆ แต่พอได้ทำเองก็รู้สึกสนุกและท้าทายมากยิ่งขึ้นครับ
ทิ้งท้ายด้วยการขายของครับ ตอนนี้ฟีเจอร์ก็ปล่อยออกมาซักระยะนึงแล้ว ใครที่ใช้งานบัตรเครดิตธนาคารกสิกรไทยสามารถใช้ฟีเจอร์ K Scan to Pay ของ K PLUS เพื่อชำระรายการกับร้านค้าที่ร่วมรายการกันได้ครับ ดูรายละเอียดขั้นตอนได้ที่ลิงก์นี้เลย
สำหรับใครที่ชื่นชอบบทความนี้ อย่าลืมกดติดตาม Medium: KBTG Life เรามีสาระความรู้และเรื่องราวดีๆ จากชาว KBTG พร้อมเสิร์ฟให้ที่นี่ที่แรก
