UX ในธุรกิจ B2B มันเป็นอย่างงี้นี่เอง (ORGX)

10 ปีที่ผ่านมากับการเป็น dev เป็น CTO จนมาปีนี้ได้โอกาสจากพี่ๆผู้บริหารให้ลองเปิดทีม UX ขึ้นมา

ตลอดเวลาได้ไปร่วมงาน meetup, seminar, summit ทางด้าน UX มาบ้าง ไปคุยกับมืออาชีพด้านนี้มาก็หลากหลาย คิดว่าเข้าใจศาสตร์นี้ในระดับหนึ่ง แต่ก็ยังไม่เคยลองออกฟิลด์จริงๆสักที

แล้ววันนึงก็ได้ทำ…

ไม่ใช่ทำคนเดียว ทำพร้อมกับน้องๆทีม UI และน้องเดฟอีกคนนึงที่สนใจด้านนี้และอยากเปลี่ยนสายอาชีพมาลองทำ

เริ่มคนเดียวก็ยากอยู่แล้ว นี่เริ่มแบบมาเป็นทีม

จากที่ต้องคิดว่า “เฮ้ย ทำแบบนี้ดีมั้ยวะ?” ยังต้องมาคิดอีกว่า “แล้วจะแบ่งงานไหนให้ใครทำดี?”

Chaotic สุดๆค่ะใน mission แรกๆ แต่ทุกคนในทีมสู้แค่ตายมาก แม้จะอยู่ภายใต้ความกดดันมหาศาล ถ้าเราทำไม่สำเร็จวันนี้ โอกาสที่ทีม UXD จะไม่ได้ไปต่อก็มีอยู่สูงมาก มันทำให้นึกถึงหนังเรื่องนึงที่เคยดูเลยค่ะ

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

“เพราะเธอคือผู้หญิงคนแรก เธอจะเป็น standard ของผู้หญิงอีกหลายๆคนที่จะสมัครเข้ามาเป็นนาวิกโยธินในอนาคต คนทั้งกองทัพจับตาดูเธออยู่ ผู้หญิงพวกนั้นก็จับตาดูเธออยู่ ถ้าเธอยอมแพ้วันนี้ มันจะไม่มีแม้กระทั่งโอกาสสำหรับผู้หญิงพวกนั้น...”

ชื่อเรื่องอะไรก็จำไม่ได้เลยท้าทายอยู่คนเดียว น้องๆไม่รู้ด้วย 5555

แต่สุดท้ายทีม UXD เราก็สามารถการันตีว่าได้ผลลัพธ์ usability testing ภายใน 3 วันทำการค่ะ!! เฮ้ย ทำได้ไงอ่ะ…

มาดูกันดีกว่า…

จั่วหัวว่า B2B UX แถมมีคำว่า ORGX วงเล็บกำกับไว้ด้วย (ไม่ต้องไปเซิร์สหาที่ไหนนะคะ เราตั้งขึ้นมาเอง 5555) สำหรับเราแล้วมันแตกต่างในกระบวนการการได้มา และการพิสูจน์ มันคือ Multiple UXs มารวมกันสุดท้ายกลายเป็น experience ที่ดีในระดับองค์กร (Organization Experience)

แอพพลิเคชั่นทุกตัวของ Builk One Group เป็นแอพพลิเคชั่นที่ใช้งานในระดับองค์กรล้วนๆ ซึ่งแต่ละ application จะส่งผ่านข้อมูลกันเป็นซีรี่ย์ ไม่ว่าจะข้ามแผนก/ข้ามตำแหน่ง/ข้ามประเทศ/ข้ามบริษัท หลายครั้งๆต้องพลิกมุมกลับ ปรับมุมมอง information ชุดเดียวกันไปหลายๆ perspective

Data แทบทุกอย่างของ B2B application จะมีวงจรชีวิตที่ว่า พนักงานระดับ operation เป็นผู้บันทึกไว้ >> พนักงานระดับ manager เป็นผู้รวบรวมและสรุปให้ >> executive เอามาดูและตัดสินใจ >> และบางครั้งก็ส่งต่อไปให้ customer ขององค์กรนั้นๆเอาไปใช้งาน

เป็น chain ที่ยาว ใหญ่ และประกอบไปด้วยหลาย personas ที่เกี่ยวข้อง แต่อาจจะต่างกรรมต่างวาระกันไป

แค่บอกว่า มาทำระบบ payment gateway กันเถอะ..ก็สะเทือนไปค่อนบริษัท ตั้งแต่ลูกค้าที่เป็นคนจ่ายเงิน ฝ่ายขายที่ต้องเก็บเงิน ไปจนถึงฝ่ายบัญชี

ทุกคนคงพอจะเห็นภาพความใหญ่ยิ่งของระบบที่มี persona หลายคนแล้ว เพราะฉะนั้นทุกครั้งที่ทีม UXD ถูกเรียกใช้งานเมื่อไหร่ เราจะยึด ORGXD Life Cycle อันนี้ไว้ประหนึ่งเกลือรักษาความเค็ม

