Unexpected outcome of UX

Case study จากหนึ่งในโปรเจคที่ทำจริงภายในบริษัท non-IT Corporate

กลับมาอีกครั้งกับบลอค UX ตามใจคนเขียน 😂
ถึงชื่อหัวบลอคจะดูอลังการ จริงๆมันไม่ได้หรูหราเบอร์ใหญ่อะไรหรอก
เป็นชื่อ session เราเอางานที่ทำให้ฐานะ UX Designer/Researcher มาพูดให้คนในบริษัทฟัง เพื่อแชร์ประสบการณ์และตัวอย่างจริงๆที่เกิดขึ้นโดยใช้ User-Centered Design mindset ซึ่งเป็นหนึ่งในคีย์หลักที่บริษัทพยายามผลักดันอยู่

บลอคในคราวนี้ก็จะเป็นการแปลงเอาสิ่งที่พูดใน session วันนั้น แต่ตัด Confidential info ต่างๆออกไป จะเน้นพูดถึงวิธีการและประเภทของ Deliverable ที่ออกมาแทน

แล้วทั้งหมดของการทำโปรเจคนี้ ไม่ได้เสิจหารูปสวยๆแบบนี้เลยจ้าาา (Photo from Pexels)

Intro โปรเจคคร่าวๆ

เนื่องจากบริษัทเราไม่ใช่ IT-based (แต่เราอยู่ในแผนกไอที) initiation ของโปรเจคใดๆส่วนใหญ่จะมาจากฝั่ง business ที่เป็นคนกุมบังเหียนแนวทางต่างๆ โปรเจคนี้ก็เช่นกัน Biz เป็นคนที่เริ่มไอเดียขึ้นมา แล้วติดต่อทางฝั่ง IT ให้ implement ระบบ โดยการรวมตัวระหว่างสองฝั่งขึ้นมาจะเรียกว่า “Project team” คือทีมเฉพาะกิจที่จัดตั้งขึ้นมาทำงานร่วมกัน เพื่อวางแผน พัฒนา และทดลอง ตามไอเดียตั้งต้น เมื่อผ่านการทดสอบและคิดว่าใช้งานจริงได้แล้ว โปรเจคทีมก็จะยุบตัวหายไป Operation ต่างๆหลังจากนี้ก็จะโอนถ่ายไปให้กับหน่วยงานที่เกี่ยวข้องแทน

ซึ่งโปรเจคนี้มีความพิเศษที่ว่า 1 ในทีม IT เริ่มเดาอนาคตได้แล้วว่าถ้าโปรเจคนี้สำเร็จ ปริมาณงานส่วนหนึ่งจะตกมาที่ IT Support เนื่องจากว่าการ maintainance ข้อมูลจะเกิดขึ้นค่อนข้างบ่อย (ต่ำสุดคือทุกๆ 1–3 เดือน) อีกทั้งข้อมูลที่ต้องแก้ไขเหล่านั้นบางส่วนก็ไม่ได้คอขาดบาดตายมากถึงขนาดที่ต้องมี process flow มาควบคุมป้องกันการทุจริตหรือกลโกงใดๆ เค้าเลยปิ๊งไอเดียว่าอยากทำเว็บสื่อกลางมาตัวนึง เพื่อที่ฝั่ง Business จะได้ config data ง่ายๆได้ด้วยตัวเอง ไม่ต้อง raise ticket กลับมาที่ฝั่ง IT

และนั่นคือสิ่งที่ทำให้ทีม IT ยื่นมือมาหาทีม UX เพื่อร่วมงานด้วยกันนั่นเอง :)

ปะ เริ่มทำงานกันดีกว่า~

Process คร่าวๆที่เราเอาจะมาพูดในวันนี้ (Icons from thenounproject)

Research

