UX Research ที่ Pruxus เราทำ มีแบบไหนบ้าง

UX Research ที่ Pruxus เราทำ มีแบบไหนบ้าง? 

ช่วงนี้มีคำถามเข้ามาบ่อยพอสมควรว่า "อยากทำ UX Research แต่ไม่รู้ว่าควรใช้แบบไหน" หรือ พรักซุสมีบริการทำ Research แบบไหนบ้างนะ และแต่ละแบบใช้ตอนไหนบ้าง?

บทความนี้เลยอยากมาลงรายละเอียดเกี่ยวกับวิธีการทำ Research ของเราสักหน่อยครับ

ไม่ว่าคุณสนใจจะใช้บริการของเรา หรืออยากเอาไปทำด้วยตัวเองก็ได้เช่นกันครับ ซึ่งคิดว่าน่าจะช่วยให้เห็นภาพเกี่ยวกับ UX Research ได้ชัดขึ้นครับ ​

 

==========================

ก่อนเข้าเรื่อง:

UX Research มักจะทำแบบ 1-on-1

 

หลายคนคุ้นเคยกับ Focus Group หรือการทำ Research ที่มีคนนำสัมภาษณ์ 1 คน คุยกับผู้เข้าร่วมหลายคนพร้อมกัน ซึ่งฝั่ง Marketing มักจะใช้ Method นี้กันบ่อย ๆ และใช้ได้ดีมากครับ เพราะสิ่งที่ฝั่ง Marketing สนใจเป็นหลัก คือความรู้สึกโดยรวม ชอบ ไม่ชอบ สนใจ ไม่สนใจ น่าซื้อ ไม่น่าซื้อ

แต่ UX Research ต้องการขุดลึกกว่านั้น เราสนใจ "เหตุผลเบื้องหลัง" ว่าทำไมคนถึงทำสิ่งต่างๆ ซึ่งสิ่งเหล่านั้นมักไม่ออกมาเวลาคนอยู่กันในกลุ่มหลายคนครับ ยิ่งเป็นคนอื่นที่ไม่รู้จักด้วยแล้ว ทำให้คนมีแนวโน้มปิดกั้นตัวเอง ไม่กล้าพูดในสิ่งที่ตัวเองไม่เข้าใจ หรือเขินที่จะยอมรับว่าทำอะไรบางอย่างไม่ได้

 

​ นั่นคือเหตุผลหลักที่ UX Research เราทำแบบ 1-on-1 เสมอครับ

 

==========================

ก่อนเข้าเรื่อง (2) :

Research เราแบ่ง 2 ช่วง: ก่อน และ หลังดีไซน์

 

หลัก ๆ พรักซุสเราแบ่ง UX Research ออกเป็น 2 ช่วงครับ โดยดูที่ขั้นตอนการดีไซน์เป็นแกนหลัก และดูว่า Research ที่เราจะทำนี้ ทำ "ก่อน" หรือ "หลัง" การดีไซน์

ซึ่งทั้งสองช่วงของ Research นี้ มีเป้าหมายต่างกันชัดเจน และ methods ที่ใช้ก็ต่างกันด้วยครับ

 

==========================

ช่วงที่ 1: Research ก่อนดีไซน์ (Understand)

 

 

หัวใจของเฟสนี้คือ การ "เข้าใจ" ก่อนจะลงมือออกแบบอะไรก็ตาม เราต้องเข้าใจให้ได้ก่อนว่าปัญหาที่มีอยู่จริงๆ คืออะไร User มี Need อะไรบ้าง และเรามีข้อจำกัดอะไรที่ต้องทำงานด้วย

ถ้าเริ่มดีไซน์โดยที่ยังไม่เข้าใจตรงนี้ให้ดีพอ สิ่งที่ออกมาก็มีโอกาสสูงที่จะดูดีบนกระดาษ แต่พอใช้งานจริงกลับไม่เวิร์คครับ

 

ซึ่งหลัก ๆ จะเลือกใช้วิธีการ Research แบบไหน เราจะดูก่อนว่า ลูกค้าเคยมีโปรดักส์เดิมมาก่อนอยู่แล้วไหม? (เช่น โปรดักส์เวอร์ชันก่อนหน้า ที่อยากจะพัฒนาให้ดียิ่งขึ้น)

 

==========================

 

​ ถ้ายังไม่เคยมีโปรดักส์มาก่อน

วิธีที่เป็นท่ามาตรฐานที่สุด คือ:

