จากตอนที่แล้วเราพูดถึงภาพรวมของ BiRD ไป (ตอนที่ 1: แก้ปัญหา Business Requirement ด้วย BiRD Canvas) มาตอนที่สองเราจะเริ่มลงรายละเอียกในการเขียนแต่ละส่วนกันครับ โดยเริ่มจากส่วนบนสุดกันก่อน

BiRD ย่อมากจาก Business impact Requirement Description เป็น Frameworks ที่ทีม ODDS พัฒนาต่อยอดมากจากหลายๆ แนวคิด เพื่อนำมาแก้ปัญหา Requirement ไม่ชัดเจน (เอกสารความต้องการจากผู้ใช้งานที่จะส่งไปให้นักพัฒนาไม่ชัดเจน) เป็นต้นเหตุให้งานล่าช้า หรือหลายครั้งงานที่ได้ออกมาไม่สามารถนำไปแก้ปัญหาได้จริง แม้จะทำตามเอกสารทุกอย่างแล้วก็ตาม

ปัญหาอยู่ตรงไหน (Why)

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

ถ้ามองย้อนกลับไปที่ผู้เกี่ยวข้องหลัก 3 ฝ่าย

1. …

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

มาลองดูลักษณะของ Group ก่อน

โดยปกติแล้วเวลาที่เราจะเปลี่ยนข้อมูลหรือย้ายที่วัตถุหลายๆ ตัวพร้อมกัน เราก็จะใช้วิธีกด Shift หรือ Ctrl ค้างไว้ แล้วคลิ๊กบนวัตถุที่เราต้องการแก้ไขไปเรื่อยๆ มันจะเกิดกรอบขึ้นแล้ว แล้วเราจะสามารถแก้วัตถุทุกชิ้นในกรอบนั้นไปพร้อมๆ กันได้ นั้นก็ถือเป็นการ Group แล้ว แต่เป็นกลุ่มที่อยู่ได้ไม่นาน เพราะเมื่อเราไปคลิ๊กที่วัตถุอื่นหรือกด ESC ความเป็นกลุ่มก็จะหายไป

ถ้าเราอยากให้ความเป็นกลุ่มอยู่ไปยาวๆ หลังจากเลือกแล้วให้กด ctrl+g (Windows) หรือ Cmd+g (Mac) วัตถุที่เราเลือกก็จะถูกรวบมาเป็นกลุ่มเดียวกัน

รูปชวนคิดเพื่อเทียบให้เห็นการทำงานที่สนใจผลลัพธ์มากกว่าผลงาน และ เน้น Efficiency (ประสิทธิภาพ) มากกว่า Agility (ความคล่องแคล่ว)

ผมวิเคราะห์สองภาพแบบนี้

🏃 ”ภาพแรกเป็นการวิ่งให้ได้วิ่ง ไม่ได้งาน” เน้นทำแบบเดิมควบคุมตัวแปลทั้งหมด มี Agility น้อย เน้นหาทางเพิ่ม efficiency ให้สูงที่สุด

output = วิ่ง

🦁 “ภาพที่สองคือวิ่งให้ได้งานจริงๆ” กำลังล่าสัตว์ในเส้นทางที่คล้ายเดิมแต่ไม่เหมือนเดิมแน่นอน ควบคุมไม่ได้ว่าสัตว์จะวิ่งไปทางไหน ต้องมองความเปลี่ยนแปลงของเป้าหมายและพื้นตลอดเวลา ต้องมี Agility สูงมาก ไม่งั้นไม่มีทางได้ข้าวเย็น

outcome = มีข้าวเย็นกิน

ปัญหาของวิ่งแบบที่สองคือครั้งแรกๆ จะช้ามากแทบหาข้าวเย็นไม่ได้เลย (สร้าง Agility ช่วงแรกที่ทำงานช้า ไม่แปลก) จนตอนหลังที่เริ่มทำ automation ได้ เริ่มมองสัตว์และพื้นไปพร้อมๆ กันได้ จึงจะเริ่มได้งาน

ถ้าอยากให้มีข้าวกินเร็วๆ ก็ให้จ้างโค้ช 😅

🏌️‍♀️ ถ้าเทียบกับการทำงานเป็นทีมระหว่าง “ทีมนักกีฬา” กับ “ทีมนักล่า”

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

🧑‍💻 ถ้าเทียบกับงาน Software Development เราไม่ได้เน้นเขียน code!!

จริงๆ code น้อยเป็นเรื่องดี เราเน้นงานที่โปรแกรมทำออกมาได้มากกว่า ว่ามันช่วยให้ผู้ใช้ทำงานง่ายขึ้นได้อย่างไร

ถ้าเน้นเขียน code เยอะๆ = เขียนโปรแกรม “ปลอม”
ถ้าเน้นงานที่ได้จาก code = เขียนโปรแกรม “จริง”

