สรุปเนื้อหางาน UX for Developers ตอน Implementation (Later Stage Product)

ก็เป็นอีกหนึ่งงานที่จัดขึ้นสำหรับชาว IT โดยเฉพาะ Developer ที่สนใจในการทำ UX และผมก็ได้มีโอกาสไปร่วมงานเหมือนกัน โดยจุดประสงค์ของงานคือให้ความรู้เกี่ยวกับการทำ UX สำหรับ Developer นั่นเอง แต่จริงๆ แลัวงานวันนี้ Designer เองก็สามารถเข้าไปฟังได้เพราะถือว่าเนื้อหากลางๆ ไม่พูดการ Design มากไปหรือ Technical มากไป จะเป็นออกแนวคิดมากกว่า ฟังได้ทุกคนครับ

งานนี้จัดแถวๆ BTS ออนนุช โดยสถานที่จาก HUBBA-TO จัดโดย Startup หน้าใหม่ชื่อ Indie Dish แอพสั่งอาหารเพื่อสุขภาพ โดยมีคุณ Darin Suthapong ซึ่งเป็น Co-Founder ของ Indie Dish และ UX Design Lead ของ Amazon (US) มาพูดให้ความรู้เกียวกับงานในวันนี้ พูดได้ว่างานเรามีผู้เชียวชาญด้าน UX มาโดยตรงนะครับ 

What’s UX

อธิบายง่ายๆ ให้ Developer หรือ Designer มือใหม่ เข้าใจง่ายๆ คือการออกแบบที่เอา คน เป็นตัวตั่งเพื่อให้ เพื่อให้คนที่เข้ามาใช้งานระบบมีความเข้าใจระบบ (Discoverability), เรียนรู้ได้เอง (Learnability) โดยการออกแบบแนวนี้เราจะมองกันที่หลักจิตวิทยาว่า UI ที่เราออกแบบมานั่น User พึ่งพอใจและใช้งานได้ดีแค่ไหนเป็นต้น โดยที่เราจะมีศาสตร์ที่ตรงข้ามกับ UX คือ SA (System Analysts) โดย UX จะพูดถึงคนและจิดใจ อารมณ์จะใช้หลักจิตวิทยา (Psychology) เข้ามาช่วยและ SA จะพูดถึงการออกแบบระบบ การวางโครง การเขียนโฟร์

 

Topic of speech

  • Mindset – มุมมองแนวคิด แง่มุมการคิดของการทำ UX
  • Framework – ขั่นตอนการทำงาน เครื่องมือต่างๆ ที่ช่วยในการนำเอา Mindset ไปใช้ยัง
  • Implement – จะนำเอาสองหัวข้อด้านบนไปใช้ยังไงถ้าเข้าในการทำ UX และขั่นตอนต่างๆ กับ Product ใหม่ หรือ Product เก่าของเรา

งานนี้มีอยู่ 3 หัวข้อหลักซึ่งต้องบอกว่าแต่ละหัวข้อสนุกมาๆ เต็มอิ่มกันเลยทีเดียว เรามีดูกันต่อแต่ละหัวข้อนะครับ

 

Implementation

คือช่วงการเอา Framework เอามาทำจริงๆ โดยตัวที่เราใช้ก็คือ 4Ds ที่เป็นลูกของ Midset นั่นเอง เอามาทำให้เห็นภาพว่าการที่เรามี Midset แล้วเราจะทำ UX ในงานของเราได้ยัง ซึ่งบทความนี้ก็จะมาพูดเรื่องการทำ Later Stage Product ทำยังไงเราลองมาดูกัน

– Later Stage Product

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

เริ่มต้นเลยเราก็ยังคงใช้ 4Ds คือ Discover, Design , Develop, Do the test เหมือนเดิมครับ แต่ว่าโฟกัสต่างออกไปนิดนึงเพราะว่ามันคือสิ่งที่เรามีอยู่แล้ว เช่นเราต้องการทำงาน Product นี้ให้ดีขึ้น 

 

Discover Phrase

