สรุป Key Learnings ที่ได้จากการฟัง 3 Key Learnings ของพี่พิจในงาน UX Thailand conference 2024

เมื่อไม่กี่สัปดาห์ก่อนได้ไปงาน UX Thailand conference 2024 มาค่ะ แล้วได้ฟังพี่พิจ Talk ในหัวข้อเรื่อง “What I've learned from 15+ years of conducting usability testing”

.

ใน talk พี่พิจได้มีการพูดถึงเรื่องของการทำ user research โดยเริ่มจากอธิบายคร่าว ๆ ว่าการทำ user research คืออะไรให้คนที่มาฟังเห็นภาพตรงกัน และเล่าถึง Key learnings 3 ข้อที่พี่พิจเจอจากประสบการณ์การทำงาน 15 ปีที่ผ่านมาค่ะ

.

เนื่องจากมีคนสรุป talk พี่พิจไปหลายคนแล้ว (และเขียนกันดีมาก ๆ เลยค่ะ )

Article นี้เลยจะเป็นการเขียน Key learnings 10 ข้อ ที่ได้จาก Key learnings ที่พิจพูด 3 ข้อกันค่ะ (เอ๊ะ! ทำไมเยอะกว่า )

.

จริง ๆ ทำงานอยู่ Pruxus อยู่แล้ว และได้ฟังพี่พิจพูดเรื่องพวกนี้มาทุกวี่ทุกวันเลยค่ะ แต่จากที่ได้ไปฟังในงานก็รู้สึกว่าอยากเขียนสรุป Key learnings ของตัวเองออกมาอีกทีค่ะ เพราะถึงจะฟังบ่อยแต่ไม่เคยสรุปไว้เลยค่ะ 

.

มาเริ่มกันเลยดีกว่าค่ะ

.

________________________________________________________

.

.

#1 User research คืออะไร?

.

พี่พิจมองว่า คำว่า “User Research” เป็นคำกว้าง ๆ ที่หมายถึงกิจกรรมที่คน UX ทำ เพื่อทำความเข้าใจ users ให้มากขึ้น โดยหลัก ๆ คือการเข้าไปมีปฏิสัมพันธ์ พูดคุย หรือไปสังเกต users ในเรื่องที่เกี่ยวข้องกับโปรดักส์ที่เราสนใจ

ซึ่งใต้คำว่า User Research นั้น พี่พิจแบ่งมันออกเป็น 2 ฝั่งค่ะ คือ:

.

1.Discover Research - เป็นการ research แบบไปนั่งคุยให้ users เล่าเรื่องราวสิ่งที่เคยพบเจอมาก่อน ทั้งสิ่งที่ใช้งานหรือไม่ใช้งาน, สิ่งที่เคยเรียนรู้มา, หรือปัญหาแย่ ๆ ต่าง ๆ ที่เคยเจอมา

.

2.Usability Testing (UT) - เป็นการ research ที่เรามีโปรดักต์ตัวนึงที่โฟกัสอยู่ แล้วต้องการรู้ว่าโปรดักต์ ของเราใช้ได้ยากง่ายอย่างไรบ้าง โดยให้ users มาลองใช้งานจริงครั้งแรกแล้วดู experience ในการใช้งานของ users ค่ะ

.

.

.

#2 Discovery research ต่างกันกับ Usability Testing (UT) ยังไง?

.

ความแตกต่างหลัก ถ้ามองแบบสายเนิร์ด ลึกลงไปในเรื่อง Cognitive processing ของ users ที่มาเข้าร่วม Research จะพบว่า Discovery research นั้น จะเป็นการให้ users ทำการ “Recall from memory” หรือระลึกถึงประสบการณ์ต่าง ๆ ในอดีต แล้วมาเล่าให้เราฟัง ซึ่งจะทำในช่วงแรกก่อนที่เราจะลงมือ design โปรดักต์ เนื่องจากเรายังไม่มีดาต้าหรือความรู้เพียงพอเกี่ยวกับ users ของเรา เราจึงต้องทำความเข้าใจ users ก่อน