คนทำงานด้าน UX เป็นตัวแปลใหญ่ๆ ในการสร้างนวัตกรรม และทำให้ทุกคนในทีมมองเห็นเป้าหมายร่วมกัน มองเห็นว่า User ของเราเปลี่ยนไปทางไหน อยากให้ UX ทุกคนรู้ว่าคุณคือคนที่สำคัญมากๆ ถ้าทีมต้องการจะมี Agility

Application Icon เป็นการสร้าง First impression ของโปรแกรมเรากับผู้ใช้ แต่จุดสำคัญไม่ใช่แค่นั้น Application Icon ยังถูกใช้ในอีกหลายบริบทเลย

ดังนั้นการเลือก App Icon ไม่เหมือนการเลือก Logo บริษัท

บริบทที่สำคัญมากๆ ของ App Icon คือการทำให้ผู้ใช้สามารถหา Application ของเราเจอในเวลาที่น้อยสุด เพราะการหา App เจอก็ถือเป็น Experience ที่สำคัญมากเช่นกัน 🤔

อย่าลืมว่า App ​Icon ของเรามักมีคู่แข่งมากถึง 7 แถว 4 คอลัมน์ รวม 28 Apps แถมยังไม่ได้มีหน้าเดียวด้วย และบางทีอาจจะเลวร้ายกว่านี้ถ้า App ของเราเราถูกเอาไปใส่ไว้ใน Folder จนเหลือตัวเล็กนิดเดียว ผู้ใช้บางคนอาจจะมี App มากถึง 58 Apps เลยทีเดียว

การจะทำให้ผู้ใช้หา App Icon ของเราเจอได้เร็ว เราต้องสร้างรูปทรง (shape) ให้ชัด เพื่อให้ผู้ใช้ไม่ต้องจดจำรายละเอียด เพียงแค่เห็นสีและรูปทรงคุ้นๆ ก็รู้ได้เลย (ทั้งนี้ต้องเผื่อคนที่ตาบอดสีด้วยนะ) ตอนที่เราทำการทดสอบเพื่อเลือก App Icon เราจึงมักใช้ภาพที่เบลอๆ เพื่อให้แยกของที่มีรูปทรงชัดและไม่ชัดออกจากกัน

อย่างในรูปข้างล่างพอจะทายกันถูกหรือเปล่าครับ ว่ารูป Icon ไหนเป็นของ Application อะไร?

ถ้า Icon ที่ออกแบบมาดี แม้ว่าจะเห็นเร็วๆ ตอนที่ขึ้นมาพร้อม Notification ผู้ใช้ก็สามารถแยกได้ว่าเป็นโปรแกรมอะไร ช่วยให้ผู้ใช้ได้รับข้อมูลของเราเร็วขึ้น หรือตอนที่ icon ของเราถูกย่อขนาดเป็นตัวเล็กๆ ในหน้า Setting…

ทีมพัฒนา Software มักใช้งาน UX เพื่อเตรียมของให้กับทีมพัฒนา แต่ถ้าทีมพัฒนานั้นใช้ Agile งานของ UX ก็จะครอบคลุมไปถึงการช่วยทีมพัฒนา และการนำของที่พัฒนาแล้วไปทดสอบด้วย
.
เพราะทีม Agile ไม่ใช่ทีมที่ตะบี้ตะบันทำของให้เสร็จ แต่ทีมนี้ต้องปรับเปลี่ยนตัวเองตามผู้ใช้เพื่อความสำเร็จของงาน (ของสำเร็จ ไม่จำเป็นต้องเสร็จก็ได้)

ดังนั้นทีม UX จึงมีหน้าที่เพิ่มขึ้น

👩‍🎨 อย่างแรกคือต้องคอยวาดฝัน ออกแบบล่วงหน้า ทำงาน research เพื่อยืนยันเป้าหมาย คุยกับ PO เพื่อให้รู้ทิศทางของ Product ต้องหาทางที่ทำให้ User Win, Business Win, Operation Win

👨‍💻 อย่างที่สองคือ ต้องคอยช่วยทีมปรับงาน เพราะตอนเริ่มงานจริงๆ มักมีสิ่งที่คาดไม่ถึงโผล่ออกมาเสมอ โดยเฉพาะงาน Software ที่เรากำลังสร้างของที่ไม่เคยมีมาก่อนบนโลกใบนี้

🙆‍♀️ สุดท้ายคือเอาไปทดสอบ! เรารู้ดีกว่า Done <> Value ของเสร็จไม่จำเป็นต้องมีคุณค่า ถ้าผู้ใช้ไม่ยอมใช้มันก็มีค่าเท่ากับศูนย์ ดังนี้ทีม UX ต้องคอยเอางานไปทดสอบด้วย พอได้ผลออกมาคนที่เป็น PO จะปรับปรับแผนได้