สิ่งที่เราจะสนใจนั่นจะต่างออกไปจากตอนที่แล้วคือ New Product เพราะเราจะเน้น 2 อย่างดังนี้

  • Understand existing behaviors & expectations – คือเราจะศึกษาว่าเขาใช้ Product ของเรายังไง พฤติกรรมการใช้ต่างๆ
  • Uncover stakeholders assumptions – ยิ่งโปรดักที่อยู่มานานจะยิ่งมีอะไรให้ศึกษามาก เราต้องไปแกะออกมาให้หมด
  • Look at past data – เป็นการเอาข้อมูลเก่าๆ มาวิเคราะห์ ซึ่งเราต้องถามตัวเองว่าถ้าเรากำลังทำ Product ของที่เรามีเช่น re-Design , ออกฟีเจอร์ใหม่ (ไม่ว่าเล็กหรือใหญ่) เราต้องถามตัวเองว่าเราจะไปหาข้อมูลที่เกี่ยวกับสิ่งที่เราสนใจได้ที่ไหน ตัวอย่างเช่น Google Analytics, สอบถาม เป็นต้น ซึ่งเวลาเราจะทำฟีเจอร์ใหม่ๆ เราต้องคิดว่าเราจะไปาข้อมูลจากไหนได้บ้าง ใครจะช่วยเราได้บ้าง แผนกไหนจะให้ข้อมูลเราได้เยอะเป็นนี้เป็นตัน
  • Preliminary user test – ในส่วนคือการให้ User ใช้งานนั่นเอง โดยคุณ Darin ยกตัวอย่างของ Eric RIes (คนคิดค้นการทำ Lean Startup นั่นเอง) ซึ่งเขาเป็นคิดวิธีว่าเราต้องเทสเร็วๆ และเทสบ่อยๆ ซึ่งเขาเจอกับปัญหาคือเขาใข้เวลาในการเขียนโปรแกรมเพื่อทำโปรดักนานมาก พอเขาปล่อยโปรแกรมออกมาปรากฏว่าไม่มีคนใช้ ซึ่งบัคก็ไม่มี หลังจากนั่นเขาจึงลองมาทำ Preliminary user test โดยเขาก็เลยเอาคนกลุ่มเป้าหมายของเขามาลองใช้งานระบบของเขา ซึ่งเขาก็ค้นพบระบบเขามันยังไม่ดีเท่าไร  เพราะระบบเขาที่ทำขึ้นมาเองมันมีความเสี่ยงไป (ระบบแชท + the sim โลกเสมือน) ดังนั่นเขาเลยเอาระบบตัวเองไปผูกกับระบบแชทคนอื่นแทน ซึ่งหลังจากที่เขาหาตรงนี้ได้เขาก็กลับไปพัฒนาระบบตัวเองใหม่
  • Users Journal – โดยคุณ Darin ยกตัวอย่าง“Delivery not receipt” มาอีกว่าเขาก็ให้เงินคนลองไปซื้อของแล้วก็ให้เขาเขียนมาว่าเขามีขั่นตอนและความเข้าใจยังไงเกี่ยวการซื้อของและเอาข้อมูลตรงนี้มาปรับปรุงระบบนั่นเอง
  • Mental Modal Map – คิดค้นโดย Indi Young เป็นวิธีที่เหมาะกับการทำกับ Product ที่มีอยู่แล้วมาก ซึ่งวิธีนี้คล้ายๆกับการทำ Affinity Map ในบทความที่แล้ว ซึ่งตรงนี้ถ้าเรามี Product อยู่แล้วเราสามารถเอาฟีเจอร์ที่เรามีอยู่มีอะไรบ้างมาลิส โดยรูปด้านบนคือ Mantal Map ในการไปดูหนังซึ่งจะศึกษาว่าคนตอนไปดูหนังมีพฤติกรรมยังไง เช่น อยากดูจากผู้สร้างคนนี้ ดูจากนักแสดงคนนี้เท่านั่น จากนั่นก็เอามา map กับระบบของเราว่ามีฟีเจอร์อะไรบ้าง (ในรูปสีเหลืองคือพฤติกรรม ด้านล่างคือฟีเจอร์ที่เรามี)

 

Design Phrase

ในช่วงการออกแบบเราจะมีหลักการอยู่ 2 อย่างก็คือ

Have a solid strategy 

  • Identify challenge
  • Form vision & solutions
  • Create guiding principles
  • Know what to focus

