หน้า T&C เป็นหน้าเล็กๆ ที่สำคัญมากๆ เพราะมันเป็นการกำหนดข้อตกลงระหว่างเราและผู้ใช้บริการ ไม่ว่าจะเป็นเรื่องความรับผิดชอบต่อความเสียหายจากการใช้งาน เการปกป้องข้อมูลส่วนบุคคล (PDPA) การรับประกัน หรือเรื่องอื่นๆ ซึ่งผู้ให้บริการที่จริงใจก็อยากให้ผู้ใช้งานได้เข้าใจก่อน แน่นอนว่าสิ่งนี้จะเข้ามาขัดจังหวะการใช้งาน แต่ในขณะเดียวกันเราก็ไม่อยากให้ผู้ใช้รู้สึกยุ่งยาก อยากปรับให้ Experience ออกมาราบรื่นที่สุด ดังนั้นเมื่อมีความย้อนแย้ง หน้านี้จึงไม่ได้ออกแบบง่ายเลย

ตอนที่จัด Workshop วิชา Information Architecture ครั้งที่ 2 เราคุยกันถึงเรื่องการแยกวิชา UX, UI และ IA ว่าจะรู้ได้อย่างไรว่าตอนนี้เราเรียนเนื้อหาอะไรอยู่ ก็เลยมีการเล่ากับน้องๆ ว่าการแยกวิชาพวกนี้ อย่าแยกโดยใช้แนวคิดของแผนที่ปัจจุบัน ที่ใช้การตีเส้นขอบหาพื้นที่ แต่ให้ใช้แผนที่สมัยอยุธยาที่เราสนใจดูว่าเมืองหลวงอยู่ที่ไหนเป็นหลัก ทั้งสามวิชาไม่ว่าจะ UX, UI หรือ IA ต่างก็มีเนื้อหา และเครื่องมือซ้อนทับกัน จนไม่สามารถระบุขอบเขตชัดๆ ได้ แล้วแต่ว่าผู้สอน หรือผู้เรียนจะขยายขอบของมันไปถึงไหน ดังนั้นแทนที่จะมองหาขอบ หรือมองว่าเครื่องมือตัวนี้เป็นของวิชาไหน เราหันมามองหาจุด Focus ของแต่ละวิชาดีกว่า

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

เนื่องจากอาทิตย์หน้าจะได้ไปทำ Workshop Designing Strategy กับคนเขียนหนังสือเล่มนี้ “Blind spot” ในงาน UX LX เลยไปหาซื้อมาอ่านครับ ตอนแรกก็อ่านผ่าน e-Book ไม่นึกว่าเล่มจะส่งมาทัน จะได้ไปขอลายเซ็นด้วยเลย 😁 ในหนังสือเค้าพูดถึง Value ที่สำคัญแต่ business ไม่ค่อยสนใจ คือรู้ว่ามีแต่ก็ไม่ได้ลงไปวิเคราะห์ เอามาเป็น action plan ชัดๆ เพราะมันจับต้องได้ยาก ในตำราเลยมักดันไปเป็นเรื่องของ branding แบบรวมๆ ไปซะ ทั้งๆ ที่มันควรเป็น Core Value ขององค์กรได้เลยนะเลย

ในมุมของ Data Visualization ต้องบอกว่าของ Thai PBS ทำออกมาได้ดีมากๆๆๆๆ (ทีม inox.co.th) ผมชอบที่หน้าบิดข้อมูลเค้าไม่ได้เปลี่ยนภาพไปเรื่อยๆ แต่ยึดแผนที่เป็นหลักเอาไว้ตรงกลาง แล้วมีด้านขวาเป็นตัวเปรียบเทียบพรรค จากนั้นด้านซ้ายก็เอาไว้บิดข้อมูล ทำให้คนอ่านข้อมูลก็ไม่ต้องเรียนรู้ใหม่ ใช้ความเข้าใจชุดเดิมตีความได้เลย แถมทำแบบนี้ยังช่วยให้ Frontend ทำงานได้ง่ายเพราะมีแบบเดียว คนที่จัดการข้อมูล และ Backend ก็ทำงานง่ายเพราะไม่ต้องคอยจัดชุดข้อมูลหลายแบบ

