12 ขั้นตอนสำหรับ Basic User Experience (UX)

ประเดิม Blog แรกเลยนะเนี่ย (^_^)/ ต้องขอบคุณพี่ @apirak ที่ให้โอกาสได้ไปช่วย Basic UX Workshop ที่จัดโดย Ux Academy เมื่อวันที่ 28 - 29 กันยายน ที่ผ่านมา จัดที่ Hubba

ได้ความรู้ติดกลับมาด้วยเยอะแยะเลย อยากสรุปเอาไว้อ่านเองแล้วก็อยากแบ่งปันด้วย เลยเอามาเขียน Blog เลยละกัน

"การคิด UX" 

ในความคิดของตั้ว คือ การคิดวิเคราะห์เข้าไปในจิตใจผู้ใช้ ว่าอะไรที่จะทำให้เค้าใช้งานสิ่งของทุก ๆ อย่างที่เราตั้งใจผลิดออกมาไม่ว่าจะเป็นสิ่งของ เครื่องใช้ รวมไปถึง software, mobile application ต่าง ๆ ได้อย่างราบรื่น รู้สึกดีกับชิ้นงานของเรา และอยากใช้อีก สรุปวิธีคิดแบบง่าย ๆ คือ สิ่ง ๆ นั้น ควรจะต้องตอบโจทย์ปัญหาในชีวิตไม่อย่างใดก็อย่างนึง และยังมีการใช้งานที่ง่าย ใช้งานแล้วไม่สะดุด ในที่นี้ จะพูดถึงเรื่อง Basic UX ของการทำ software เช่น web หรือ mobile application นะ :)

12 ขั้นตอน สำหรับ Basic UX

1.) research

สอบถามทุกคนที่เกี่ยวข้องกับสิ่งที่เราจะทำ (stakeholder) ว่าเหตุผลและจุดมุ่งหมายของการทำสิ่ง ๆ นั้นขึ้นมาคืออะไร

2.) review user

สอบถามประวัติและเรื่องราวในชีวิตประจำวันของ user เพื่อหาปัญหาที่ซ่อนไว้ลึก ๆ (insight) โดยการถามคำถาม จะเริ่มจากให้แนะนำตัวเพื่อสร้างความเป็นกันเอง แล้วให้เค้าลองเล่าเรื่องที่น่าจะเกี่ยวกับหัวข้อที่เราจะทำ โดยจุดสำคัญคือ ให้เน้นการเล่าเรื่อง ไม่ใช่ให้ตอบคำถามปลายปิด และไม่ชี้นำ เพื่อให้ user เป็นคน lead เรา ไปหานิสัยส่วนตัวลึก ๆ ของเขา เพราะบางคำตอบ user อาจจะตอบ "ที่สิ่งเขาคิดว่าเขาเป็น" ไม่ใช่ "สิ่งที่เขาเป็น" จริง ๆ นอกจากนี้ เราควรสังเกตหน้าตาท่าทางของ user ขณะเล่าด้วย ว่าจุดไหนที่เขาอึ้ง เงียบ กำลังคิด นั่นก็หมายถึงว่า เค้ากำลังขุดสิ่งที่เค้ารู้สึกข้างในออกมาบรรยายให้เราฟัง คำถามที่ดีคือคำถามที่ทำให้เขาฉุกคิด และในขณะที่เขาคิดควรปล่อยให้เขาคิด ห้ามถามคำถามแทรก
ยกตัวอย่างเช่น อยากจะทำ app note ช่วยจดบันทึก ก็จะให้ลองเล่า ชีวิตตั้งแต่ตื่น ไปจนถึงที่ทำงาน ให้เขาลองเล่ารายละเอียดมาเป็นชอต ๆ โดยขั้นตอนนี้ อาจจะสัมภาษณ์ user ประมาณ 3 - 5 คน

3.) กำหนด persona

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

4.) brain storm ด้วย post it เพื่อหา problem

เราจะใช้ post it เพื่อทำการ brain storm โดยทีมจะมามุงกันที่บอร์ด แล้วให้คนนึงเริ่มพูดสิ่งที่คิดว่า persona ของเรากำลังมีปัญหาอยู่ โดยทีมจะผลัดกันแปะ post it แล้วพูดอธิบาย post it นั้นทีละคน ไม่พูดซ้อนกัน เพื่อให้ทุกคนได้เข้าใจทุกความคิดที่ถูกแปะไป หากเราเห็นความคิดของคนอื่นแล้วนึกถึงเรื่องอื่นได้ ก็สามารถเขียน post it แล้วไปแปะต่อกับ post it อันที่ทำให้เราเกิดความคิดได้ (เรียกว่า ต่อยอด post it)

กฏการ brain storm 

มีอยู่ 7 ข้อหลัก ๆ ด้วยกัน