"In-depth Interview" หรือการสัมภาษณ์เชิงลึกแบบ 1-on-1 กับ potential users (หรือคนที่เป็นกลุ่มเป้าหมายที่คิดว่า เค้าจะมาใช้โปรดักส์ของเราเมื่อสร้างเสร็จแล้ว)

ซึ่ง Research แบบนี้ มันไม่ใช่การสัมภาษณ์ทั่วไป ที่เราไปนั่งถามคำถามไล่ไปเรื่อย ๆ ว่าชอบหรือไม่ชอบอะไร แต่คือการให้เค้าเล่าประสบการณ์ที่ผ่านมาในอดีต ที่เกี่ยวข้องกับไอเดียของโปรดักส์ที่เราอยากจะสร้าง และทีม Research เราจะคอยเจาะทำความเข้าใจถึงเหตุผลของสิ่งที่ Users เล่ามาต่าง ๆ ขุดลึกไปถึงสาเหตุที่เค้าตัดสินใจทำสิ่งต่าง ๆ นั้น ปัญหาที่เค้าเคยเจอ และทำความเข้าใจ context ของชีวิตเขาจริงๆ

 

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

 

==========================

แต่ถ้าเรามี product เดิมอยู่แล้ว และอยากพัฒนาให้ดีขึ้น

 

ตรงนี้ทำได้ 2 แบบครับ:

 

แบบแรกเรียกว่า "Contextual Inquiry" หรือการ ให้ Users ที่เคยใช้งานเวอร์ชั่นก่อนอยู่แล้ว เปิดระบบของจริง ใช้งานให้เราดูจริง พร้อมเล่าให้เราฟังขณะที่ walk-through การใช้งานไปด้วยกัน ข้อดีของวิธีนี้คือ ทีม Researchers เราจะได้เห็นภาพจริง ๆ เลยว่าเขาใช้งานตรงไหน ทำอะไรยังไง และเมื่อเจอปัญหาต้องแก้ไขอย่างไรบ้าง ซึ่งคนเล่าก็เล่าง่ายขึ้น คนฟังก็เข้าใจและเห็นภาพมากขึ้นครับ

แถมการให้คนเล่าจากปากเปล่าล้วน ๆ โดยที่ไม่มีระบบให้ดูนั้น ความทรงจำคนเรามักจะนึกออกไม่ครบ และคลาดเคลื่อนได้ง่ายครับ

 

แบบที่สองคือ "Usability Testing" หรือ เอาระบบที่มีอยู่แล้วมาให้คนที่ "ยังไม่เคยใช้" มาทดลองใช้งานครั้งแรก (แต่ต้องเป็นคนที่มีโอกาสมาใช้งานระบบนี้ได้จริง ๆ นะ)

จุดสำคัญคือต้องเป็นคนที่ใช้ครั้งแรกเท่านั้นนะครับ เพราะสิ่งที่เราสนใจคือคนสามารถ "เรียนรู้การใช้งานด้วยตัวเองได้ไหม" ถ้าครั้งแรกมันยากเกินไป โอกาสที่คนจะเลิกใช้และกลับไปหา product เดิมก็สูงมาก

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

 

==========================

  ช่วงที่ 2: Test หลังทำดีไซน์มาแล้ว

 

 

ก่อนอื่น ต้องเข้าใจก่อนว่า "ดีไซน์" มีหลายขั้น

 

