สิ่งที่ได้จากงาน UX Talk #3

ที่มา รูปภาพจากทีมงาน UX Talk ครับ

เมื่อวันเสาร์ที่ 4 พฤษภาคม 2559 ได้ไปงาน UX Talk ครั้งที่ 3 มาครับ
งานครั้งนี้มีแนวความคิดหลักที่ว่า Empathy ถ้าแปลตรงตัว คือ การเอาใจใส่
ทีนี้ รายละเอียดภายในงานหรือเนื้อหาที่วิทยากรบรรยาย อีกสักพักก็คงมีทีมงาน
เผยแพร่วิดีโอที่ถ่ายในงานมาให้คนทั่วไปได้ชมครับ

คุณ Natt Phenjati สรุปเนื้อหาในงานไว้แล้ว อ่านได้ที่นี่เลยครับ

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

ไปแล้วก็ได้อะไรกลับมาเยอะครับ รู้ว่าคนเก่งเพียบ คนเจ๋งเพียบ เรามันตัวเล็ก ๆ อีกแล้ว ฮ่า ๆ ยิ่งออกไปพบคนมาก ตัวเรายิ่งเล็กลงครับ เป็นแรงผลักดันดีจริง ๆ

ในฐานะที่คาดหวังในชีวิตตัวเอง ในอนาคตว่าอยากเป็น Software Engineer ที่ดี (คำว่าดี ดีอย่างไร อันนี้ไม่แน่ใจ เดี๋ยวไว้เรียนจบอาจจะมาเขียนอีกที) การได้มาฟังเรื่อง UX ช่วยให้เห็นภาพในการทำงานได้มากขึ้น จากที่ฟังมา ขอลิสต์เป็นข้อ ๆ ที่รู้สึกว่าน่าสนใจ นำไปใช้ได้ จะขอสอดแทรกความคิดตัวเองเข้าไปด้วยครับ เห็นด้วยหรือไม่ประการใดก็พูดคุยกันได้ครับ

  1. ถ้าพูดในแง่ของ SDLC (Software Development Life Cycle) สมัยนี้ Agile มาแรงมากครับ Agile เน้นส่งผลงานที่รวดเร็ว แต่ทีนี้การที่ส่งมอบงานอย่างรวดเร็ว อาจจะทำให้เกิดปัญหาได้ คุณไวท์ ได้กล่าวว่า (เห็นคุณไวท์บอกว่า มาจาก CEO บริษัท Nest เป็นคนกล่าว ผิดถูกอย่างไรขออภัยครับ)
การออกแบบนั้น เร่งรัด”ไม่ได้ ต้องคิดให้ลึกซึ้ง ซึ่งการใช้ Agile นั้นจะเป็นการเร่งตลาดผลิตภัณฑ์มากเกินไป

อันนี้ไม่ได้โจมตี Agile นะครับ ส่วนตัวคิดว่า Agile นั้นดี แต่บางครั้งการใช้ Agile ของบางคนก็เป็นการเร่งรัด รวดเร็วมากเกินไป ดังนั้นอาจจะต้องระวัง

2. ในฐานะที่เป็นนักพัฒนา (Dev) ส่วนตัวจะคำนึงถึงผู้ใช้ตลอดครับ ว่าผู้ใช้เค้าจะใช้เป็นรึเปล่านะ จะใช้ง่ายรึเปล่านะ ซอฟต์แวร์ที่เราเขียนจะซับซ้อนเกินไปไหมนะ ฟังเหมือนจะโอเคนะครับ แต่ความจริงแล้วไม่โอเค เพราะเราไม่มีทางรู้เลยว่าผู้ใช้จะใช้งานซอฟต์แวร์เราได้ไหม จนกว่าเราจะเข้าใจผู้ใช้จริง ๆ บางครั้งเราคิดถึงตัวเองเป็นหลักว่า ต้องทำแบบนี้ซิถึงจะดี คนใช้งานต้องปรับตัวตามที่เราคิด (ซึ่งกลายเป็นว่า เป็นภาระของผู้ใช้อีกที่จะต้องเปลี่ยนแปลง หรือเรียนรู้การใช้งานโปรแกรมที่เราพัฒนา) เค้าจึงบอกว่า

เราจะต้องลด EGO ลงและเพิ่ม Empathy ให้มากขึ้น