ปกติไม่ค่อยมีใครพูดถึงเท่าไร ดังนั่นจึงหยิบมาพูดให้ฟังโดยใจความคราวๆ โดยยกตัวอย่างการ Delivery not receipt พอเราเจอแล้วว่าปัญหาว่ามันประมาณไหน ก่อนที่เราจะวาดกล่องแรกหรือเริ่มออกแบบ เราต้องดู Strategy ว่าเราจะแก้ปัญหานี้ยังไง ซึ่งจากปัญหาที่คนโทรมาในปัญหาที่เขาไม่ได้รับสินค้า กับที่เราออกแบบว่าไว้เราจะแก้ปัญหานี้ยังไงให้มันมาเชื่อมโยงกันได้ยังไง (solutions) ซึ่งเราก็ต้องระบุปัญหาให้ได้ก่อนและในตัวอย่างนี้ปัญหาหาก็คือการสื่อสาร (Identify) เพราะลูกค้าไม่ได้เข้าใจว่ากระบวนการส่งของเป็นยังไง

หัวข้อถัดมาคือ  Create guiding principles ซึ่งคุณ Darin ก็ได้ยก usecase จาก Facebook มาอันนึงก็คือระบบ Reaction ก็คือเพิ่มปุ่นกดแสดงอารมณ์เพิ่มมานอกจากปุ่มไลค์ และสงสัยไหมทำไมเขาถึงใช้เวลาทำนาน ซึ่งเขาก็ได้ซึ่งศึกษาปัญหาก่อน (Identify) ซึ่งเขาพบว่าคนเข้ามาใน Facebook มันก็ Not everythink in life is Likeable มันก็อาจจะมาสยองบ้าง ตกใจบ้าง ซึ่งเขาก็คิด (Form vision) ก่อนว่าคนที่เขามาใช่ปุ่มไลค์มันไม่ได้มีแต่ฝรั่งเรามีคนทั่วโลกเพราะงั่นปุ่มจะต้องทำให้คนเข้าใจได้ง่ายและทำให้ยังไงให้ฟีเจอร์แค่นึงอันเข้าใจได้ทั่วโลกเพราะงั่นเขาก็ต้องมีหลักยึด (guiding principles) ว่ามันต้องใช้งานง่าย ไม่ใช้ว่ากดลงไปมี drop-down มี modal โผล่มาแบบนี้ก็ใช้ยากไป หลายขั่นตอนไป

 

Get detailed into the design (UI Design 101)

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

  • Context – ต้องเขาใจก่อนว่าหน้า UI เนี่ย คนที่เข้ามาใช้เขาเข้ามาทำไร ก็คือ Think Holistic 
  • Purpose – เมื่อเข้าใจ Context เราก้ต้องเข้าใจว่าหน้านี้เราทำเผื่ออะไร (Purpose)
  • Content – เมื่อรู้ Purpose แล้วก็มาดูว่าหน้านี้ต้องมีเนื้อหาอะไรบ้าง เพื่อตอบสนองกับ Purpose เช่นเราจะทำแอพเกี่ยวกับค้นหาที่ท่องเที่ยวเราต้องมี Content อะไรบ้าง เช่น แผนที่ ชื่อสถานที่ เป็นต้น
  • Layout – พอเราวาง Content ได้แล้วว่าหน้านั่นเราจะจัดมันออกมายังไงเช่น Grid View, List View หรือ Modal ดีไหม เป็นต้น
  • Surface – พอเราจัดวาง Layout เสร็จก็ค่อยไปจัดความสวยงานนั่นเอง

 

Develop Phrase

wireframe

 

ถ้าเป็น Develop ของ Later stage ตรงนี้ก็จะเน้นที่ Higher fidelity คือทำให้เหมือนจริงล่ะ อาจจะเขียนโค้ดขึ้นมาเลยให้กดได้จริง หรืออาจจะพวก Mockup prototype เช่น keynote , origami ของ Facebook หรือ FramerJs เป็นต้น

 

Do the Test Phrase

สิ่งที่เราต้องการที่เป็นหัวใจของการทำ Do the test ของ Later stage ซึ่งเรากำลังจะเตรียมตัวปล่อยงานขึ้นสู่ Production แล้ว ก็คือ

Get more detailed data – ขั่นนี่คือการทดสอบให้รู้ผลว่ามันใช้งานได้จริงนะ

Actual validation from users’ real behavior – คือต้องทำให้เหมือนจริง ปกติการทดสอบในขั่นจะต้องทำในแลปสะส่วนใหญ่  ก็คือห้องธรรมดาที่มีอุปกรณ์ทั่วไปเช่น คอมพิวเตอร์  ปกติเราจะ setup แลปกันแบบนี้คือมีห้องสองห้อง ห้องนึงห้องเล็กๆ และมีคอมพิวเตอร์หรืออุปกรณ์ที่ใช้ทดสอบ และก็มีอีกห้องที่ถ่ายทอดสดออกไปเพื่อให้ Developer, Designer, PO หรือใครก็ตามเฝ้าติดตามเพื่อดูพฤติกรรมของ User testing