จาก Framework ที่ Pruxus ใช้อย่าง Pyramid of UX (https://www.facebook.com/share/r/19Car1bG8a/) การดีไซน์ไม่ได้หมายถึงแค่การออกแบบหน้าจอให้สวยงาม

แต่มันเริ่มตั้งแต่ขั้น Concept ว่าระบบเราจะทำอะไรได้บ้าง ไปจนถึงการออกแบบหน้าจอหลายๆ หน้าจอที่รวมกันกลายเป็น "Flow" หรือขั้นตอนที่ User ต้องกดผ่านหน้าจอต่าง ๆ ในระบบของเราจนจบ และได้ในสิ่งที่ต้องการ (ระบบตอบโจทย์ Needs ของ Usersได้ เมื่อกดจนจบ Flow)

 

==========================

แกนหลักที่เราดูว่าควรเลือก Method ไหนดี - ออกแบบ Flow แล้วหรือยัง?

 

หลักๆ เราจะดูก่อนว่าตอนนี้เราอยู่ในขั้นไหนของการดีไซน์ครับ

ถ้า ​ ยังไม่มี Flow มีแค่ไอเดียว่าระบบจะทำอะไรได้บ้าง

→ ใช้ "Concept Validation"

ถ้า ​ออกแบบ Flow เรียบร้อยแล้ว

→ ใช้ "Usability Testing"

 

==========================

 

ยังไม่มี Flow: ใช้ "Concept Validation"

 

วิธีการคือเอาไอเดียที่เรามีมาสร้างเป็น Scenario หรือเรื่องราวตั้งแต่ต้นจนจบ ว่าก่อนที่ User จะมาใช้ระบบเรา เค้าเจอปัญหาอะไร และเมื่อใช้ระบบนี้จบแล้วมันช่วยแก้ปัญหาให้เค้าได้อย่างไร แล้วเอา Scenario นี้ไปเล่าให้ User ฟัง

 

แต่หัวใจหลักไม่ใช่แค่เล่าให้ฟังแล้วถามว่าชอบหรือไม่ชอบ แต่คือการใช้ชุดคำถามที่ขุดลึกให้ได้ว่า ไอเดียนี้มันตอบโจทย์ Needs ของ User จริงๆ หรือเปล่าครับ

 

Common Mistake ที่เจอบ่อย คือหลายทีมรีบนั่งออกแบบ Flow และหน้าจอทั้งหมดก่อน แล้วค่อยเอามาทดสอบกับ User ทั้งที่จริงๆ ถ้าไอเดียยังไม่แน่ใจว่าตอบโจทย์ Needs จริงไหม เล่าเป็นเรื่องราวก็เพียงพอแล้วครับ ไม่จำเป็นต้องเสียเวลาออกแบบหน้าจอทั้งหมดก่อน

แต่ถ้าอยากมี Flow ประกอบด้วย ทุกวันนี้ AI สามารถช่วยสร้าง Flow คร่าวๆ ให้เราได้เร็วมากขึ้นแล้วครับ จะใช้ตรงนั้นมาช่วยก็ได้เช่นกัน เพราะหัวใจหลักคืออย่าเสียเวลากับการออกแบบเยอะโดยที่ Concept ยังไม่ชัด

แต่สิ่งที่ต้องระวัง คือต้องแยกให้ออกว่า สิ่งที่ User พูดว่าดีหรือไม่ดีนั้น เค้ากำลังพูดถึงอะไร — ไอเดียมันมีโอกาส "แก้ปัญหาเค้าได้จริงไหม" หรือเค้าแค่รู้สึกว่า "ใช้งานง่าย" หรือ หน้าจอ "สวย" เพราะทั้ง 3 อย่างนี้เป็นคนละเรื่องกันครับ

และนี่คือสิ่งที่ Pruxus เราให้ความสำคัญมากๆ ในการทำ Research ครับ ว่า Insight หรือแต่ละประโยคที่ User พูดมานั้น มันอยู่ในมิติไหน เพราะถ้าแยกไม่ออก สิ่งที่เอาไปพัฒนาต่อก็อาจจะแก้ผิดจุดได้ครับ

 

==========================

มี Flow แล้ว: "ใช้ Usability Testing"

 

ถ้าผ่านขั้นตอนของการ Validate ไอเดียมาแล้ว และตอนนี้มี Flow พร้อมแล้ว ก็สามารถทำ Usability Testing ได้เลยครับ ซึ่งคล้ายกับที่พูดไปใน Part 1 แต่จุดที่ต้องย้ำคือ Usability Testing วัดเรื่อง "ใช้งานง่ายไหม" ไม่ใช่ "มีประโยชน์ไหม" ทั้งสองอย่างนี้เป็นคนละมิติกันครับ

 

นอกจากนี้ยังมี Tree Testing ซึ่งเหมาะสำหรับระบบที่เมนูหรือการจัดหมวดหมู่เป็นเรื่องสำคัญ ถ้า User มักหาของไม่เจอหรืองงกับโครงสร้างของระบบ Tree Testing จะช่วยให้เราเห็นภาพชัดขึ้นว่าปัญหามันอยู่ตรงไหนครับ

 

========

 

คร่าวๆ ประมาณนี้ครับสำหรับ Methods หลักๆ ที่ Pruxus เราทำ นอกเหนือจากนี้ยังมี Methods ปลีกย่อยอีกพอสมควร ถ้ามีโอกาสจะมาเขียนเพิ่มในบทความถัด ๆ ไปนะครับ