.

ส่วน Usability testing น้ัน จะเป็นการให้ users ทำการ “Problem-solving” หรือทำการแก้ปัญหาบางอย่าง เหมือนการแก้ puzzle โดยสิ่งที่แก้ปัญหาก็คือ การหาทางใช้งานโปรดักต์ของเราให้ไปถึงจุดปลายทางให้ได้ โดยจะเป็นการทำในช่วงที่เราทำ design โปรดักต์ออกมาแล้ว และต้องการใช้ users มาลองทดสอบการใช้งานดูว่าใช้ได้ยากง่ายแค่ไหนค่ะ

.

.

.

#3 เมื่อทำ UT เสร็จแล้ว โปรดักส์จะดีขึ้นได้เลยจริงไหม?

.

ปกติแล้วเราทำ UT เพื่อที่จะไปพัฒนาโปรดักส์ของเราให้ดีขึ้น แต่หลาย ๆ ครั้งก็เจอคนทำ UT เพราะได้ยินคนอื่นพูดมาว่าต้องทำ หรือเห็นคนอื่นทำ UT แล้วรู้สึก FOMO (fear of missing out) หรือ รู้สึกว่า #ของมันต้องมี

.

และบางคนเข้าใจว่าเมื่อทำ UT เสร็จแล้วโปรดักส์จะดีขึ้นทันที เลยทำ UT แค่ 1-2 อาทิตย์ก่อนหน้าจะ launch โปรดักส์ซึ่งพอได้ results มาแล้วว่าควรจะแก้ไขตรงไหนบ้าง ก็ไม่ได้ทำอะไรต่อ เพราะไม่มีเวลาให้แก้ไขอะไรแล้ว

.

“UT is not the cure, it’s only the diagnosis.”

คนมักจะเข้าใจผิดว่าการทำ UT คือทำแล้วโปรดักส์จะดีขึ้นเลย แต่จริง ๆ แล้ว UT เป็นแค่พาร์ทนึงของ process ที่ทำให้เราวิเคราะห์ได้ว่าปัญหาอยู่ที่ไหน และเราควรจะแก้ไขยังไงต่อเพื่อให้โปรดักส์ดีขึ้นเท่านั้น

.

.

.

#4 ถ้าเราอยากจะพัฒนาโปรดักส์ให้ดีขึ้นจริง ๆ ทำไมถึงทำแค่ survey หรือ Research แบบตัวเลข (Quantitative) อย่างเดียวไม่ได้?

.

ในการทำ research จะมี 2 แบบคือ Quantitative และ Qualitative research

Quantitative คือการเก็บข้อมูลเชิงปริมาณจาก users จำนวนมาก เช่นการทำ survey

Qualitative คือการเก็บข้อมูลเชิงลึก จะได้การอธิบาย หรือได้เหตุผลจาก users เช่น การสัมภาษณ์

.

การรีเสริชแบบ quantitative เราอาจจะทำ survey ถาม users ว่าหน้าจอตรงไหนที่มีปัญหาได้ แต่เราจะไม่รู้ว่าปัญหานั้นเกิดเพราะอะไร แล้วจะต้องแก้ยังไง ซึ่งมันอาจจะทำให้เกิด interpretation หรือการที่ทีมตีความไปเอง แล้วไปแก้ไขในจุดที่ไม่ใช่สิ่งที่ users เจอปัญหาจริง ๆ ได้

ซึ่งแตกต่างกับการรีเสริชแบบ qualitative ที่เน้นการทำความเข้าใจ ใน session พี่พิจได้เปิดคลิปตัวอย่างการทำ UT ให้ดู ซึ่งจะเห็นชัดขึ้นเลยว่า users มีการเจอปัญหาตรงไหน เพราะอะไร

.

.

.

#5 ทำไมเราควรต้องให้ users พูดตลอดเวลาที่ทดสอบการใช้งาน (หรือ มีการ Think-aloud)?

