เมื่อวันที่ 27 มิถุนายน 2561 ทาง TMB ได้ขานรับยุคดิจิทัล ด้วยการจัดงาน TMB Digital Talks โดยคราวนี้มากับหัวข้อ ‘UX | UI ที่เปลี่ยนให้ชีวิตผู้คนดีขึ้น’ เพื่อให้พนักงานได้เรียนรู้ศาสตร์ด้านการออกแบบ User Interface และ User experience มากขึ้น

หนึ่งในวิทยากรที่มาให้ความรู้ คือ อภิรักษ์ ปนาทกูล ผู้ก่อตั้ง UX Academy ที่มาปูพื้นฐานความเข้าใจว่า การออกแบบที่ดี ควรเริ่มตั้งคำถามจากอะไรบ้าง

อภิรักษ์ฉายให้ดูภาพอาหาร แล้วเปรียบให้เราเข้าใจง่ายๆ ว่า UX ก็เหมือนกับอาหาร เราจะเห็นว่าอาหารแพงๆ ระดับมิชลินสตาร์บางจานมีปริมาณน้อย แต่กลับขายราคาสูงได้หน้าตาเฉย เพราะว่าร้านอาหารไม่ได้ขายแต่ตัวอาหาร แต่ขายประสบการณ์ จากการได้มีโอกาสกินอาหารนั้น

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

แล้วเราจะเริ่มออกแบบ UX ได้จากอะไร อภิรักษ์กล่าวว่าก่อนอื่นเลยต้องเข้าใจสามสิ่ง ได้แก่ ผู้ใช้ (User) คุณค่าที่พวกเขามี (Value) และเข้าใจผู้ให้ทุนในการทำแอปฯ (Stakeholder)

 

เข้าใจ User

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

แต่อภิรักษ์เบรกเราไว้ก่อนว่า สิ่งสำคัญมากๆ คือ “อย่าเชื่อ User” ซึ่งหมายความว่า อย่ารีบเชื่อว่าเขาอยากได้อะไร แต่ต้องดูว่าผู้ใช้นั้นเป็นใคร (จะทำให้เข้าใจว่า ทำไมเขาถึงอยากได้ปุ่มใหญ่ขึ้น)

ตัวอย่างเช่น หากมีการออกแบบซอฟต์แวร์กรอกข้อมูลในโรงแรม ถ้ารีบแก้ตามคอมเมนต์ของผู้ใช้ เช่น ทำให้ปุ่มใหญ่ขึ้น ลดความซับซ้อนในแต่ละหน้าลง แบ่งออกเป็นหลายๆ หน้า

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

อภิรักษ์ย้ำว่า การจะทำ UI ให้ดี ไม่ใช่การเริ่มที่ UI เลย แต่ต้องไปเริ่มการสำรวจความต้องการของผู้ใช้ก่อน

แต่ความต้องการ หรือ need นี้ บางทีตัว user เองก็ไม่รู้ เพราะฉะนั้น ก็ไม่ใช่ว่าหากถามไปแล้ว จะได้คำตอบที่แท้จริงเลย แต่ต้อง “ลองไปใส่รองเท้าของผู้ใช้” หรือเอาใจตัวเองไปใส่ใจของผู้ใช้

ขั้นตอนคือการเริ่มจากสัมภาษณ์ หรือ User Interview ซึ่งมีกฎอยู่ว่า อย่าถามคำถามปลายปิด อย่างคำถามที่ต้องตอบว่า ใช่ หรือ ไม่ จากนั้นก็สำรวจ User Journey คือดูว่า เกิดอะไรขึ้นบางในขั้นตอนการทำงานทั้งหมดของผู้ใช้ ไม่ใช่แค่ตอนที่อยู่กับแอปฯ ของเรา แล้วเราจะได้เห็นภาพรวมมากขึ้น ส่วนสุดท้ายคือ Team Understanding เราต้องแชร์ข้อมูลทั้งหมด เพื่อให้ทั้งทีมเข้าใจตรงกัน

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

ตัวอย่างสองโปรแกรมที่เหมือนจะเหมือนกัน ความต้องการของผู้ใช้ต่างกัน ได้แก่ Lightroom โปรแกรมออกแบบมาให้ทำงานเร็ว แต่กลับใช้งานยาก บางคนต้องไปเรียนก่อนเพื่อมาใช้ แต่ทั้งนี้ก็ตอบโจทย์ผู้ใช้ในฐานะช่างภาพมืออาชีพ ตรงข้ามกับโปรแกรม Photo ใน iOS ซึ่งเหมาะกับการใช้งานทั่วไป สะดวก รวดเร็ว กับความต้องการพื้นฐาน