ขั้นตอนแรกที่เป็น Best practice ที่เหล่าชาว UX พยายามหนักหนาในการผลักดันให้เกิดขึ้น lol อย่างที่กล่าวไปข้างต้นว่าโปรเจคนี้คือทีม IT เป็นคนต้นคิด เค้าได้ตั้ง “สมมติฐาน” ว่าตัวเว็บไซต์ที่จะสร้างขึ้น จะช่วยให้ user ในอนาคตสามารถ config ข้อมูลได้โดยตรง และลดปริมาณงานที่ฝ่าย IT จะต้อง support ลง ซึ่งในขั้นตอนการทำ Research เนี่ยแหละ จะเป็นขั้นตอนสำคัญที่ทำให้เราพิสูจน์ได้ว่า กระบวนการทำงานจริงๆเป็นยังไง user จะคิดยังไง มีปัญหามั๊ย ไอเดียที่เราตั้งไว้ตอนแรกมัน valid จริงๆรึเปล่า

วิธีการ Research นั้นทำได้หลายแบบ จะสัมภาษณ์ user ตรงๆ ไปแอบนั่ง observe เวลา user ทำงาน วิเคราะห์ข้อมูลการใช้งานจาก tracking tool ต่างๆ หรือแม้กระทั่งไปสัมภาษณ์ stakeholders (ในที่นี้คือฝ่าย Business ที่เป็นคนคิด process ต่างๆของโปรเจค และ ฝ่าย IT ที่เป็นคน implement ระบบ เป็นต้น) ก็เป็นประโยชน์ทั้งนั้น

ซึ่ง outcome ที่เกิดขึ้นก็เป็นได้ทั้งแรงสนับสนุนในการลงมือทำ หรือ idea ใหม่ๆต่างๆที่จะทำให้ product ดีขึ้น หรือแม้กระทั่งการปัดตกไอเดียทั้งหมดที่เรามี เพียงเพราะว่ามัน “ไม่ใช่ปัญหา” ที่ user ต้องการจริงๆก็มี

แล้วโปรเจคที่เราทำล่ะ?

.

.

.

คำตอบคือศูนย์ โบ๋แบ๋ ไม่มี research จ้ะ 😅

อันนี้ก็ Brutal truth อะเนอะ บางโปรเจคมันมาด้วยงบหรือเวลาที่จำกัด ถ้าหัวไม่ได้เห็นค่าของ UX มากพอ มันก็ยากที่หางจะดิ้นไปมาขอไปหา user ตั้งแต่ต้น แต่ๆๆๆ ถึงเราจะไม่ได้ลงไปเก็บข้อมูลได้โดยตรง เราก็สามารถสอดแทรกการเก็บข้อมูลไปในแต่ละขั้นตอนถัดไปได้นะ :) ป่ะ ไปต่อจ่ะ

Information

User Flow แสดง flow การทำงานคร่าวๆ (Photo from Pexels)

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

ขั้นตอนนี้ ชื่อเต็มๆของมันคือ Information Architecture เป็นการออกแบบโครงสร้างข้อมูลเพื่อดูว่า product ที่เราจะสร้างมันจะมีข้อมูลอะไร ทำงานแบบไหน มี technical constraints ใดๆได้บ้าง

อย่าง user flow ของโปรเจคนี้ เนื่องจากว่ามันมี Rule engine ในการคำนวณอยู่ 7–8 rule เราก็แยะแต่ละ rule ออกมาแล้วเขียนว่า user สามารถเห็นข้อมูลอะไรได้บ้าง สามารถแก้ไขหรือสร้างข้อมูลใดๆขึ้นใหม่ได้ เมื่อคอมเฟิร์มว่าเข้าใจถูกต้องกับทีม IT แล้ว เราก็เอาไปคุยกับฝั่ง Business อีกที ว่าสิ่งที่พวกเราจะสร้างมันเป็นแบบนี้นะ มันทำงานแบบนี้ๆๆได้ ซึ่ง feedback แรกที่ได้รับเลยก็คือ rule ที่จะแก้ไขบ่อยจริงๆในเชิง business อะ มันมีแค่ 2 ข้อเอง ลองทำแค่นั้นก่อนดีกว่ามั๊ย แล้วค่อยมาว่ากันทีหลังว่าจะเวิร์คไม่เวิร์ค ก็ถือว่าลดสโคปงานไปเกินครึ่ง ตั้งแต่ก่อนการออกแบบหน้าตาหรือลงมือเขียนโค้ดเลยด้วยซ้ำ

อะ เราได้ core idea ที่จะเริ่มทำงานละ เริ่มลงมือดีไซน์เลยดีกว่า :D

Design the wireframe

