อย่าแก้ปัญหาการสื่อสาร ด้วยการสื่อสารน้อยลง
การสื่อสารมักกลายเป็นแพะตัวแรก ๆ เมื่อเกิดความความเข้าใจผิดในองค์กร ทั้ง ๆ ที่เราก็คุยภาษาเดียวกัน ในห้องประชุมก็ดูเหมือนจะเข้าใจกันหมด แล้วมันจะเป็นปัญหาที่การสื่อสารได้อย่างไร
“ที่ทีมทำออกมาไม่ตรงเป็นเพราะ Communication Problem ต่อจากนี้เวลาที่เราตกลงในห้องประชุมแล้ว เราจะส่ง e-mail สรุปให้ทุกครั้ง” — PM ท่านหนึ่งกล่าวไว้
บ่อยครั้งที่เราได้ยินการแก้ปัญหาการสื่อสารด้วยวิธีการนี้ (ลองนึกดูว่าจริง ๆ เค้าห่วงอะไร) ที่ทีมทำออกมาไม่ตรง น่าจะเป็นพราะทีมเข้าใจผิดตั้งแต่ในที่ประชุม เราควรส่งเสริมให้รีบ ๆ มาคุยกันเพิ่มเติมดีกว่า ผมลองถามจากเพื่อน ๆ แล้วพบว่า e-mail สรุปการประชุมถ้ายังไม่มีปัญหาก็ไม่มีใครอ่าน การที่เราบอกว่าจะส่ง e-mail สรุปเป็นการบอกเป็นนัย ๆ ว่ามีสรุปอยู่ใน e-mail แล้วนะ อ่านตรงนั้นก่อน ข้อตกลงอยู่ในนั้น กลายเป็นว่าการคุยกันถือเป็นอันดับสองรองจากอ่าน e-mail
สิ่งที่เราควรทำไม่ใช่การคุยกันให้น้อยลง แต่ควรคุยให้เร็วที่สุดทุกครั้งที่มีความไม่เข้าใจเกิดขึ้น และควรหาทางปรับปรุงการคุยให้มีประสิทธิภาพมากขึ้น ทำให้เข้าใจชัดขึ้น ทำให้ไปถึงข้อสรุปได้เร็วขึ้นต่างหาก
เรื่องชวนคนมาคุยกันนี่ ทีม UX เก่งครับ เรามีเครื่องมือหลายตัวที่เข้าช่วยหลอกล่อให้คนมาคุยกัน กระบวนการส่วนใหญ่จะออกมาคล้ายกันครับ คือจะมีส่วนขยายและส่วนสรุป ผมลองยกตัวอย่างมา 5ตัว อยากให้เพื่อน ๆ ลองสังเกตุสิ่งที่เหมือนกัน ในลักษณะการทำงานของเครื่องมือแต่ละตัวดูครับ
1. Empathy Map
เครื่องมือสุด classic ที่ใช้ชวนคุยตอนเรามองผู้ใช้เป็นคนละคนกัน หรือตอนที่เราอยากจะเข้าใจผู้ใช้ของเรามากขึ้นผ่านมุมมองของคนในทีมแต่ละคน
ภาพทางซ้ายมือเป็นการทำ Empathy Map แบบดั้งเดิม คือเราจะติดสิ่งที่ผู้ใช้เห็นหรือได้ยิน (ปัจจัยภายนอก) สิ่งที่เค้าคิด (ปัจจัยภายใน) สิ่งที่เค้าพูดหรือทำ แล้วลองคิดสิ่งที่เป็น Painpoint และสิ่งที่เป็นความรู้สึกดี ๆ การทำแบบนี้บางทีก็แอบยากเพราะมีหลายช่อง เลยมีแบบใหม่เป็นภาพทางขวาซึ่งมีแค่ 4 ช่อง บางทีมก็แบ่ง Think/Feels/Says/Does บางทีมก็แบ่งเป็น See/Do/Feel/Commit ผมมองว่าใช้แบบไหนก็ได้ เมื่อไหรที่ทีมเริ่มพูดก็จะเริ่มเห็นมุมมองที่ไม่เหมือนกัน ช่วยให้เกิดการคุยกันมากขึ้น
ขั้นตอนสุดท้ายของการทำคือให้เราจับกลุ่มของ Post-it เราจะเริ่มเห็นประเด็นใหญ่ ๆ ออกมาตรงนี้ถ้าคนนำชี้ชวนให้ทีมงานแลกเปลี่ยนข้อสรุปของแต่ละคนจะดีมาก จะช่วยให้เราเห็นภาพผู้ใช้ของเพื่อนด้วย แทนที่จะเห็นของเราคนเดียว
2. Persona
เครื่องมือตัวนี้ Classic กว่า Empathy Map ซะอีก เพราะการมองผู้ใช้ให้เป็นมนุษย์เหมือนเราจะช่วยเราคิดถึงผู้ใช้มากขึ้น ยิ่งถ้าเราสังเกตุว่าแต่ละคนพูดถึงผู้ใช้ไม่เหมือนกัน การลองมาช่วยกันทำ Persona จะทำให้เราได้สื่อสารกันเยอะเลย
การทำ Persona จะต่างจาก Market Target ตรงที่มันไม่ได้ครอบคลุมคนหลายคน แต่ระบุชัดเจนเป็นคน ๆ ไปเลย จะมีหลายคนก็ได้แต่ต้องเป็นคน ๆ ไป ไม่มีแบบเป็นช่วง เช่น อายุ 20–30 ปี หรือเงินเดือน 20,000–30,000 บาท เวลาที่เราพยายามลงให้ตรงนี่ละ เป็นช่วงที่กระตุ้นการถกเถียงได้ดี ยิ่งเราแบ่งกันสร้างผู้ใช้มาซัก 4–5 คนแล้วลองถามว่าใครที่จะรัก Product ของเรามากที่สุด ก็ช่วยให้เกิดการคุยกันมากที่เดียวครับ
3. User Journey
การทำ User Journey คือการชวนคนมาคุยเรื่องราวของผู้ใช้ของเรา หรือเรื่องราวของผู้ใช้กับ Product ของเรา หลายครั้งเราคิดว่าเพื่อน ๆ ก็น่าจะคิดเรื่องราวต่าง ๆ เหมือนกับเรา แต่เอาเข้าจริงหลายครั้งกว่าจะเรียงกับออกมาลงตัวต้องใช้เวลาเป็นชั่วโมง แต่นั่นเป็นเวลาสนทนาที่มีคุณค่ามาก เพราะทำให้ทีมของเราเห็นเรื่องราวของผู้ใช้ได้ชัดเจนมากขึ้น
ผมตั้งหัวข้อว่า User Journey แต่จริง ๆ มันยังมีแบบย่อย ๆ อีก เช่น Experience Map, Service Blueprint หรือ Sprint Map เป็นต้น แต่ทุกแบบจะมีอย่างหนึ่งที่เหมือนกันคือมีแกน X เป็นเวลา ส่วนแกน Y จะเป็นช่อง ๆ แล้วแต่ว่าเราสนใจอะไร ส่วนมากก็จะเป็น User Action (ผู้ใช้ทำอะไร) Touch point (ผู้ใช้ทำที่ไหน) Emotion (ผู้ใช้รูปสึกอย่างไร) หรือบางที่ก็เพิ่ม Interface, Front Stage, Back Stage, Suport หรือ Action ของแต่ละ Persona ลงไปด้วย
สุดท้ายสิ่งที่ได้คือความเข้าใจที่เริ่มตรงกันว่าผู้ใช้จะมีชีวิตอยู่กับ Product ของเราอย่างไร
อ่านเรื่อง User Journey เพิ่มเติมได้ที่ Techsauce
4. Story Board
อันนี้เป็นเหมือนอาวุธลับเลยครับ ผมเห็นบทความที่สอนเรื่องนี้หลายครั้งมาก แต่ไม่ค่อยเห็นคนเอามาใช้ ทั้ง ๆ ที่มันทรงพลังมาก ๆ การบอกเล่าเรื่องราวของ Product ของเราออกมาเป็นเรื่อง ทำให้เห็นภาพรวมทั้งบริบทเรื่องเวลา ปัญหา ความรู้สึก จังหวะการแก้ปัญหา และอีกหลาย ๆ อย่างด้วยกระดาษแผ่นเดียว ยิ่งถ้าเราให้แต่ละคนวาด story board ขึ้นมา แล้วเอามาเล่า มันจะกลายเป็นเรื่องให้คุยกันได้อีกเยอะเลย
การทำ Storyboard ของ Product ก็เป็นแบบเดียวกับ Storyboard ของหนังครับ เรียงกันเป็นช่อง ๆ เหมือนกัน มีจุดที่เป็นปัญหา การแก้ปัญหา และผลลัพธ์ ถ้าเราดูภาพทางขวา จะเห็นว่ากระบวนการออกแบบเริ่มที่ Storyboard ก่อน แล้วค่อยวาด Wireframe จากนั้นจึงค่อยออกแบบภาพเหมือนจริงออกมา
ถ้าเราสรุปเรื่องราวของโปรแกรมของเราให้ชัดเจนในใจของทีมงาน การที่แต่ละคนจะลงรายละเอียดในส่วนของตัวเองให้เหนือกว่าที่เราวางแผนไว้ก็เป็นเรื่องที่ง่ายขึ้น
5. Assumption mapping
จะช่วงเวลาไหน ๆ ของการพัฒนา Product เราก็จะพบว่าพวกเรามีสิ่งที่อยากทำมากกว่าเวลาที่เรามีเสมอ การย้อนกลับมาคุยกันว่าเรามีข้อสันนิษฐานอย่างไร จึงอยากทำสิ่งนั้น ๆ ก็ช่วยให้เราเขาใจตัวเราและทีมงานมากขึ้น
ยิ่งถ้าเราลองเอาข้อสันนิษฐานนั้น ๆ มาวางในกราฟ Assumption Mapping ก็ยิ่งทำให้เราเห็นชัดเจนว่าอะไรที่เรามันใจแล้วสามารถเอาไปทำได้เลย หรืออะไรที่เรายังไม่มั่นใจควรเอาไปทดสอบเพิ่มเติม เราจะเริ่มเห็นว่าคนในทีมแต่ละคนมีความมั่นใจในข้อสันนิษฐานของตัวเองไม่เท่ากัน การได้คุยกันว่าจริง ๆ เราควรมั่นใจแค่ไหน ก็เป็นเรื่องทีดีมาก ๆ
ยังมีเครื่องมืออีกหลายตัวมาก ๆ เช่น Lean Value Tree, Story Mapping, Product Market Fit เป็นต้น คนที่ทำงานด้าน UX ควรมีเครื่องมือเหล่านี้ติดตัวเอาไว้ เมื่อไหรที่เริ่มเห็นความเข้าใจที่ไม่ตรงกัน หรือต้องการเปิดตัวเลือกให้มากขึ้น จะได้หยิบเอามาใช้หลอกล่อให้ทีมได้คุยกัน
ถ้าลองสังเกตุดี ๆ กระบวนการหลอกส่วนใหญ่จะมีสองส่วน คือ ส่วนขยาย และส่วนสรุป ส่วนขยายคือส่วนที่เราพยายามดึงเอาความเข้าใจหรือ idea ของทีมงานแต่ละคนออกมาให้ได้มากที่สุด ตรงจุดนี้ถ้าคนนำเก่ง ๆ จะช่วยได้มาก (Facilitator) อีกส่วนคือส่วนสรุป จะเป็นการจัดกลุ่มเพื่อให้เห็นแนวโน้ม การทดสอบเพื่อดูว่าแนวทางไหนได้ผล หรือใช้เหตุผลเพื่อหาข้อสรุป ซึ่งเครื่องมือส่วนมากจะแสดงบทสรุปออกมาในภาพสุดท้ายอยู่แล้ว
Note: ถึงภาพสุดท้ายจะเป็นข้อสรุปของการประชุม แต่ก็ไม่ต้องยึดถือว่ามันจะไม่เปลี่ยนแปลง เมื่อไหรที่เรารู้สึกว่ามันไม่ถูกต้องแล้วก็มาเปลี่ยนได้ตลอด สิ่งที่มีค่ากว่าข้อสรุปคือความเข้าใจของทีมที่สร้างภาพสุดท้ายมาด้วยกัน
ถ้าทุกการประชุมเราไม่คุยกันในอากาศ แต่หาทางเขียนข้อสรุปของเราออกมาอย่างในตัวอย่างทั้ง 5 แบบ สุดท้ายเราก็ไม่ต้องเขียน e-mail สรุปขึ้นมาให้เป็นภาระที่ทุกคนต้องมาทำความเข้าใจใหม่ แค่ให้ทุกคนถ่ายภาพบอร์ดที่สร้างขึ้นมาด้วยกันก็พอ ถึงจะอ่านยากหน่อยแต่ของที่สร้างมากับมือมันก็น่าจะเข้าใจมากกว่าครับ
5 ตัวอย่างนี้เป็นเครื่องมือหลอกให้คนคุยกันของ UX ถ้าสนใจว่าทีม Scrum เค้ามีเครื่องมืออะไรบ้าง ลองเข้าไปอ่าน blog ของพี่โอ ได้นะครับ
หรือถ้าสนใจเรื่อง UX อื่น ๆ สามารถดูได้ที่ blog.uxacademy.in.th มีบทความที่น่าสนใจหลายเรื่อง เช่น
ส่วนบริษัทไหนต้องการหาทีมงาน UX มืออาชีพมาช่วยงาน ลองติดต่อ Ahancer ดูนะครับ
