User Journey คืออะไร ใช้ตอนไหนบ้าง?

เคยสงสัยไหมครับ ว่าผู้ใช้ของเรามีประสบการณ์อย่างไรเมื่อเขาใช้บริการผลิตภัณฑ์ของเรา 🤔 พวกเขามีความสุข หรือกำลังประสบปัญหาบางอย่างอยู่ มันอาจจะเป็นปัญหาที่ทีมของเราเห็นอยู่แล้ว หรือบางปัญหาเราอาจจะไม่เคยคิดถึงมาก่อนเลยก็ได้ คนที่เป็น UX เมื่อเจอข้อสงสัยแบบนี้ เค้าจะใช้เครื่องมือไม้ตายที่ชื่อ “User Journey” ครับ

ในบทความนี้ เราจะไปดูว่า (1) หน้าตาของมันเป็นอย่างไร มีองค์ประกอบอะไรบ้าง (2) มีกี่แบบ (3) ตัวอย่างสถานการณ์ที่จะเอาไปใช้ และ (4) นอกจาก User Journey มันมีอะไรที่ทำงานได้คล้ายๆ กันอีกมั๊ย เราไปดูกันทีละข้อเลยครับ

User Journey หน้าตาเป็นอย่างไร

หน้าตาของ User journey ต้องแสดงให้เราเห็นว่าประสบการณ์ของผู้ใช้ ตั้งแต่ช่วงแรกที่เขาเริ่มต้นสัมผัสกับผลิตภัณฑ์ของเรา ผ่านกระบวนการต่าง ๆ ไปจนได้รับบริการจากเราเรียบร้อยนั้น ดำเนินไปอย่างไร โดยเราจะแบ่งเป็นบรรทัดๆ ได้ดังนี้

บรรทัดที่ 1 : Action

เริ่มจากบรรทัด Action ก่อน เพราะเป็นหัวใจของ User Journey ครับ เราสนใจสิ่งที่ผู้ใช้ทำเป็นหลัก หรือบางครั้งก็ใช้กับการถูกทำก็ได้ เช่น ผู้ใช้ “ตั้งเวลาปลุก” หรือ ผู้ใช้ “ถูกปลุกให้ตื่น” ในกรณีที่เราพัฒนา Application เรามักเรียง Action ตามหน้าจอที่ต้องออกแบบ แต่ถ้าในหน้านั้นมีหลาย Action เราก็ไม่ต้องยึดติดว่าต้องทำไปทีละหน้านะครับ เน้นไปตาม Action ของผู้ใช้เป็นหลัก ในหน้าหนึ่งๆ อาจจะมีหลาย Action ก็ได้

บรรทัดที่ 2 : Touchpoint

บรรทัดที่สองคือ Touch point เป็นที่ๆ ผู้ใช้กระทำ หรือถูกกระทำ เช่น “มือถือ”, “ป้ายโฆษณา”, “ทีวี” หรืออื่นๆ ที่ผู้ใช้มีปฏิสัมพันธ์ด้วย ถ้าเราทำ Application แทนที่เราจะพูดรวมๆ เป็นมือถือ หรือคอมพิวเตอร์ เราอาจจะลงรายละเอียดไปว่าหน้าจอไหนที่ผู้ใช้กำลังใช้อยู่ก็ได้ เช่น “หน้าแรก”, “หน้าจ่ายเงิน”, “หน้าค้นหา” เป็นต้น แล้วแต่ว่าเราอยากจะเห็นละเอียดแค่ไหนใน Journey นี้

ผมแนะนำให้เริ่มจาก Action แต่บางครั้งถ้าเรานึกไม่ออกว่าผู้ใช้ต้องทำอะไรบ้าง เราอาจจะเริ่มจากผู้ใช้ทำที่ไหนก็ได้ แต่ตอนที่เอามาเรียงควรเรียงให้ Action และ Touchpoint ตรงกันเสมอ ตามรูปข้างบน ไม่งั้นคนที่เข้ามาอ่าน Journey ของเรา จะงง ไม่รู้ว่าสิ่งที่ผู้ใช้ทำนั้นๆ เกิดขึ้นที่ Touchpoint ไหน