Sketch คร่าวๆ แสดงการวางตำแหน่งและข้อมูลที่จะให้ user เห็น (Photo from Pexels)

Design แรกสุดที่ไวสุดและลวกสุด คือการวาด Wireframe ซึ่งส่วนใหญ่เราจะชอบวาดลงบนไวท์บอร์ดเพราะมันลบและแก้ไขได้ง่าย ขั้นตอนนี้หลักๆจะเป็นเพียงการวางข้อมูลในแต่ละหน้า เพื่อเช็คดูว่ามันเหมาะสมมั๊ย พื้นที่เพียงพอรึเปล่า เมื่อเราวาดเองจนพอใจแล้วก็สามารถ snap รูปแล้วเอาไปถาม feedback ต่อได้ทันที คีย์สำคัญของการทำ wireframe ก็คือการไม่ลงความสวยงาม ใช้สีแค่ monochrome เพื่อสโคปความสนใจของ test participant ให้โฟกัสอยู่ที่ function ล้วนๆ (เคยเอาเวอร์ชั่นสีไปเทสรอบนึง user เถียงกันอยู่ 20 นาทีว่าทำไมตรงนี้ใช้สีนี้ ไม่ใช่สีนั้น…) เพราะงั้นจะวาดมือหรือวาดดิจิตอลก็ไม่ได้ให้ผลที่ต่างกันเท่าไหร่ในความรู้สึกเรา

Design the prototype

Prototype แสดงการลิงค์ของปุ่ม/element ไปหน้าต่างๆ (Photo from Figma)

ถ้า wireframe คือ First look ตัว prototype ก็คือ First experience หลังจากที่เราวางโครงคร่าวๆเพื่อดูความเหมาะสมของการจัดวางแล้ว สิ่งต่อไปก็คือการเชื่อมโยงแต่ละหน้าไว้ด้วยกัน Key สำคัญของ Prototype test ก็คือ Fake it till you make it ในขั้นตอนนี้เราจะพยายามทำทุกอย่างให้สมจริงที่สุด (รวมไปถึงเนื้อหาในระบบ ฟอนท์ สี flow การใช้งานต่างๆ) เนื่องจาก Prototyping tool สมัยนี้ฉลาดมาก (ไม่ว่าจะ Adobe XD, Sketch หรือ Figma) เราสามารถ mock ตัวโปรดักต์ของเราให้เหมือนจริงที่สุด กล่าวคือ test participant สามารถกดลิงค์ที่เรา export ออกมา สลับไปมาระหว่างหน้าต่างๆได้เหมือนจริงโดยที่เราไม่ต้องไปรบกวนฝั่ง developer ในการเขียนโค้ดให้เลย

จุดประสงค์หลักของ Prototype test สำหรับ IT product เช่นแอปหรือเว็บไซต์ ก็คือการดู Flow การใช้งานทั้งหมดว่ามันไหลลื่นมั๊ย make sense พอรึเปล่า คือบางครั้งตอน design แต่ละหน้ามันดูเวิร์คนะ แต่พอลองคลิกสลับไปมาตาม flow จริงๆ ก็อาจจะเจอความสะดุดบ้าง แอบงงบ้างว่าข้อมูลตรงนี้ที่แสดงขึ้นมามันไม่เชื่อมต่อกับหน้าที่แล้ว เป็นต้น ข้อดีอีกอย่างนึงของการทำ Prototype ก็คือเมื่อเราเทสผ่านเรียบร้อยแล้ว เราสามารถส่งตัว prototype ให้ไป developer พัฒนาต่อไปโดยอ้างอิงจาก prototype นั้นๆได้เลย

อนึ่ง prototype ไม่ได้จำกัดอยู่เพียงแค่ tools ที่เรากล่าวมาในข้างต้นเท่านั้น มันมีอีกหลายวิธีในการสร้างมันขึ้นมา เช่น Paper prototype ที่ปริ้น wireframe แยกแผ่นออกมา ให้ test participant เอานิ้วจิ้มๆ แล้ว test moderator ก็เปลี่ยนกระดาษไปหน้าอื่นเป็นการจำลอง transition คร่าวๆ หรือจะทำ prototype ไวๆจาก Powerpoint Presentation โดยการใช้ hyperlink feature เปลี่ยนหน้าไปมาก็ได้ หรือบาง IoT product ก็สามารถใช้การตัดต่อวิดิโอเข้ามาเล่นตรงนี้ได้เช่นกัน