เพราะ Agile คือความคล่องแคล่วในการปรับตัว (Inspect & Adapt) ถ้าไม่ทำทั้งสามอย่างเราจะมีข้อมูลไปปรับตัวได้อย่างไร

อาทิตย์ที่ผ่านมา UX Academy ร่วมกับ Skooldio จัดสอนแบบ Online UX Workshop ได้ผลตอบรับดีกว่าที่คิดเอาไว้มาก ผู้เรียนสนุกบอกให้หยุดก็ไม่ยอม 😆

เลยเอารูปการจัดจัดอุปกรณ์ของทีมงานมาให้ดูครับ

ส่วนที่สำคัญมากๆ น่าจะเป็นการที่เราใช้ ipad เป็น Sidecar แล้ว duplicate หน้าจอออกมาเพื่อให้สามารถวาดภาพบนหน้าจอได้ และยังสามารถใช้โปรแกรม Google Docs, Keynote ได้แบบ Desktop ด้วย

พระเอกคือโปรแกรม ScreenBrush ที่ทำให้เราเขียนภาพทับบนหน้าจอ ipad ได้
💁 https://imagestudiopro.com/screenbrush/
แต่ต้องจำ shortcut สองสามตัวเพื่อให้ใช้ได้เร็วพอที่จะเอามาสอน

ส่วนประกอบสำคัญอีกตัวคือ OBS และ Zoom Host เพราะช่วยให้เครื่องผู้สอนทำงานได้เร็วขึ้น ไม่ต้องถูก zoom แยกหน่วยความจำไป ทำให้ขยับได้คร่องและ sidecar ไม่ตาย

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

🙇‍♂️ ต้องขอบคุณทีมงานของ Skooldio ทุกคนมากๆ ครับ

การจัด Workshop ครั้งนี้เป็นสิ่งหนึ่งที่ผมฝันไว้นานแล้ว ว่าอยากจัด Workshop ให้คนที่ไม่ได้อยู่กรุงเทพบ้าง เพราะต้นทุนในการเดิมทางมันแพง ครั้งนี้ก็มีคนที่มาจากที่ไกลๆ หลายคนเลยรู้สึกดีใจมาก 🎉

ถ้าอาจารย์ท่านดูภาพแล้วมีคำถามสามารถสอบถามใน comment ได้เลยนะครับ 👩‍🏫

Simplicity is the ultimate sophistication
— Leonardo Da Vinci 💆‍♂️
.
การหาทางออกที่เรียบง่ายมันไม่ง่ายเลย อุปสรรคใหญ่คือทางเก่าๆ ที่ใช้กันมาคอยดึงเราให้กลับไปใช้หนทางเดิม การบุกเบิกหนทางใหม่ต้องอาศัยความกล้า และที่สำคัญที่สุดคือต้องเข้าใจในบริบทของปัญหานั้นเป็นอย่างดี
.
🧐 ที่สำคัญต้องรู้ว่าทำไมคนเก่งๆ ในอดีตถึงไม่เลือกหนทางนั้น คนที่พูดว่าจะทำของให้เรียบง่ายโดยไม่เข้าใจก่อนจะมีความเสี่ยงสูงมากที่จะเผชิญปัญหาแบบเดียวกับคนอื่นๆ ที่ผ่านมา แล้วเลิกล้มความตั้งใจในที่สุด
.
แต่เราก็ยังเห็นคนทั่วไปก็ยังคิดว่า “การทำของให้เรียบง่ายนั้นทำง่าย” นั่นก็เพราะว่า
.
🤷‍♂️ “เมื่อพวกเราเห็นทางที่เรียบง่าย เราจะนึกไม่ออกเลยว่ามันยากตรงไหน”
.
นักธุรกิจจำนวนมากจึงมักบอกว่าเราจะสร้างความได้เปรียบโดยการทำให้ง่าย ทั้งๆ ที่ยังไม่รู้เลยว่าจะทำให้ง่ายได้อย่างไร
.
อย่างไรก็ตามนั่นก็ถือเป็นจุดเริ่มต้นที่ดีครับ ว่าเค้าให้ความสำคัญกับเรื่องนี้ ลำดับถัดไปคือการลงมือศึกษาให้ลึกซึ้งจนเข้าใจบริบทของปัญหาอย่างแท้จริง และเริ่มแก้ปัญหาที่นักบุกเบิกรุ่นแรกเผชิญอยู่ เมื่อเราเข้าใจได้ลึกซึ้ง หนทางที่เรียบง่ายก็จะเริ่มสองแสงออกมาให้เห็นเอง 🔦
.
โลกแห่งความเรียบง่ายนั้น ช่างซับซ้อนยิ่งนัก 💆‍♀️