ทั้งนี้เราสามารถเขียน Touchpoint ซ้ำกันได้นะครับ เช่น “หน้า Home” อาจจะเกิดขึ้นที่ Action “เปิด App” และ Action “ปิดนาฬิกา” ทั้งสองที่เลยก็ได้ ไม่ต้องกลัวว่าจะเขียนซ้ำเยอะๆ เอาให้เข้าใจง่ายไว้ก่อนดีกว่าครับ

บรรทัดที่ 0 : Timeline

บรรทัดบนสุดเอาไว้กำกับใจของเราว่าเวลาของผู้ใช้บน User journey นั้นเดินจากทางเดียวไม่มีการย้อนกลับ ในใจของเราต้องเห็นภาพของผู้ใช้อยู่เสมอว่าเค้าเป็นอย่างไรบ้างบน Timeline ของเรา เกิดความสงสัยอะไร คิดอะไร หนักใจอยู่หรือเปล่า กำลังพยายามแก้ปัญหาอะไร จุดที่แก้ปัญหาอยู่ตรงไหน จบอย่างไร

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

บรรทัดนี้เป็นเคล็ดลับในการเขียน Journey เลยครับ เพราะมันช่วยให้เราเห็นภาพร่วมก่อนที่จะเขียน Action และ Touchpoint ทำให้ทุกอย่างมันสอดคล้องเป็นเหตุเป็นผลกัน ความน่ากลัวของการไม่มีบรรทัดนี้คือ Journey ของเราอาจจะไม่สมจริงได้ง่ายๆ ครับ และจะทำให้ต้องใช้เวลาในการสร้างนานขึ้นแทนที่จะเสร็จอย่างรวดเร็ว อยากให้ยอมเสียเวลาสร้างมันขึ้นมาก่อน จะสร้างในใจหรือจะเขียนมันออกมาก็ได้ครับ

User Journey มีกี่แบบ

ถ้าพูดถึงหน้าตาของ User Journey มันจะมีหลากหลายมาก เช่น เป็นแบบละเอียดถ้าเราสนใจทุก Micro interaction ของผู้ใช้ ก็จะทำให้ User Journey ของเรายาวมาก หรือถ้าเรามีประเด็นที่เราสนใจเยอะๆ เราก็จะเพิ่มบรรทัดลงไปใน Journey ของเรา เช่น บรรทัด UI, บรรทัดความรู้สึกของผู้ใช้, บรรทัดเวลา เป็นต้น ก็จะทำให้เราสร้าง User Journey แบบใหม่ๆ ได้นับไม่ถ้วน

แต่ถ้าจะแบ่ง User Journey ไปตามช่วงเวลาของผลิตภัณฑ์ ก็จะแบ่งได้ 3 แบบครับ คือ As-is, To-be และ Transition เราลองมาดูไปทีละอัน

(1) As-is : ก่อนมาใช้ผลิตภัณฑ์ของเรา

เป็นการเขียน User Journey ในช่วงเวลาที่ปัญหาของผู้ใช้ยังไม่ถูกแก้ เพื่อดูว่าปัญหาเกิดขึ้นได้อย่างไร ดำเนินไปอย่างไร ผู้ใช้ของเราจัดการปัญหาด้วยวิธีการใด

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

ในจุดนี้ก็มีโอกาสที่เราจะช่วยเค้าได้หลายจุด เช่น การฝืนทำงานต่อจะดีมั๊ยนะ? หรือนอนพักเร็วๆ แล้วค่อยตื่นมาทำงานจะดีกว่า หรือความกังวลเรื่องงาน ถ้าเราหาทางให้เค้าวางงานได้ ไม่กลัวว่าตื่นแล้วจะลืม ก็น่าจะดี