UXD Life Cycle v.3 หรือ ORGXD ที่แปะอยู่บนกระดานของทีมยังเป็นเวอร์ชั่นเก่ากว่านี้เลยค่ะ 5555

Strategy

Idea : OKR

ทุกครั้งที่ทีม UXD ถูกเรียกตัวเข้าไปฟัง Brief สิ่งหนึ่งที่เราจะทำเสมอ คือ ชวน Idea Owner ตั้ง OKR ค่ะ

ทำไมต้อง OKR? เพราะมันไม่เพียงประกอบไปด้วยเป้าหมาย แต่มันยังมี Key result ที่เอาไว้วัดได้ ว่าถ้าผลลัพธ์เกินเส้นไหนเราถึงจะไปต่อ

Key Result ของทีมเราต้องมี 2 ปัจจัยเสมอ

1. จุดไหนที่เรียกว่าบรรลุ Goal
2. จุดไหนที่เรียกว่าเกิด Awareness

ดังนั้นทุกมิชชั่นที่ผ่านมือต้องทำสองเรื่องเป็นอย่างน้อย

ทำยังไงให้ customer รู้ว่ามีสิ่งนี้ และจุดประสงค์ของมันคืออะไร นำไปสู่การใช้เองได้ ใช้ง่าย และใช้เป็น

และด้วยความที่เรามีแอพพลิเคชั่นที่ผลิต data มหาศาลอยู่แล้ว ก่อนจะวางแผน ก่อนจะได้ OKR เราจะตั้งคำถามที่ประกอบไปด้วย Who, what, where, when, why (+how) เพื่อหาคำตอบเบื้องต้นจากการคุ้ย data ที่มีอยู่ ว่าไอเดียนี้ที่เกิดขึ้นมาเพราะต้องการแก้ pain ไหน — pain นี้มีอยู่จริงมั้ย คำตอบทั้งหลายอยู่ใน data

Research

Conducted research data : Existing swim lane flowchart

ขั้นนี้เราจะกระจายตัวกันไปสัมภาษณ์ผู้เกี่ยวข้องเพื่อหา user flow หรือ user journey ที่ทุกฝ่ายทำอยู่เป็นเรื่อง “ปกติ” มาให้ได้มากที่สุด โดยจะมีคนนึงรับหน้าที่สืบหา competitive workflow โดยทั่วไปหน้าที่นี้จะเป็นเราเองค่ะ 5555

ไม่จำกัดวิธีการหา จะสัมภาษณ์ จะปลอมตัวไปหลอกถาม จะไปลองซื้อคอนโดจริงๆเพื่อให้เข้าใจวิธีการทำงานนั้นๆก็ได้ไม่ว่ากัน XD

แต่ทุกครั้งก่อนออกไปเราจะเตรียมสิ่งที่เราเรียกกันว่า Hypothesis (สมมุติฐานที่เราต้องการพิสูจน์) ร่วมกัน หลักๆมันคือ เป็นของที่เราจะหยิบไป confirm กับลูกค้าจริงๆว่าไอเดียนี้ Valid

แต่เมื่อสิ้นวัน เราจะมาต่อภาพ flow กันด้วย Swim lane flowchart

นี่คือจุดที่เราล้มลุกคลุกคลานกันมาอย่างหนักมาก กว่าจะรู้ว่าที่เหมาะกับการทำงานที่มี persona มากกว่า 10 คือ flowchart ที่มี swim lane

นี่คือจุดที่เราคิดว่า UX B2B แตกต่างจาก B2C มาก เพราะ..

คนซื้อระบบ อาจไม่ได้ใช้ คนใช้ระบบ อาจไม่ได้ซื้อ

แต่เป้าหมายคือ คนที่ซื้อระบบต้องพึงพอใจพอที่จะลากทั้งองค์กรมาใช้ระบบ ในขณะที่คนที่ต้องใช้ระบบ ต้องไม่ทรมานมากเกินไปจนเขวี้ยงบาตร (ขั้นกว่าของคว่ำบาตร)

แต่ละ flow ที่ผ่านมือ มันจะยุ่งเป็นยุงตีกันประมาณนี้

เมื่อได้ flow ทุกคนจะใช้ Says, Does, Thinks, Feels จาก Empathy map มาไล่แปะตาม flow สุดท้ายเราจะเริ่มเข้าใจ Pain จากการทำงานแบบเดิมที่แต่ละฝ่ายอาจจะพูด หรือไม่พูดออกมา

Analysis

Researched data : Initiative information

จังหวะนี้เป็นจังหวะที่เราจะเริ่มสร้าง Persona ขึ้นมา(บางๆพอ เอาแค่ให้เห็นภาพ บางทีแค่ปริ้นท์รูปมาแปะข้างกระดาน) เพื่อเอามาสร้าง User Flow/System Flow ที่มี swim lane เป็น persona หรือ system ที่จะเกี่ยวข้อง ของระบบใหม่ที่น่าจะแก้ pain บนระบบเก่าของเขาได้ ขอขีดเส้นใต้คำว่า “น่าจะ” เพราะ flow ใหม่ที่สร้างขึ้นมา ก็ยังถือว่าเป็นแค่ Hypothesis หรือ “ระบบที่เราเชื่อว่าถ้ามีอยู่ ความเจ็บปวดทรมาน(จากขั้นตอน Research) จะหายไป”

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