ในวีดีโอเป็นรายการที่พี่รูฟเข้ามาตอบคำถาม Agile โดยไล่ตาม search suggestion ของ Google จะได้ตอบได้ตรงว่าคนส่วนใหญ่เค้าสงสัยอะไรกัน คำถามแรกที่ขึ้นมาก็เรียบง่าย “Agile คือ?” พี่รูฟบอกว่าคำถามนี้ตอบได้ 3 วัน แต่ถ้าตอบสั้นๆ มันก็เป็นประโยคนี้ เป็นกระบวนการที่ส่งมอบ software แล้วได้ feedback กลับมา อย่างต่อเนื่อง ปรับเปลี่ยนเข้ากับการแข่งขันได้ตลอดเวลา พอฟังแล้วก็พบว่าประโยคนี้ไม่ธรรมดา มันเป็นการกลั่นบทเรียน ที่เกิดจากการทำจริงๆ ออกมา ซึ่งมีทั้งแนะนำแนวทางและช่วยชี้หลุมพราง ให้ได้ในประโยคนี้เลย เลยอยากเอามาลองขยายความที่ละท่อน ว่าผมเห็นอะไรในนั้นบ้าง

ท่าแรกเราเราใช้ท่า “ทำ sub-layer ของ icon ให้เหมือนกัน” ลองย้อยกลับไปดูที่มาของปัญหาและวิธีการทำได้ใน blog ที่ผ่านมาครับ ในกรณีที่เราคุมตัว icon ให้มีชื่อ sub-layer เหมือนกันไม่ได้ หรือบางกรณีเราก็ไม่อยากรวบให้มันเหลือแค่ sub-layer เดียว หรือกรณีที่เรากลัวว่าถึงชื่อจะแสดงเหมือนกัน แต่เราก็ไม่รู้ว่ามันเหมือนกันจริงหรือเปล่า ถ้าเราตกอยู่ในสถานการณ์นี้ ท่าที่สองก็เหมาะสมดีครับ และยังเป็นท่า official ที่ Figma advocate แนะนำด้วย

ปัญหาของการสลับ icon ใน instant คือมันจะไม่จำสีเดิม พอเราเปลี่ยน icon ใหม่ ไม่ว่าจะใช้วิธี Drag & Drop แบบในภาพข้างบน หรือใช้วิธีเปลี่ยน component ที่ property ด้านขวา ก็จะได้ผลว่ามันจะใช้สีเดิมของ icon แทนที่จะเปลี่ยนสีตามที่ component ของเรากำหนดเอาไว้ ทางแก้สวยๆ ตอนนี้มีสองท่าครับ ใน Blog นี้จะเป็นท่าแรก 😁 ท่าแรก → ตั้งชื่อ layer ให้เหมือนกัน

ในหนังสือ Practical Empathy ของ Indi Young และหนังสือ The Lean Product Play book ของ Dan Olsen ทั้งสองเล่มต่างย้ำให้เราพยายามแยกผู้ใช้ตามนิสัยของเค้า แทนที่จะแยกตามสิ่งที่มองเห็น (เพศ อายุ อาชีพ รายได้) Behavioral Segments First, Then Maybe Personas การเข้าใจผู้ใช้ ไม่ใช่การรู้ว่าผู้ใช้ของเรามีลักษณะอย่างไร แต่เป็นการรู้ว่าผู้ใช้มีวิธีตัดสินใจอย่างไร เราต้องเข้าใจเจตคติ(ความเห็นต่อสิ่งหนึ่งๆ) ว่าเค้าให้คุณค่ากับอะไรมากกว่าอะไร ถ้าจะต้องตัดสินใจเค้าให้น้ำหนักกับอะไรมากกว่า