การเขียน User Journey แบบ As-is สำคัญมากๆ เพราะทำให้เราอยู่กับ Problems Space นานขึ้น เห็นปัญหาจริงๆ ก่อนที่จะรีบกระโดดไป Solution Space

(2) To-be : หลังจากที่ใช้ผลิตภัณฑ์ของเราแล้ว

เมื่อเราเริ่มเห็นแล้วว่า Solution ของเราจะออกมาแบบไหน การเขียน User Journey แบบ To-be จะช่วยเราเห็นภาพของผู้ใช้ขณะที่กำลังใช้ผลิตภัณฑ์ของเราชัดขึ้น ยิ่งเราแบ่งเป็นขั้นตอนที่ละเอียด เราจะเห็นเลยว่าแต่ละขั้นมันต่อเนื่องกันหรือเปล่า ผู้ใช้ต้องสลับ Touch point ไปมาหรือไม่ ทำให้เห็นทั้งโอกาสและปัญหา ช่วยให้เราเห็นโอกาสในการพัฒนาผลิตภัณฑ์ของเราให้ดีขึ้นได้

อย่างในรูปนี้เราวางว่าจะมีคนแนะนำ App ซึ่งอาจจะไม่ดีเพราะผู้ใช้อาจจะไม่มีคนที่รูจัก App ของเราอยู่ใกล้ๆ ถ้าเราแก้เป็นเว็บไซต์ แล้วผู้ใช้ค้นหาเจอน่าจะดีกว่า ซึ่งทำให้รู้ว่าเราต้องมี Web แล้วล่ะ

จะเห็นว่าปัญหาที่เจอส่งผลต่อความสำเร็จของผลิตภัณฑ์ของเรา แม้ว่าเว็บไซต์จะไม่ได้เป็นส่วนหนึ่งของ App ก็ตาม

(3) Transition : ช่วงระหว่างกำลังค่อยๆ เปลี่ยนมาใช้ผลิตภัณฑ์ใหม่ของเรา

ผู้ใช้ไม่ได้เปลี่ยนมาใช้ผลิตภัณฑ์ของเราแล้วลืมของเก่าในทันที หรือแย่กว่านั้นก็อาจจะใช้ของเก่าควบคู่ไปกับของใหม่ด้วย และเราต้องทำให้ประสบการณ์ของผู้ใช้ออกมาดีที่สุดแม้ในช่วงเวลาของการเปลี่ยน

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

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

ตัวอย่างสถานการณ์ที่จะเอาไปใช้

สมมุติว่าเราถูกจ้างให้เข้าไปช่วยออกแบบ เว็บไซต์ขายอุปกรณ์กีฬา ด้วยโจทย์ที่ว่า “มีผู้ใช้เข้ามาที่หน้า Home ของเราเพิ่มขึ้นเยอะมาก แต่ยอดขายกลับไม่เพิ่มขึ้นตามจำนวนผู้ใช้ที่เข้ามา” เราก็อยากรู้เลยว่าเกิดอะไรขึ้น เราเลยชวนเจ้าของเว็บมาช่วยกันวิเคราะห์ โดยใช้ User Journey เป็นตัวแกะความเข้าใจของเจ้าของออกมา

👆 As is (สภาพปัจจุบัน): เราชวนเจ้าของเว็บมาวาด User Journey ปัจจุบันเพื่อให้เห็นปัญหาได้ชัดเจนมากขึ้น

พอวาดเสร็จเราจะสังเกตว่า แม้เราพาผู้ใช้เข้ามาที่เว็บได้ก็จริง แต่ผู้ใช้กลับต้องเข้ามาค้นหา “กางเกงมวย” ในเว็บซ้ำอีกรอบ แม้ว่าจะค้นเจอผ่านทาง Google ไปแล้วก็ตาม เราเลยมีสมติฐานว่า “ถึงผู้ใช้จะรู้ว่ามีกางเกงนี้อยู่บนเว็บ แต่พอต้องใช้ความพยายามในการหาอีกรอบ ก็เป็นไปได้สูงที่ผู้ใช้จะออกจากเว็บเราไป” แทนที่จะพยายามหาจนเจอ