How to setup your test? 

  • Script – ก็คือเป็นการเขียนเพื่อบอกว่าจะให้ User เขาทำอะไร เป้าหมายหลักคือทำอะไร เป็นต้นก็จะคล้ายๆ กับช่วงของ New Procut ในบทความตอนที่แล้ว แต่มันจะมีความละเอียดมากขึ้นและชัดเจนกว่า
  • Context –  ก็คือคล้ายๆ กับบทความที่แล้วคือสร้างความเข้าใจให้ User ก่อนว่าเขาต้องทำอะไร ระบบที่จะทำคืออะไร
  • Make sure they don’t feel judged  ทำให้แน่ใจว่า User เขาไม่ได้ถูกทดสอบอยู่ เหมือนกันที่พูดในบทความที่แล้ว
  • Encourage the users to think out loud – ทำให้เขาสามารถพูดได้โดยที่เขาไม่รู้สึกผิดเมื่อเขาพูดออกไป หรือกลัวที่จะพูดเกี่ยวกับสิ่งที่เขาทดสอบอยู่  สรุปง่ายๆ คือเขาสามารถด่าได้ พูดได้โดยที่เขาจะไม่รู้สึกว่าทำให้เรารู้สึกแย่ เราอาจจะพูดว่าเราไม่ได้ทำแอพนี้ เราถูกจ้างมาเพื่อทดสอบ เพื่อทำให้เขาสบายใจว่า เราไม่ใช่คนทำ เพราะงั่นพูดไปไม่มีกระทบเราแน่นอน

 

ab-testing

สุดท้ายสิ่งที่ควรจะทำก็คือ A/B Testing คือการออกแบบระบบหรือฟีเจอร์มาสองอย่างและให้ User ทดสอบว่าแบบไหนเขาเข้าใจและได้ผลตอบรับดีมากที่สุด หลักๆ ก็จะมี Control และ Variation หรือจะเรียกว่า Treatment   ซึ่ง Variation ก็ไม่จำเป็นต้นเป็นอันเดียวก็ได้ อย่างเช่นเราอยากรู้ว่า Design ไหนที่คนเข้าใช้งานมากที่สุด มันอาจจะมี Control ที่เป็นแบบปกติที่เราใช้อยู่ปกติ อาจจะมี Treatment1, Treatment2, Treatment3 แต่ละอัน ก็จะเปลี่ยนลิ้ง เพิ่มปุ่มหรือลูกล่นอะไรก็ตามที่เราต้องการ

ซึ่ง A/B  มันไม่ใช่แค่การทดสอบเรื่อง Design แต่มันควรจะทดสอบในเรื่องของสมุติฐานที่ต่างกัน และคุณ Darin ก็ได้ยกอย่างการทดสอบ เช่น อันไหนจะทำให้ User คิดว่าขอจะมาส่งแน่นอนและมีปัญหาน้อยมากที่สุด ก็เลยตั่งสมุติฐานสองอย่างคือ 1. คนมันน่าจะอยากเห็น Count Down เห็นวันที่มันน้อยลง 2. ให้เห็น Progress Bar ว่าของใกล้มาถึงแล้วเป็นต้น และผลที่ได้คือแบบ Count Down ทำให้คนรู้สึกว่านานขึ้น รู้ว่าส่งช้าจัง ซึ่งเวลาทำ A/B มันไม่ควรจะเป็นแค่อันนี้เป็นสีเหลือง อันนี้สีขาว ซึ่งเราควรจะทำให้มันแตกต่างเพื่อจะได้เรียนรู้ User ได้มากขึ้น

ต้องใช้เวลาทดสอบนานเท่าไร ถึงจะถูกต้อง? คำตอบคือ 2 อาทิตย์ขึ้นไป และต้องมี specifically significant

 

ก็จบไปแล้วนะครับกับการทำ Later Stage Product ขอขอบคุณ คุณ Darin Suthapong ที่มาให้ความรู้กับเรา และหวังว่าจะมีประะโยชน์ต่อคนที่เข้ามาอ่านะครับ

14088781_10154352011208605_1929331825_n

Facebook Comments