EGO คือ การที่เราเข้าใจตัวเอง อยากจะทำอะไรก็ทำ คิดว่าดีเลยทำแบบนี้ คนอื่นจะต้องมาเข้าใจเรา
Empathy คือ การเข้าใจ ใส่ใจ เราควรที่จะเรียนรู้(learn) รู้สึกได้(feel) และเข้าใจ(Understand) ถึงความต้องการของคนใช้จริง ๆ เพราะเป้าหมายของเราคือ พัฒนาซอฟต์แวร์ให้ผู้ใช้ใช้ ไม่ได้ให้ตัวเองใช้

แล้วเราจะเข้าใจผู้ใช้ได้อย่างไร เราต้องตั้งเป้าหมาย ความคาดหวัง มีความเข้าใจ และรู้ถึงความต้องการของผู้ใช้ ซึ่งได้มาจากการสังเกต จากบุคลิกลักษณะของผู้ใช้

ส่วนตัวให้ความรู้สึกเหมือนกับการเราไปเก็บ Requirement ครับ ซึ่งการเก็บ Requirement ก็มีหลายวิธีตามหลัก Software Engineering (ขอติดไว้ก่อนไว้ทบทวนแล้วจะเขียนอีกที) แต่ศาสตร์ด้าน UX จะเน้นในเรื่องของความเข้าใจผู้ใช้ ทางด้านจิตวิทยาและการได้มาซึ่งข้อมูลที่แท้จริง แต่พอเป็น Software Requirement Engineering (RE) เราจะเน้นในเรื่องของกระบวนการให้ได้มาซึ่งความต้องการ เพื่อให้ได้มาซึ่ง Software Requirement Specification (SRS) ที่ดี สามารถระบุแล้วนำไปใช้ต่อได้ มันก็คล้ายคลึงกันอยู่นะ แต่ก็รู้สึกว่ามันก็ต่างกันมากอยู่ เหมือนเป้าหมายเดียวกัน จุดประสงค์เดียวกัน คือ ให้ได้มาซึ่งความต้องการที่แท้จริงของผู้ใช้ ดังนั้นผมเลยคิดว่า UX และ RE เนี่ย มีความทับซ้อนกันอยู่ใกล้เคียงกันมากเลย แต่คนละมุมมอง

3. มีประโยคนึงที่วิทยากร (คุณไวท์) ได้บอกว่า มีประโยคนึงที่พี่เค้าชอบมาก คือ เราจะต้องพัฒนาผลิตภัณฑ์หรือบริการให้ลูกค้านั้น

รู้สึก Guilty ที่มาใช้บริการเราแล้วรู้สึกว่าจ่ายน้อยเกินไป

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

4. ในการทำ UX มีอีกส่วนที่คล้ายกับการทำ RE คือ การทำ UX จะช่วยในการสร้าง Template ที่ผ่านจากขั้นตอนการ Exploration/Research แล้ว ซึ่งพอเราได้ Template ก็สามารถนำไปใช้กับโครงการอื่น ๆ ได้อีก เพราะสิ่งที่ได้นั้นเกิดจากเรา Learn, Look, Ask, Try มาแล้ว ก็คือเราได้ความต้องการของผู้ใช้มาแล้ว (เหมือนได้ Tailoring ต้นแบบมาแล้ว ตามหลัก Software Process)

5. ในการพัฒนาซอฟต์แวร์ที่เป็นอยู่ในปัจจุบัน เกิดปัญหาแบบที่พี่แบงค์กล่าวไว้ การเกิดความไม่ชัดเจนของความต้องการเกิดจากไม่รู้ว่าต้องทำให้ใคร เพราะ

1. หัวหน้าไม่บอก
2. เพราะลูกน้องไม่ถาม

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

  1. เราต้องระบุให้ได้ว่าทำให้ใคร
  2. ต้องเข้าใจบริบทที่จะใช้
  3. ต้องรู้ว่าคนจ่ายเงินอยากได้อะไร

ซึ่งก็คือ การสั่งงานควรจะตอบผู้ใช้งาน (User) จากการสังเกต ไม่ใช่ดูจากสิ่งที่ได้ (Output) การที่หัวหน้าสั่งงานเป็น Output เพราะไม่ไว้ใจทีม ไม่เชื่อมั่นในศักยภาพของคนในทีม (อันนี้เข้าทาง Agile Methodology เลย) เราต้องเข้าใจ User ต้องรู้ว่า User พบปัญหาอะไรในการใช้งาน เราต้อง Validate ว่าลูกค้ามีความต้องการอะไรบ้าง โดยการสังเกตจากวิธี เห็น -> พูด -> รู้สึก -> คิด (รายละเอียดเข้าไปอ่านจากของคุณ Natt Phenjati ได้ครับ หรือรอ Video ย้อนหลังน่าจะชัดเจนในคำอธิบายมากกว่า)