Journey แบบ As-is คือการดูว่าปัจจุบันผู้ใช้เป็นอย่างไร ช่วยให้เราระบุปัญหาได้ชัดเจนมากขึ้น

✌️ To be (สภาพในอนาคต): หลังจากที่ไปคุยกับทีม Data Analytic เพื่อยืนยันสมติฐานของเราแล้ว ก็พบว่าผู้ใช้เข้ามาที่หน้าเว็บเราผ่านทางการค้นหาสินค้าบน Google จะออกไปจากเว็บของเราโดยไปไม่ถึงสินค้าที่ต้องการจริงๆ

เราเลยชวนทีมพัฒนามาร่วมปรับปรุง Journey ของผู้ใช้ใหม่ โดยแทนที่จะติด Link ไปที่หน้า Home ก็ให้ติด Link พาผู้ใช้มาที่หน้าสินค้าแทน วิธีนี้จะช่วยลดขั้นตอนไปได้หลายขั้น และน่าจะช่วยให้เกิดการซื้อสิ้นค้ามากขึ้น

Journey แบบ To-be คือการวาด idea ของเราออกมา ซึ่งทำให้เห็นความเสี่ยง และความบกพร่องของ idea ของเราได้ชัดเจนง่ายขึ้น

🤟 Transition (ช่วงการเปลี่ยนแปลง): แม้เราจะมีแผนที่ดีแล้ว แต่เราก็รู้ว่ามีผู้ใช้จำนวนหนึ่งอยากเข้าไปที่หน้า Home ก่อนเพื่อจะดูว่ามีสินค้าอะไรที่ใกล้เคียงกันบ้าง นอกจากนั้นทั้งทีมพัฒนาก็กังวลว่า ถ้าพาผู้ใช้เข้าไปที่หน้าสินค้า แล้ว พอผู้ใช้กดปุ่ม Back เพื่อหาสินค่าใกล้เคียง ผู้ใช้ก็จะหลุดออกจะเว็บเรากลับไปที่ Google เลยแทนที่จะอยู่ค้นหาสินค้าบนเว็บของเรา

ทีมพัฒนาจึงเสนอว่าแทนที่จะพาผู้ใช้ไป “หน้ากางเกงที่ชอบ” ทันทีที่เข้ามาบนเว็บเรา ก็ให้พาไปหน้าค้นหาก่อนแล้วดึงกางเกงที่ชอบขึ้นมาเป็นอันดับหนึ่งในผลการค้นหาของหน้านั้น จะทำให้ผู้ใช้สามารถหาสินค้าเจอได้อย่างรวดเร็ว และเมื่อดูสินค้าแล้วอยากเปลี่ยนใจ พอกดปุ่ม Back ก็จะกลับมาที่หน้าค้นหา ไม่หลุดไปจากเว็บของเรา 🎉

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

สรุปตัวอย่าง

จะเห็นว่าเราสามารถประยุกต์ใช้ User Journey ในการทำความเข้าใจกับปัญหาที่เราเผชิญอยู่ได้หลายสถานการณ์ ไม่ว่าจะเป็นสถานการณ์ปัจจุบัน (As-is) หรือสถานการณ์ตอนที่แก้ปัญหาไปแล้ว (To-be) หรือถ้าอยากจะแสดงสถานการณ์ที่เรากำลังค่อยๆ พัฒนาก็ยังทำได้ด้วย ไม่จำเป็นว่าต้องทำ User Journey ที่ถูกต้องตามตำราเท่านั้น เราสามารถประยุกต์ใช้มันได้มากมาย อะไรที่ทำให้เราเข้าใจปัญหา หรือออกแบบแนวทางการแก้ปัญหาได้ง่ายขึ้น ก็ให้ทำแบบนั้นได้เลย