Design the real product

ใครโค้ด? เราไม่โค้ดดดดด lol (Photo from Pexels)

เมื่อ design และ prototype ต่างๆจบครบกระบวนการแล้ว ขั้นต่อไปคือการลงมือพัฒนาโปรดักต์จริงๆ ซึ่งในฐานะ UX Designer/Researcher เราไม่ได้ลงมือโค้ดเอง (ใช่สิ 5555+) แต่สิ่งที่สำคัญคือการโคงานกันระหว่างเราและ developer

คือบางอย่างที่เรา design มาอาจจะอิงจาก Styleguide หลักของโปรเจ็คต์ใหญ่บ้าง รสนิยมและความรู้ส่วนตัวบ้าง ซึ่งไม่ใช่ทุกอย่างที่ apply ในการเขียนโค้ดได้จริง แต่ละ framework ก็มี constraints และ limitation ของมัน สุดท้ายทั้ง Developer และ Designer ก็ต้องมาคุยกันว่า จะให้ความสำคัญกับฝั่งไหนมากกว่า บางจุด Design อาจจะมี hidden agenda ที่ทำให้เปลี่ยนแปลงไม่ได้ ในขณะที่บางจุดก็ไม่ได้คุ้มค่าที่จะต้องเพิ่มเวลา dev ไป 3 วัน 7 วันเพื่อให้มันเป็นไปตาม Design ตอนแรกก็มี เพราะงั้นก็คุยกันดีๆ จูนงานกันไป สุดท้าย Product ที่ออกมาจริงๆก็อาจจะไม่ได้เหมือน prototype ตัวที่ออกมาก่อนหน้านั้นเป๊ะๆ

Validation

การใช้งานแอปตอนอยู่ในบ้านกับนอกบ้าน ก็ expectation ต่างกันนะ (Photo from Pexels)

เพื่อพัฒนาเสร็จเรียบร้อยแล้ว ขั้นตอนสุดท้ายคือการ validate ว่าผลงานที่เราทุ่มเทลงแรงมาทั้งหมด user ที่เป็นผู้ใช้จริงๆนั้นรู้สึกยังไง แต่ถ้าลองสังเกตดีๆ ในแต่ละขั้นตอนการ Design จะมีการ validate ภายในตัว ที่เราเอาไปถามและเก็บ feedback จาก test participant เสมอ ซึ่งสิ่งเหล่านั้นจะเป็นตัวการันตีว่าตลอดเวลาเราได้เดินมาถูกทาง ป้องกันไม่ให้การลงทุนลงแรงทั้งหมด หลังจาก dev เสร็จเรียบร้อย แล้วพบว่าที่เดินมาตลอดทางอะ ปีนเขาผิดลูกจ่ะแม่ //ล้องห้ายยย

สำหรับบริษัทของเราที่เป็น Internal tool การเทสจริงๆกับ user อาจไม่ได้มี setting ที่หวือหวาอะไรเพราะมันคือการเปิดเว็บบนหน้าจอคอมทำงานที่เกือบจะเป็นมาตรฐานเดียวกันทั่วบริษัท แต่สำหรับแอปมือถือ การเทสในสถานการณ์จริงนั้นสำคัญมากๆ เช่น แอปเรียกวินมอไซค์ พอวินมารับแล้ว ใน flow ตอนแรกมันอาจจะเด้งหน้ารีวิวตามปกติ แต่ตอนใช้งานจริงๆคือ user ฟาดขาขึ้นวินแล้วอะ จะเอามือไหนไปกดดด

ซึ่งการ Validation นั้นมีหลากหลายวิธี จะทำ usability test ที่ setup test แบบจริงจัง มี moderator นั่งคุยกับ user ห้องนึง แล้วต่อมอนิเตอร์ไปห้อง observer อีกห้องนึง หรือจะ Acceptance test ทั่วไปที่ deploy ขึ้น acceptance environment ให้ user ลองเล่นแล้ว feedback กลับมา หรือจะเดินตามวิถีคนจริง test บน production ไปเลย ไม่ว่าจะทำ A/B testing แบ่งกลุ่ม design เดิม/ใหม่ แล้ววัดผลด้วย data tracking หรือจะปล่อยมันดิบๆแล้วรอเก็บ user feedback (หรือคำด่า…) ทีหลังก็ยังได้