มีผู้ถามคำถามว่า เราจะแน่ใจได้อย่างไรว่าเราเข้าใจผู้ใช้ อภิรักษ์ตอบว่า “จริงๆ ไม่มี แต่เราต้องใช้วิธีส่งออกให้ลองไปใช้งานก่อน และเก็บข้อมูลสถิติไว้เพื่อศึกษาแต่ละฟีเจอร์อีกที นอกจากนี้ ผู้ใช้เองก็เปลี่ยนไปตลอด เราจึงต้องค่อยสอดสอง (monitor) กรณีที่แย่ที่สุด คือหา user มาศึกษาไม่ได้ เพราะไม่มีใครเข้ามาใช้งาน”

เข้าใจ Value

ข้อต่อมา คือการเข้าใจ ‘คุณค่า’

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

“เราชอบคิดว่าฟีเจอร์เยอะๆ เท่ากับ Value เยอะ แต่จริงๆ แล้วความเยอะนี้เป็นอุปสรรคของผู้ใช้งาน”

อภิรักษ์ยกตัวอย่างแอปฯ ธนาคารที่มีฟีเจอร์เปลี่ยนพื้นหลังได้ เขาบอกว่าเป็นฟีเจอร์ที่ทำยาก และอาจทำให้ตัวอักษรถูกกลืนไปจากสีที่ใกล้เคียงกัน อีกทั้งนี่ก็ไม่ใช่ฟีเจอร์ที่คนคาดหวังจากการใช้แอปฯ ธนาคาร (ไม่ใช่คุณค่าที่เขาให้) หรือแอปฯ ช็อปปิ้งที่มีตัวแปลงหน่วย ทั้งๆ ที่คนทั่วไปไม่ใช้กัน เพราะถ้าจะแปลงหน่วย พวกเขาก็ใช้แอปฯ อื่น หรือฟีเจอร์รายงานสภาพอากาศในแอปฯ สายการบิน ที่ไม่ได้มีประโยชน์อะไร เป็นต้น

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

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

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

 

เข้าใจ Stakeholder

ส่วนสุดท้าย คือการทำความเข้าใจความต้องการที่แท้จริงของคนที่เป็นผู้ออกเงินลงทุนในการทำแอปฯ นั้น

อภิรักษ์บอกว่า บางคนต้องการทำเพื่อกำไร บางคนก็เพื่อแพสชัน หรือบางคนต้องการเพียงเพื่อหน้าตา ซึ่งสามอย่างนี้มีผลต่อการกำหนดงบและความพยายามที่จะใส่ไปในแอปฯ นั้นๆ ไม่เท่ากัน

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

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

UX/UI ในไทย

สำหรับแวดวง UX/UI ในไทย อภิรักษ์บอกว่า ตอนนี้ก็ยังมีบุคลากรจำนวนน้อยอยู่ แต่ก็มากขึ้นเรื่อยๆ แบบทวีคูณ

“แม้ผู้เชี่ยวชาญจะน้อย แต่ปัจจุบัน คนที่เห็นว่า UX จำเป็น มีให้เห็นเยอะมากขึ้น เราเริ่มเห็นในธนาคาร สถาบันการเงิน บริษัทประกัน ฯลฯ มาก่อนเลย เพราะเขาเห็นตัวเลขชัดว่า องค์กรตัวเองใหญ่มากแต่กลับโดนองค์กรเล็กๆ มาแย่งส่วนแบ่งตลาด แล้วกลายเป็นว่าที่คนเลือกรายเล็กๆ เป็นเพราะเรื่อง Experience

“พวกนี้ขยับตัวเร็วมาก และพอกลุ่มนี้ขยับ เขาก็พากลุ่มอื่นขยับตามไปด้วย อธิบายให้คนอื่นได้เข้าใจด้วย เหมือนอย่างการจัดงาน TMB ในวันนี้”

อภิรักษ์กล่าวปิดท้ายว่า ไม่จำเป็นต้องเป็นผู้เชี่ยวชาญกันไปทั้งหมด แต่ทุกคนจำเป็นต้องเข้าใจเรื่อง UX และตระหนักถึงเรื่องนี้ให้มากขึ้น

Tags: , ,