User Journey เป็นเครื่องมือสำหรับการเล่าเรื่อง (Storytelling) แบบหนึ่ง ที่ช่วยให้เราจิตนาการตามได้ว่าตอนใช้งานจริงจะเป็นอย่างไร ทำให้คาดการปัญหาได้ มองเห็นทางแยกต่างๆ ที่น่าจะเกิดขึ้น รวมถึงเห็นความเชื่อมโยงของข้อมูลต่างๆ ของผู้ใช้ตั้งแต่เริ่มใช้งานไปจนจบ ง่ายกว่าการมองทีละชิ้น — by พี่นุ่น

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

องค์กรไหนที่มีปัญหาการสื่อสาร (Communication problems) ลองชวนกันทำ User Journey นะครับ มันไม่ใช่แค่ได้เข้าใจ แต่มันสนุกด้วยครับ 😚

นอกจาก User Journey มันมีอะไรอีก

แน่นอนว่าสำหรับคนที่เป็น Experience Designer เราไม่อยากให้ประสบการณ์ของผู้ใช้มาด้วยความบังเอิญ เราอยากออกแบบมันไว้ก่อน ดังนั้นเราจึงมีเครื่องมือมากมายที่ช่วยในการออกแบบประสบการณ์ของผู้ใช้

แม้ว่า User Journey จะเป็นไม้ตายสำคัญ​แต่ก็ยังมีอย่างอื่นที่คล้ายๆ กันอยู่ครับ เครื่องมือแต่ละตัวก็จะมีจุดเน้นของตัวเองเหมือนกัน อย่าง “User Journey ก็จะเน้นหาว่าผู้ใช้ทำอะไรบ้างไปตามเวลา” ตัวอื่นๆ ก็จะเน้นตามนี้ครับ

• User Flow เน้นว่าผู้ใช้ทำอะไรไปตามเงื่อนไขของระบบ
• Service Design Blueprint เน้นวิเคราะห์เบื้องหลังว่าต้องทำอะไรบ้าง เพื่อให้ผู้ใช้ได้รับประสบการณ์ตามที่เราออกแบบไว้
• Experience Map เน้นวิเคราะห์ประสบการณ์ของผู้ใช้ว่าแต่ละขั้นนั้นผู้ใช้รู้สึกอย่างไร (บางตำราจะบอกว่ามันเหมือน User journey แต่จะเฉพาะเจาะจงผู้ใช้บางคนเป็นพิเศษ)
• Funnel เน้นวิเคาะห์ว่าตั้งแต่ผู้ใช้เข้ามาในระบบมีหลุดออกไปตรงไหนบ้าง สุดท้ายแล้วเกิดการซื้อ หรือใช้งานสำเร็จเท่าไหร เทียบกับจำนวนที่เข้ามา

เครื่องมือแต่ละตัวก็จะมีเทคนิคในการใช้งานไม่เหมือนกัน ใช้กับสถานการณ์ที่ไม่เหมือนกัน ใครสนใจตัวไหนก็บอกไว้ได้นะครับ เดี๋ยวเราเอามาเล่ากันอีกที ✌️

ถ้าสนใจเรื่องของ UX เพิ่มเติมสามารถติดตามได้ที่ Blog ของ UX Academy นะครับ มีบทความที่น่าสนใจอีกหลายบทความเลย เช่น สามบทความนี้

มองผ่าน The Hooked Model: ทำไมเราถึงติด Pokemon Go?

Assumption Mapping จาก Workshop ของ Jonny Schneider

ลูกค้าอยากได้ไปหมด ทำอะไรก่อนดี

หรือสามารถติดตาม Workshop ที่กำลังจะจัดได้ที่ uxacademy.in.th ครับ