1. defer judgement > ไม่แย้งความคิดเห็นของคนอื่น
2. encourage wild ideas > สนับสนุนความคิดที่เปิดกว้าง
3. build on the ideas of others > ต่อยอดความคิดของคนอื่น
4. stay focused on topic > พยายามอย่าออกนอกหัวข้อจนเกินไป
5. one conversation at a time > ให้คนพูดที่ละคน เพื่อให้ทุกคนได้ยินและเข้าใจที่มาของทุกความเห็น
6. be visual > ถ้าสื่อไม่ถูก ก็วาดรูปแทนได้
7. go to quantity (not quality) > เน้นปริมาณ ยังไม่เน้นคุณภาพ

5.) vote problem

ใช้ dot vote เพื่อดูแนวโน้มว่าปัญหาใดที่ควรแก้ไขในอันดับต้น ๆ คือ ให้แต่ละคนในทีม มี vote ของตัวเอง คนละ 3 ถึง 5 โหวต (แล้วแต่ขนาดของทีมและ post it) จากนั้น ก็เลือกจุด post it ปัญหาที่เราสนใจและอยากจะแก้ไข

6.) "เพราะว่า ..[problem].. เป็นไปได้ไหมที่จะ …[solution ที่วัดผลได้].."

เขียนประโยคนี้ใส่กระดาษใหญ่ ๆ ให้ทุกคนในทีมเห็น เพื่อเป็นจุดให้เรา focus ว่าเรากำลังจะแก้ปัญหาอะไรให้ user แล้วเราจะวัดผลอย่างไรว่าเราได้แก้ปัญหานั้นแล้ว โดยเวลาเขียน solution ต้องเขียนในรูปแบบที่จะวัดผลได้ ยกตัวอย่างเช่น กรณีจะเขียน app to-do list อาจจะเขียนว่า "เพราะว่าไม่ทราบว่าจะทำอะไรก่อนหลัง เป็นไปได้ไหมที่จะเห็นว่าควรทำอะไรก่อน อย่างน้อย 3 อันดับแรก" >> คือ เขียนออกมาให้เป็นรูปแบบตัวเลขที่ทำให้วัดผลได้ เช่น จำนวน, เวลา เป็นต้น

7.) brain storm หา solution

เริ่มจากการ brain storm หา solution ด้วย post it ก่อน (เหมือนข้อ 4) โดยการ brain storm หา solution นี้ จะอิงกับประโยคที่เรา define ไว้ในข้อ 6

ตัวอย่างการ generate ideas

• เพิ่มสิ่งที่ดี
• กำจัดสิ่งที่แย่
• ลองมองมุมกลับ
• ตั้งข้อสงสัยสิ่งที่รู้อยู่แล้ว
• เปลี่ยนความรู้สึก
• เลียนแบบ

เมื่อ brain storm เสร็จ จะช่วยกันเลือกว่า solution ที่เราจะทำขึ้นมา เพื่อแก้ปัญหาตามข้อ 6 นั้น คืออะไรดี เราอาจจะใช้วิธี dot vote เหมือนตอนหาปัญหาก็ได้ หรือ อาจจะใช้วิธี thumb vote คือ ให้ทีมใช้การยกนิ้วโป้งเพื่อโหวต มีทั้งหมด 3 แบบ ก็คือ

1. ยกนิ้วโป้งขึ้น (เหมือนกด like) หมายถึง เห็นชอบกับวิธีนี้
2. กดนิ้วโป้งลง หมายถึง ไม่ชอบ / ไม่เห็นด้วยกับวิธีนี้
3. ยกนิ้วโป้ง แล้วทแยงมือขนานกับพื้น หมายถึง เฉย ๆ

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

8.) วาด storyboard

เล่าถึง use case ในการใช้งาน software ของเรา ว่าคนจะใช้ในเหตุการณ์ไหน เล่าในรูปแบบของภาพเล่าเรื่อง บอกถึงลำดับการใช้งานหลัก ๆ ว่าเป็นยังไง เพื่อให้ผู้ใช้เห็นภาพรวมและเข้าใจจุดประสงค์

9.) ร่าง wireframe คร่าว ๆ ด้วยหน้าจอ 2 นิ้ว (อันนี้กรณีออกแบบ mobile app)

ใส่รายละเอียดว่าโปรแกรมของเรา จะมีหน้าจอไหนบ้าง แต่ละหน้าจะมีอะไรหลัก ๆ บ้าง โดยขั้นตอนนี้ ยังไม่ต้องลงรายละเอียดในแต่ละหน้าจอมากนัก เพราะต้องการให้มองเห็นแค่ภาพรวมเท่านั้น

10.) ร่าง wireframe ละเอียด ด้วยหน้าจอขนาดจริง

