UX Thailand Conf 2019 เท่าที่จำได้
ไปงานตั้งแต่ปลายเดือนกุมภา เพิ่งมีเวลามาเขียนบลอควันนี้ 555+
จุดประสงค์หลักๆคือสรุปโน้ตตามความเข้าใจตัวเอง แต่ถ้ามีประโยชน์ต่อคนอื่นได้ก็คงจะดีนะ :) ช่วงระยะเวลามันก็เว้นไปนานๆหน่อย ถ้าเนื้อหาตกหล่นไปบ้างก็ขออภัย
1st session: Escaping The Build Trap by Melissa Perri
เปิดตัวด้วยเรื่องของ product management ในยุคที่ agile กำลังเฟื่องฟู เราเร่งความเร็วในการทำงาน เพิ่มการติดต่อสื่อสาร เพื่อ deliver ทุกสิ่งอย่างตามที่ตกลงกันไว้ แต่กับดักของมันคือการที่เราโฟกัสแต่ความเร็ว เราสร้างทุกอย่างคิดว่าต้องมี เราลิสต์ทุกอย่างที่คิดว่าต้องทำ เราเพิ่ม story เข้า backlog ตลอดเวลา แต่ไม่เคยกลับมาพิจารณาเลยว่ามันตอบโจทย์ปัญหาเพียงพอที่เราจะต้องทำมันจริงๆรึเปล่า
สิ่งที่เราเรียนรู้จาก session นี้คือการแจกแจงปัญหาให้ชัดเจนก่อนที่เริ่มค้นหาทางแก้ไข ซึ่งการจะเข้าใจปัญหาได้ ต้องเริ่มตั้งแต่การเข้าใจเป้าหมายหลักขององค์กร ต่อด้วยการทำความเข้าใจสถานภาพปัจจุบัน ศึกษาให้เข้าใจ แล้วจึงสร้าง goal ขึ้นมา เพื่อหาแนวทางการแก้ไขต่างๆอีกทีหนึ่ง อย่าลืมว่าสิ่งที่สำคัญที่สุดคือ customer การโฟกัสที่ output ว่าเราต้องทำอะไรมันง่าย แต่การโฟกัสว่า customer จะได้รับอะไร คือ key สำคัญที่จะทำให้ product ของเรามี value
ซึ่งกระบวนการเหล่านี้จะไม่สำเร็จ ถ้าไม่ได้รับความร่วมมือจากทั้งองค์กร การศึกษา-พัฒนา-แก้ไขให้ตรงจุดจะทำได้ยากถ้าเบื้องบนยังคงสนใจอยู่กับการวัดผลแบบเดิมๆ แต่ถ้าเราสามารถทำทีมของเราให้เป็นตัวอย่างที่ดีได้ เดี๋ยวคนอื่นๆก็มองเห็นแล้วอยากทำตามเอง
2nd session: Back to reality by Yvonne Tse
Session นี้สำหรับเรามันเหมือน showcase ในการทำ user research โดยใช้ VR เป็นเครื่องมือ ซึ่งมันค่อนข้าง make sense เพราะว่า use case ที่เค้าทดลองคือ Immigration area ในสนามบินที่การทดสอบในสถานที่จริงนั้นค่อนข้างทำได้ยาก
ซึ่งประโยชน์มันก็มีเยอะนะ ทั้งการที่ผู้ทดสอบเองสามารถหยิบย้ายสิ่งของใน VR ได้ตามใจชอบ, การ track ทิศทางการเดินต่างๆ, cost ในการปรับแต่งหรือเตรียม test case ใน VR ก็ถูกกว่าในโลกความเป็นจริง แต่เรายังไม่เห็นว่าวิธีนี้สามารถทำไป apply ได้มากน้อยแค่ไหน อีกทั้งเรื่อง constraint ผู้คนหลั่งไหลในสนามบินจริงๆก็ไม่ได้จำลองมาในการ present ครั้งนี้
อีกหนึ่งจุดที่น่าสนใจ และเป็นข้อจำกัดของ VR ก็คือผู้คนมักมองว่ามันคือวิดิโอเกมขนาดใหญ่ มีผู้ทดสอบที่ถามกลับว่า “แล้วชนะรึเปล่า?” เมื่อจบการทดลองด้วย 5555+ เลยคิดว่าถ้าจะนำวิธีนี้ไปต่อยอดก็ควรจะต้องคำนึงถึงจุดนี้เหมือนกัน
จากนั้นก็พักกลางวัน กลับมาเจอ Lightning talk สั้นๆกระตุ้นสมองให้เตรียมรับข้อมูล
Lightning talk #1 Tracking UX Debt by Elena Sanchez
Session นี้จะพูดถึง defect เล็กๆน้อยๆใน product ของเราที่มันจะเพิ่มพลังขึ้นเรื่อยๆไปตามกาลเวลา จุดเล็กๆเหล่านี้อาจะดูไม่มีพิษภัย แต่การเจอกับมันซ้ำๆไปมาก็ส่งผลให้เกิดประสบการณ์การใช้งานที่ไม่น่าพึงใจได้เหมือนกัน เปรียบเทียบเหมือนกับลูกอมในขวดโหล ลูกเดียวอาจจะรู้สึกว่าจิ๊บจ๊อย แต่ถ้าหลายๆลูกสะสมเข้ามาเรื่อย มันก็หนักมากพอที่จะทำให้ user เลิกใช้งานไปเลยทีเดียว
การแก้ไขภายหลังก็ทำได้ยากและมีราคาแพงขึ้นมากๆ โดยเฉพาะอย่างยิ่งเมื่อ user เคยชินกับความ “ไม่น่าภิรมย์” เหล่านั้นไปแล้ว ทางแก้คือรีบหาให้เจอ รีบแก้ให้ไว มีการยกตัวอย่าง “1% days” คือวันที่ทุกคนหยุดทำงาน แล้วมานั่งวิเคราะห์หาข้อบกพร่องของ peoduct ร่วมกัน เป็น regular cleanup
Lightning talk #2 Breaking Conventions for Better UX by Chusek Phientharntham
Session เกี่ยวกับการออกแบบ “แอปในแอป” กล่าวถึงแอปวงในที่เป็นแอปรีวิวร้านอาหารเป็นหลัก มีชื่อเสียงโด่งดังและจำนวนที่ user ที่เยอะพอตัว เมื่อทางบริษัทเริ่มต้องการความหลากหลายและขยายแนวทางไปยัง cooking recipe การสร้างแอปใหม่อาจจะเสียค่าใช้จ่ายในการสร้างจำนวน user ยากกว่า ทางแก้ในเชิง business จึงเป็นการซ้อนแอปมันเข้าไปในนั้นเลย
ซึ่งในเชิง Design มันยาก 55555555555+ ทางแก้คือการทำลายกฏดีไซน์เดิม ซ้อนทับ navigation menu ของแอปรีวิวทั้งหมดด้วยแอปทำอาหาร เปลี่ยนธีมเปลี่ยนสี (แต่คงสไตล์เดิม) เพื่อทำให้ user รู้ว่านี้คืออีกแอปที่อยู่ภายใน เพราะเมื่อ user เข้ามาดูแอปทำอาหารแล้ว เมนูสำหรับรีวิวร้านต่างๆก็ไม่จำเป็นต้องใช้อีกต่อไป ปิดท้ายสวยๆว่าคุณสามารถลืมกฏการดีไซน์ต่างๆได้ แต่คุณต้องไม่ลืมนึกถึง user
Lightning talk #3 What happen when UX knows ? by Boonjira Angsumalee
Session น่ารักๆสั้นๆ ว่าด้วยชาว UX ที่ก่อเกิดมาจากหลากหลายสาย บางคนเชี่ยวชาญด้านการออกแบบความสวยงาม บางคนเข้าในกำลังความสามารถของ developer บางคนเก่งด้านมุมมองทางธุรกิจ ฯลฯ ซึ่งสายงานนี้มันเป็นสายที่กว้างและ abstract มากจริงๆนั่นแหละ การฟังเรื่องนี้จึงเป็นการตอกย้ำอีกครั้งว่าเราไม่จำเป็นต้องยึดติดกับทางไหนทางหนึ่ง อยากรู้อะไรก็เรียนรู้มันไป สุดท้ายแล้วเราก็จะเติบโตและนำศาสตร์หลากหลายสิ่งนั้นมาใช้ในการทำงานได้เอง
กลับเข้าสู่ session ปกติ บ่ายแก่ๆสติเริ่มหลุดลอย 55555+
3rd session: Democracy Is A Design Problem by Dana Chisnell
session นี้ว่าด้วยการออกแบบ flow การเลือกตั้ง โดยยกเคสคนที่เพิ่งพ้นโทษออกจากคุกและมีสิทธิเลือกตั้งเป็นครั้งแรก ซึ่งเค้าจะกาง step เปรียบเทียบกับคนทั่วไปที่มีสิทธิ์โหวตเป็นประจำ ซึ่งระบบที่ไม่ราบรื่น เช่น เว็บของแต่ละรัฐที่แตกต่างกันโดยสิ้นเชิง, ใบออกเสียงที่ยุ่งยากซับซ้อนเกินเข้าใจ ฯลฯ ล้วนส่งผลกระทบกับการติดสนใจของผู้มีสิทธิเลือกตั้ง ทุกขั้นตอนที่คนๆนึงต้องเผชิญคือบททดสอบให้ตัดสินใจว่าจะเดินหน้าต่อหรือ drop off ไป ซึ่งความยุ่งยากเหล่านี้มันสะสมได้เรื่อยๆ ซึ่งจริงๆแล้วมันไม่มีใครไม่สนใจการเลือกตั้งหรอก แต่ระบบต่างหากที่ทำให้พวกเขาเหนื่อยล้าและท้อใจ ถือเป็นอีกหนึ่ง case study ที่น่าสนใจดีเหมือนกัน
4th session: Everyone Is A Designer by Liam Hutchinson
Session ที่ว่าด้วยความร่วมมือของคนทุกฝ่ายในการ design product/service ใดๆ ยกตัวอย่างเช่น โรงแรมที่ดูแลลูกค้าเป็นอย่างดี เมื่อแม่บ้านพบว่าแขกออกจากที่พักไปโดยทิ้งครัวซองต์เอาไว้ให้เย็นชืด จึงนำไปฝากส่วนครัวให้เก็บรักษาไว้ เมื่อแขกกลับมาติดต่อทาง reception จึงจะนำไปอุ่นแล้วนำกลับมาเสิร์ฟอีกที ซึ่งกระบวนการทั้งหมดนี้เกิดขึ้นสำเร็จด้วยการประสานงานร่วมกันของทุกๆคน
ในการทำงานจริงก็เช่นกัน ถ้าทุกคนในทีมได้แชร์ความคิดเห็นและความเข้าใจร่วมกัน พวกเราก็จะสามารถออกแบบผลลัพธ์ได้ดียิ่งๆขึ้นไป เพราะ design คือผลลัพธ์จากการตัดสินใจหลายๆครั้งร่วมกัน
5th session: Continuous Design How Not to Exchange Waterfalls for Whirlpools by John Cutler
อีก 1 session โจมตี Agile 55555+ เราล้มเลิกการทำงานแบบ Waterfall ที่ Plan->Design->Implement->Test ทีละม้วน มาเป็นการทำงานแบบ Agile ที่วนลูปกลับมาเป็นรอบๆ iteration ไป แต่น่าแปลกที่การทำงานของเรามันไม่ได้ก้าวไปข้างหน้า กลับซ้ำๆย่ำอยู่กับที่เป็นน้ำวนในอ่างเสียอย่างนั้น
เราควรปรับมุมมองในการทำงานเสียใหม่ การพัฒนา product ไม่ใช่การส่งงานตามเดทไลน์ มันคือการแก้ไขปัญหาหนึ่งๆ feature หรือ output ใดๆที่ออกมามันเป็นสิ่งที่ไม่จีรังยั่งยืน value ที่ออกมาต่างหากคือสิ่งที่เราควรสนใจ ดังนั้น การแชร์ไอเดีย, ผลการทดสอบ, หรือดีไซน์ใดๆจึงเป็นสิ่งที่ Designer ควรทำให้กับทีม เพื่อให้ทุกคนเห็นภาพตรงกันและพร้อมปรับเปลี่ยนแนวทางไปตามไอเดียที่เกิดขึ้นมา
เหมือนกับเวลาที่เชฟคอยชิมตอนทำอาหารนั่นแหละ เหล่า developer เองก็ต้องคอยตรวจสอบและพัฒนาไอเดียไปในแต่ละ sprint ที่ทำด้วยเช่นกัน
Last session: The Evolution of a New UX Design Resolution by Jared Spool
Session เปิดโลกกก~ เปิดเรื่องด้วยปัญหาการส่ง false alarm แจ้งเตือน missile ผิด แล้วเหล่าชาวทวิตก็ต่างหาข้อมูล ไล่วิเคราะห์หาสาเหตุกันว่าทำไมปัญหานี้จึงเกิดขึ้น ซึ่งการไล่ตีหาสาเหตุต่างๆเหล่านี้คือกระบวนการวิเคราะห์ที่เรียกว่า Fishbone analysis เป็นกระบวนการที่แนะนำมากกว่า 5 Why เนื่องจากเราไม่ได้ย่ำปัญหาอยู่กับที่ แต่มองปัญหาในหลายๆมุมมอง
เมื่อแจง fishbone ออกมาแล้วก็จะเห็นได้ว่าปัญหานั้นมีได้ทุกภาคส่วนเลยทีเดียว ตั้งแต่หน้าตา UI ที่ไม่ชัดเจนชวนให้กดผิด, ระบบที่ไม่ได้แบ่งแยก test & production, การโทรศัพท์แจ้งทดสอบที่พนักงานได้รับสารไม่ครบ, หรือใหญ่ถึงขนาดการประสานงานหลายหน่วยงานที่ไม่มีคนรับผิดชอบโดยตรง แต่ละภาคส่วนนี่แหละ ที่ใช้หน่วยเรียกว่า “resolution” เหมือนเวลาเราซูมภาพจากพิกเซลเล็กๆขยายไปภาพใหญ่ๆ
Resolution ในเชิง UX ก็มีอยู่หลายสเกล ตั้งแต่ Screen, Application, Organization ไปจนถึง Ecosystem โดยที่แต่ละ resolution ก็มีเครื่องมือในการแก้ไขปัญหาที่ต่างกันออกไป เมื่อเราเริ่มแก้ไขปัญหาเล็กๆได้ ดราก็จะมองเห็นปัญหาที่สเกลใหญ่กว่า เหมือนอย่างปัจจุบัน เราไม่ได้สนใจแค่ความสวยงามระดับ Screen แต่เราเริ่มมอง flow ภาพรวมในระดับ Application แล้วก็เริ่มขยับไปใช้ Design thinking เพื่อยกระดับองค์กร ตอนนี้ เราเริ่มมองเห็นภาพแล้วว่า Ecosystem ยังคงเป็นปริศนา พวกเราก็ได้แต่เรียนรู้และพัฒนากันต่อไป เพื่อที่ซักวัน resolution นั้นจะได้รับการเติมเต็ม …ดังเช่นอดีตที่ผ่านๆมา ;)
จบแล้ว ยาวกว่าที่คิดไว้เยอะเลย 5555+ ปิดท้ายด้วย Quote of the day เล็กน้อย
ไม่แน่ใจว่าเก็บประเด็นครบหมดรึเปล่า ถ้ามีคำแนะนำหรือข้อแก้ไขอะไรก็คอมมเนต์บอกได้นะคะ
แล้วเจอกันบลอคหน้า :)