เพราะส่วนใหญ่คนเราจะอินกับอะไรสักอย่างจนยอมเอามันเข้ามาอยู่ในชีวิตประจำวันได้ ก็ต่อเมื่อเข้าใจมัน(ในบริบทของตัวเอง)แล้วเท่านั้น

Design

System Flow : Wireframe

ขั้นตอนนี้มักจะเป็นช่วงเย็นของวันที่ 2 ของการทำงานภายในทีม UX ก่อนที่เราจะออกไป validate กับบุคคลภายนอกอีกครั้ง ดังนั้นสิ่งที่เราจะเตรียมให้พร้อมคือสิ่งที่เราเรียกกันว่า “การหลอกที่สมจริง”

Fake it, until you make it.

ถ้าบอกว่า New System Flow ของการแจ้งปัญหาการใช้งานออนไลน์นี้คือ LINE Bot เราก็จะสวมร่าง LINE Bot แล้วแชทตอบกับลูกค้าจริงๆเสมือนระบบนี้ได้มีอยู่แล้ว หลายครั้งที่ต้องระวังตัวเรื่องกฎหมายการใช้ข้อมูล ความรู้สึกที่ลูกค้ามีต่อระบบ และภาพจำ (สำหรับลูกค้าบางคน อาจติดภาพของการทดสอบรอบก่อนหน้าจนไม่สามารถย้อนกลับมาให้เขาทำการทดสอบได้อีก)

การคิดสถานการณ์เสมือนจริงเพื่อให้ได้ผลตอบรับที่เรียลพอในการวัด Usability Testing นี้ คือการสร้าง Test Scenario

Test Scenario ที่ละเอียดไปนิด หลังๆเราตั้งไว้แค่ task พอค่ะ 555

จากภาพนี้จะทำให้เราพอรู้ละ ว่าจะออก interface ที่เป็นส่วนติดต่อกับลูกค้ายังไง เพื่อให้ตอบ test scenario แต่ละอันได้ เกิดเป็น Wireframe เรียกได้ว่า จะหลอกแบบไหน ก็สร้างภาพไปแบบนั้น

พยายามให้น้องๆลงบนกระดาษก่อนค่ะ เพื่อตีกันเองภายในก่อนไปถึงลูกค้า

Production

Wireframe : Prototype

ส่วนใหญ่ ขั้นตอนข้างบนทั้งหมด อาจจะทำแค่บางส่วน หรือบางทีก็ทำทั้งหมด แต่ wrap up ให้จบในสองวัน แล้ววันสุดท้าย จะคล้ายๆกับวันใช้กรรม

ที่ดีไซน์มาหรูหราขนาดไหน ต้องปั่น Prototype เพื่อเอาไว้หลอกว่าระบบพร้อมใช้แล้วให้สำเร็จภายในวันนี้ จนหลายๆครั้งที่ต้อง Scope down ลงมาให้เหลือเป็น MVP prototype เพื่อพิสูจน์ Critical idea ที่เราเชื่อว่า นี่แหละ “Killing Feature”

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

นับว่าโชคดีค่ะ ที่ในทีม UX เรามีเดฟที่หันมาเอาดีทางด้านนี้ปะปนอยู่ด้วย ทำให้การทำ MVP เป็นไปได้ และสมจริงมากขึ้น (แต่ไม่ใช่ทุกครั้งที่เราจะลงทุนอย่างนี้นะคะ 555)

เตรียมใช้กันได้เลยค่ะ feature นี้ บน builk.com แฮ่

Beta Launch

Test Scenario : Usability Testing

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

และผลของการทดสอบจะจับเวลาเป็นวินาที หรือจับจาก Google analytics ที่ใส่ไว้ในขั้นตอน Production

Loop

UX Testing result : Make a decision

เป็นวันที่เราจะเอาผลลัพธ์ที่ได้ มาตอบ OKR ที่ตั้งไว้ตั้งแต่ day 1 เพื่อดูว่าระบบที่กำลังจะเกิดถือว่าตอบเป้าประสงค์ขององค์กร และ Persona ทั้งหมดที่เกี่ยวข้องหรือไม่ หรือควรย้อนกลับไปปรับในจุดไหน

หลายครั้งที่ก็ต้องย้อนกลับล้างกระดาน ทำความเข้าใจกันใหม่ เพราะผลที่ได้ไม่เป็นอย่างที่คิด

ก็จบลงแล้ว สำหรับวิบากกรรมที่เรา 4–5 คนล้มลุกคลุกคลานกันมา จาก Flow ง่ายๆแค่นี้ในวันแรก

วันแรกที่ตั้งทีม มีแค่นี้ค่ะ เอา Design Thinking มาตั้งเลย

กลายเป็น UXD Life Cycle V.3 ในวันนี้

“และสัญญา ว่าจะไม่หยุดค่ะ!!” XD