.

เพราะว่าในการทำ UT ถ้า users ไม่สามารถ think-aloud ได้ ใน session นั้นมันจะมีแต่ความเงียบ ซึ่งพอ users เงียบ เราจะไม่รู้เลยว่ากำลังเกิดอะไรขึ้น หรือ users กำลังมีปัญหาอะไรในการใช้งานหรือเปล่า

.

.

.

#6 แล้วทำไมถึงไม่ควรถาม “ทำไม” ตอนที่ users กำลังทำ tasks อยู่?

.

เพราะการถามว่าทำไม ทำให้ users ต้องนึกถึงเหตุผล และใช้สมองส่วนประมวลผลมาตอบคำถามของเรา ทำให้หลุดโฟกัสจากการทำ think aloud ไป และจะพยายามคิดถึงเหตุผลในการใช้งานต่าง ๆ มากขึ้น ซึ่งมันผิดธรรมชาติของการใช้งานจริง ๆ ด้วยตัวเองของ users ไป ทำให้เกิด bias ในผลลัพธ์ได้

ซึ่งแทนที่เราจะถามว่า ‘ทำไม’ ตอนที่ users ทำ tasks อยู่ ให้เปลี่ยนเป็นการพูดกระตุ้น users แทน เช่น คิดอะไรอยู่ หรือกำลังมองหาอะไรอยู่

แต่ก็ไม่ใช่ว่าจะห้ามถาม ‘ทำไม’ ไปเลยในตอน UT แต่ให้ถามหลังจากที่ users ทำ tasks เสร็จแล้วเพื่อทำความเข้าใจให้ชัดเจนยิ่งขึ้นได้ค่ะ

.

.

.

#7 แค่รู้ usability problems ของโปรดักต์ ก็ทำให้พัฒนาโปรดักต์ให้ดีได้จริงหรอ?

.

การพัฒนาโปรดักต์คนชอบเข้าใจผิดว่า ทำ UT เสร็จ เราก็จะเรียนรู้แล้วว่าโปรดักต์มีปัญหาที่จุดไหนบ้าง ก็ไปตามแก้จุดเหล่านั้น แล้วโปรดักต์ก็จะดีขึ้นแล้ว

.

แต่จริง ๆ อีกหนึ่งสิ่งที่สำคัญมากที่ทำให้ไม่ได้เกิดการแก้ไขตามนั้น ก็คือ การที่คนอื่น ๆ ในองค์กร “ไม่ยอม” หรือ “ไม่ buy” ว่าทำไมต้องแก้ปัญหาเหล่านั้นค่ะ

.

ซึ่งพี่พิจได้ลองให้ทางน้อง ๆ ทีมพรักซุส (เราก็เป็นหนึ่งในนั้น ที่โดนใช้ให้นับค่ะ ) ไปลองนับ stat จากการทำ UT ที่ผ่านมามาในช่วงหลัง ซึ่งเราเคยทำมา 35 products กับ users มากกว่า 200 คน พบว่ามี usability problems อยู่ทั้งหมด 792 ปัญหา

.

แต่ ไม่ใช่ว่าเราควรต้องแก้ทุกปัญหาที่เจอค่ะ เพราะพี่พิจบอกว่า สิ่งสำคัญคือปัญหาที่ “Severe” หรือรุนแรงมากเท่านั้นที่ควรแก้ ซึ่งปัญหาพวกนี้บางทีเราก็เรียกว่า Showstopper หรือสิ่งที่ users เจอปุ๊บ กดออกเลยเพราะทนใช้ต่อไม่ไหวนั่นเอง ซึ่งจาก stat ของเราก็พบว่า มีอยู่ 310 ปัญหาค่ะ

.

.

ทีนี้สิ่งที่เป็นคำถามในใจของพี่พิจและทีมคือ ในบรรดาปัญหาแรง ๆ เหล่านี้ มันเป็นความรับผิดชอบของทีม UX จริง ๆ แค่ไหน และทีมอื่นแค่ไหน?