สิ่งที่ได้จากคุณแบงค์ที่เป็นประโยชน์กับเรามากก็คือ เราเข้าใจว่า UX คือ เข้าใจ User ในฐานะ Dev เอง การที่ Dev คนอื่น มีส่วนเกี่ยวข้องกับโปรแกรมที่เราเขียน นั่นก็คือ Dev คนนั้นเป็น User คนนึงของเราเหมือนกัน ดังนั้น การที่เราจะเป็น Dev ที่ดี ก็ต้องเข้าใจถึง Dev คนอื่น ๆ ด้วย การใช้ศาสตร์ด้าน Software Engineering จะมีประโยชน์ตรงนี้มากครับ อย่างเช่น การเข้าใจ Design Pattern, Bad Smell, SOLID, DRY, Principles หรือ Standards ในภาษาที่เขียน, Software Architecture, การเข้าใจถึง Good Quality Attributes, Software Metrics, เขียน Test ทำ TDD , BDD ได้ เป็นต้น จะช่วยให้เราสามารถทำงานร่วมกับผู้อื่นได้ดียิ่งขึ้นครับ

6. ถ้าเราเข้าใจธรรมชาติ (Nature) และสามารถลดความซับซ้อน (Complexity) ได้ จะช่วยให้สิ่งที่เราทำนั้นตอบโจทย์กับผู้ใช้มากยิ่งขึ้นครับ (อ. เดฟ กล่าวไว้ครับ)

7. การพัฒนาซอฟต์แวร์เป็นการเพิ่มภาระให้กับผู้ใช้ (อ. เดฟกล่าวไว้ครับ) อันนี้ตอนเรียนวิชา RE หรือ SPI อ. ย้ำเสมอครับ เพราะว่าซอฟต์แวร์ที่เราจะพัฒนานั้น ควรจะศึกษาความเป็นไปได้ (Feasibility) และคำนึงถึงความเสี่ยงที่อาจจะเกิดด้วย (Risk) เพราะว่าซอฟต์แวร์ที่เราทำนั้น อาจจะเปลี่ยนแปลงการทำงานของผู้ใช้คนนั้นไปเลย อย่างเช่น บางคนเคยทำงานด้วยเอกสารที่เป็นกระดาษมาตลอดต้องมาเปลี่ยนเป็น
กรอกข้อมูลลงบนคอมพิวเตอร์แทน ถ้าหากเราพัฒนาโปรแกรมที่มีความซับซ้อนมาก ใช้งานยาก เข้าใจยาก ซอฟต์แวร์ที่เราพัฒนาก็คงไม่ดีเท่าที่มันควรจะเป็น ดังนั้น เราต้องเข้าใจผู้ใช้ให้มาก ๆ ครับ

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

9. การไปฟังครั้งนี้ ได้แนวความคิด ให้เข้าใจผู้ใช้ ต้องทำให้ผู้ใช้รู้สึกมีความสุข การจัดการทีม และแนวความคิดในการทำงานเข้ามาด้วย (อันนี้พอจะเข้าใจเทรนด์ปัจจุบันที่เป็น Agile มากขึ้น) ส่วนตัวถ้ามองเป็น Software Engineer ก็รู้สึกชอบการพูดแนว ๆ นี้เป็นพิเศษครับ ชอบหัวข้อแนว ๆ การบริหารจัดการ แนวความคิดในการทำงาน กระบวนให้ได้มาซึ่งความต้องการประมาณนี้

สุดท้าย ขอขอบคุณทีมงาน UX Talk วิทยากรทุกท่านที่จัดงานดี ๆ แบบนี้ขึ้นมาครับ

ปล. ขณะที่เขียนค่อนข้างมึนมากครับ เหมือนจะพิมพ์ตกๆ หล่น ๆ งงๆ ก็ขออภัยมา ณ ทีนี้ครับ จะปรับปรุง พัฒนาในการเขียนต่อไปครับ

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.