เริ่มลงรายละเอียดแต่ละหน้าจอมากขึ้น แล้วตัดกระดาษแต่ละหน้าออกมา ให้คล้ายขนาดจริง

11.) usability test

ให้ user ลอง test ด้วย wireframe นี้ (ใช้กระดาษที่ตัดมาจากข้อ 10 เรียกว่า paper prototype) เพื่อหา feedback ว่า มีจุดไหนที่เราลืมไป หรือมีจุดไหนที่เข้าใจยากและควรแก้ไขหรือไม่ เริ่มจากเขียนในกระดาษไว้ ว่าเราจะทดสอบ feature ไหนบ้าง

** โดยในขั้นตอนนี้ มีจุดสำคัญอยู่ที่ตอนให้ user ลอง test

ควรเริ่มจากการพูดขอบคุณที่มาช่วย test และบอกว่า การ test นี้ เป็นการ test โปรแกรม ไม่ใช่ test user หากมีจุดไหนผิดพลาด แสดงว่าผิดพลาดที่ผู้ทำโปรแกรม ไม่ใช่ที่ผู้ใช้ แล้วจากนั้น ก็บอกให้ user ทดสอบและคิดไปด้วยโดยต้องคิดให้ดัง คือ ให้พูดไปด้วยว่ากำลังคิดอะไรอยู่ ในขณะที่ทดสอบ เราควรสังเกตหน้า user ด้วย ว่าขมวดคิ้ว / งงตรงไหน คิดตรงไหนนาน การใช้งานส่วนไหนไม่ราบรื่นบ้างหรือไม่
ตอนที่จะให้ user ทดสอบตาม feature ที่เราเขียนไว้ตอนแรก ให้พูดเป็นสถานการณ์ ไม่ใช่บอกให้ทำ feature นั้น ๆ โดยตรง เพราะผู้ใช้อาจจะหา keyword จากคำพูดเราแทนก็ได้ เช่น โปรแกรม to-do list อยากจะให้ user ทดสอบการ add to-do ใหม่ ให้เราควรพูดว่า "สมมติว่าคุณ A นึกได้ว่าต้องแวะซื้อข้าวเย็นก่อนกลับบ้านแล้วอยากเก็บบันทึกไว้ คุณ A จะทำอย่างไรคะ"

** อย่าลืมให้คนนึงจด feedback และรายละเอียดที่ user comment ไว้ด้วยนะ

ตัวอย่างการ test อีกรูปแบบนึงที่เป็นที่นิยม ได้แก่ การใช้การเบลอหน้าจอ แล้วสอบถาม user ที่ยังไม่เคยเห็น ว่า คิดว่าตำแหน่งไหน เป็นอะไร หรืออาจจะใช้วิธีทำเป็นสีขาวดำ / gray scale เพื่อตรวจสอบเรื่องการใช้สี และตำแหน่ง ดูว่าอันไหนเด่น ตำ

12.) improvement

นำ feedback ที่ได้มา นำมาปรับปรุงแก้ไข แล้วเอาไปให้ user ลอง test ซ้ำไปเรื่อย ๆ จนกว่า user จะ ok แล้วค่อยเริ่ม dev เพราะการ test ด้วย wireframe ที่เป็นกระดาษ ต้นทุนถูกกว่าการ test ด้วยตัว prototype software ที่ต้องลงแรงไป dev ก่อน เราจึงควร test ในขึ้นตอนนี้ให้มากพอและมั่นใจในระดับหนึ่งก่อนจะไปเริ่ม dev นะจ๊ะ


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

สรุป Design Thinking Concept

1. empathise > review stakeholder, review user
2. define > ตั้งโจทย์ปัญหา 
3. ideate > คิดวิธีแก้ปัญหา 
4. prototype > สร้างผลงานตัวอย่าง 
5. test > ทดสอบกับผู้ใช้จริงแล้วทำการปรับปรุง

โปรแกรมทำ Wireframe / Test

• Axure RP 
• Indigo 
• POP (Prototyping on Paper) 
• Firework 
• Omnigraffle 
• Silverback > record for usability testing 
• Live View, Scala view > show ที่ mobile ขณะ design

ถ้าคำตอบคือ feature นี้ ไม่ได้ช่วยแก้ปัญหาอะไรให้ user เลย ก็ไม่มีเหตุผลอะไรให้มี feature นั้นอยู่ใน software ของเรา !

"Delivers Solution Not Feature"

*** People don't buy what you do; they buy why you do it. ***

http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

ทั้งหมดนี้เป็นแค่ข้อมูลความรู้ส่วนหน่ึงที่ได้จากการไปช่วย Workshop เท่านั้น ถ้าใครอยากได้ข้อมูลเชิงลึกกว่านี้ ได้ลองทำจริง ก็ติดตาม Event Workshop ที่ UX Academy ได้เลยนะจ๊ะ ^_^