.

เพราะปัญหา Usability problems นั้น มันไม่ใช่แค่ระดับ UX/UI เฉย ๆ แต่หลาย ๆ ปัญหา มันคือสิ่งที่มาจากทีมอื่น ที่ทีม UX/UI ควบคุมไม่ได้ด้วย เช่น ระบบ search ที่กดที รอ 5 วิกว่าจะมีผลลัพธ์ขึ้นมา ทำให้ users ทนไม่ไหวเลิกใช้ ซึ่งความเร็วความช้า มันเป็นหน้าที่รับผิดชอบของคนทีม IT หรือ Technical ใช่ไหมคะ หรือบางทีอาจจะมีปัญหาทาง Business อยากขายของมาก ก็เลยใส่ popup โฆษณาโผล่ขึ้นมา 5 อันติดทุกครั้งที่เปิดแอป ทำให้ users รำคาญจนไม่อยากใช้ต่อ แบบนี้ก็มีเช่นกันค่ะ

.

ซึ่งทางทีมพบว่า เราสามารถแบ่งหน้าที่ความรับผิดชอบของโปรดักส์ ออกเป็น 4 ด้านคร่าว ๆ ได้ ได้แก่

- UX/UI (ทีม UX/UI หรือพวก ๆ เรานี่เอง)

- Technicals (ทีม Dev, IT, ทีมระบบ ฯลฯ)

- Business/Marketing/Content (ทีม business, marketing)

- Regulations (ทีมหรือฝ่ายที่เกี่ยวข้องกับกฎหมายกฎเกณฑ์ต่าง ๆ)

.

ซึ่งใน 310 ปัญหาที่มีความรุนแรงนั้น เป็นปัญหาที่เกิดจากทีม UX ดีไซน์ไว้อยู่ที่ 79% แต่ 21% ที่เหลือเกิดเป็นปัญหาขึ้นจากทีมอื่น เช่น ผู้บริหารสั่งให้ทำ หรือไอทีบอกว่าแก้ไม่ได้ เป็นต้น ดังนั้น การพัฒนา product ไม่ใช่แค่ว่าเราไปทำ UT มาจนรู้ปัญหาของ users แล้วจะแก้ได้ แต่ต้องมี willingness to change ของทุกคนในทีมด้วย

.

.

.

#8 แล้วจะทำยังไงให้คนในทีมมี willingness to change ?

.

‘Emphaty’ เป็นสิ่งที่มนุษย์เราทุกคนมีกันอยู่แล้ว และมันจะเป็นหัวใจหลักให้เกิดการขับเคลื่อนและทำให้ทีมอื่น ๆ หันมาสนใจการแก้ปัญหาให้กับ users จริง ๆ กันได้ ซึ่ง Empathy นั้นสามารถเกิดได้จากทั้งการทำ “Discovery Research” และ UT ค่ะ

ซึ่งคนในทีมควรจะต้องมี emphaty ในการเข้าใจ users ให้มาก ๆ ถึงจะทำให้เกิดการ willingness to change ได้ ซึ่งการทำ UT ก็เป็นอีกวิธีหนึ่งในการสร้าง emphaty ให้กับคนในทีมได้เป็นอย่างดี โดยให้คนในทีมมานั่งดูตอนที่ทำ UT ด้วย แล้วเค้าจะเห็นภาพมากขึ้นว่า users ใช้งานระบบของเราแล้วเจอปัญหาตรงไหน ควรจะต้องปรับปรุงตรงไหนนั่นเองค่ะ

.

.

.

#9 ทำไมควรต้องทำ UT แบบ traditional หรือ ที่ต้องมีคนสัมภาษณ์จริง และมีการมานั่ง observe การใช้งานจริง?

.