แล้วโปรเจคที่เราทำอยู่ล่ะ?

.

.

.

.

.

โบ๋แบ๋อะเกน user คืออะไร user คือใคร user อยู่หนใดดดด //ร้องไห้แพพ

brutal truth ตรงๆจังๆจ้ะ อย่างที่บอกไปตอนต้นบลอคว่าโปรเจคนี้คือทีม IT initiate ขึ้นมาเอง มีไอเดียที่อยากจะลอง validate อยู่ แต่ถ้าฝั่ง business ที่เป็น core หลักยังไม่พร้อม process ต่างๆยังไม่เคลียร์ เราก็จะยังไม่รู้ซักทีว่า user ที่จะมา hand-over โปรเจคนี้ต่อไปนั้นคือใคร แล้วพอไม่มี user เราก็ไม่รู้จะเทสกับใคร พวก Super User หรือ User Expert ที่อยู่ในโปรเจคก็ involve มาตลอดในขั้นตอนก่อนๆ ทำให้ไม่สามารถ unlearn ความรู้ความเข้าใจที่เค้ามีแล้วนำมาเทสแบบ user ใหม่แกะกล่องได้ สรุปก็คือ ไม่มี test subject ให้ validate จ้ะ ;w;

แต่นั่นก็ทำให้เกิดสิ่งที่เป็น title ของบลอคในวันนี้นะ 👇👇👇

User Handbook

หารูปที่เกี่ยวข้องไม่ได้ เอาอันนี้ไปดูเพลินๆละกัน (Photo from Pexels)

ใช่ค่ะ User Handbook หรือ Manual หรือหนังสือคู่มือการใช้งานทั่วไปนั่นแหละ

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

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

Wrap up

สรุปนะคะ UX process flow คร่าวๆที่เราใช้ทำงาน:

1. Research ทำความเข้าใจ user, situation, stakeholder มองหาปัญหาที่แท้จริงให้เจอ แล้ว explore หาความเป็นไปได้ในการแก้ไขปัญหานั้นๆ
2. Information วางโครงสร้างข้อมูล, flow การทำงาน, techninal constraint ต่างๆเพื่อ core idea ที่มั่นคงก่อนเริ่มลงมือทำ
3. Design ออกแบบหน้าตา, การจัดวาง, experience ต่างๆในการใช้งานทั้งหมด โดยที่ในแต่ละขั้นตอนก็ต้องคอยไปเทส เก็บ feedback เสมอๆ เพื่อสเต็ปต่อๆไปที่ลงดีเทลจะได้ไม่ต้อง rework เยอะ
4. Validation นอกจากการเทสในแต่ละเสต็ปข้างบนแล้ว แม้ว่าเราจะ launch product ออกสู่สายตาชาวโลก ก็อย่าลืมคอยย้อนกลับไปเก็บ Feedback เสมอๆ เพื่อพัฒนาผลงานของเราให้ดีขึ้น ให้ดีคงทนไปยาวๆ

และสุดท้าย สำหรับ User-Centered Design mindset เหล่านี้ สิ่งสำคัญไม่ใช่ว่าคุณเป็น expert หรือไม่ คุณใช้เครื่องมือแบบไหน แต่มันอยู่ที่ว่าคุณสนใจ user มากพอมั๊ย แล้วคุณ (ไม่ว่าจะในฐานะ Designer, Developer, Business หรือตำแหน่งใดๆ) จะสามารถผลักดันโปรเจคหรือโปรดักต์ในมือคุณ ให้เข้าไปในใจของ user เหล่านั้นได้มากน้อยเพียงใด ทุกคนในโปรเจคล้วนมีส่วนสำคัญในการพัฒนาและเสนอไอเดีย

เพราะงั้น Just keep going นาจา~

บลอคจบแล้วจ้ะ ยาวเกินกว่าที่คิดไปเยอะเลย
อ่านจบแล้วขอ 👏 เป็นกำลังใจให้ด้วยนะ 😙❤️