พี่พิจได้พูดเจาะในเรื่อง UT เพิ่มเติมว่า การทำ UT นั้นมีหลายหลายวิธีมาก และก็มีเครื่องมือที่ช่วยให้ทำ UT ได้แบบอัตโนมัติ เช่นให้ users คลิกเข้ากดทำการทดสอบได้เอง และระบบก็ record สถิติเอาไว้ แต่ส่วนตัวพี่พิจเชื่อใน “Traditional Usability Testing” หรือ การทำ UT แบบดั้งเดิม ที่ต้องมี moderator นั่งกับ user แบบ 1-1 เพื่อคุย เตรียมความพร้อมให้ users และควบคุมการทำ UT ให้เป็นอย่างราบรื่นตลอดทั้ง sessions

ซึ่งการที่เราควรจะต้องทำ UT แบบ traditional เพราะสิ่งที่ได้มีประโยชน์คือ

1. ผลลัพธ์ที่ได้จาก UT เห็นภาพชัดเจนว่าปัญหาอยู่ตรงไหนบ้าง และ moderator จะได้เจาะถามตรงจุดที่มีปัญหากับ users หลังทำ tasks เสร็จ ซึ่งเราจะได้เหตุผลประกอบด้วยว่าปัญหานั้นเกิดจากอะไร

2. UT ช่วยให้ทีมที่สร้างโปรดักส์เกิด empathy และ buy in กับการแก้ไขได้ง่ายขึ้น

.

.

.

#10 ถ้าเราต้องเลือกว่าจะทำ Discovery research หรือ UT อย่างใดอย่างหนึ่งเท่านั้น ทำไมเราถึงควรเลือก UT มากกว่า?

.

พี่พิจแชร์ว่า “Discovery Research” นั้นมันมีโอกาสไปกระตุ้น Empathy แบบแปลก ๆ ให้เกิดกับทีม และกลายเป็นสร้างปัญหาให้กับโปรดักต์มากกว่าแก้ปัญหาได้ค่ะ ซึ่งมันเกิดจากการที่หลายครั้ง ทีมงานเลือกที่จะทำแค่ Discovery Research แล้วก็มีไอเดียพลั่งพรูออกมาเยอะ ต่างคนต่างคิดว่าไอเดียพวกนี้สร้างประโยชน์ให้ users อยู่ แต่จริง ๆ แล้วกลายเป็นสร้างปัญหากันรัว ๆ ได้ ถ้าไม่มีการ “เอาไปทดสอบ” กับ users จริง ๆ ก่อนค่ะ เหมือนกับเราเผลอไปเปิดกล่อง Pandora และปล่อยปีศาจออกไปสู่โลกเต็มไปหมดได้

.

ซึ่งในทางกลับกัน UT มันคือการเอาโปรดักต์มาให้ users ตัดสินกันเลยว่าดีจริงไหม เปรียบเสมือนเราให้ users มาเป็นเทพ Anubis ที่เป็นผู้ที่ตัดสินความชอบธรรมของมนุษย์ เราควรต้องเกิดการให้ users มาตัดสินโปรดักส์ที่เราสร้างกันเสมอ ไม่อย่างงั้นเราก็มีโอกาสสร้างปีศาจสู่โลกกันได้ทั้งนั้นค่ะ

.

ดังนั้นถ้าให้เลือกทำอย่างใดอย่างหนึ่ง จึงควรเลือกทำ UT มากกว่าค่ะ

.

________________________________________________________

.

และนี่คือ 10 Key learnings ที่ได้จากการฟัง talk พี่พิจค่ะ

ต้องขอขอบคุณทาง UX Thailand และ Gang Connecter ที่จัดงานดีดีอย่างนี้ขึ้นค่ะ ได้เจอคนUX ได้ฟัง talk ดีดี และได้เติมไฟในการทำงานมากเลยค่ะ

ตอนแรกเขียนเพราะกะลุ้น crybaby เฉย ๆ ค่ะ ไป ๆ มา ๆ เพลิน เขียนยาวเฉยเลยค่ะ 555

#UXTH2024