ทำไมเราถึงต้องลงแรงสร้าง feature ที่ไม่ได้เพิ่ม revenue ให้กับเรา?
สำหรับใครที่ยังไม่รู้.. เราเปลี่ยนสายงานอีกแล้วค่ะ 5555+
เนื่องจากตอนนี้ทำงานอยู่ Product team มีหน้าที่คล้ายๆ Product Owner + Quality Assurance คือต้องเป็นคนที่รอบรู้ใน features ส่วนที่ทีมดูแล ทำ Test & collect feedback จากทีม Business เพื่อพิจารณาแต่ละ enhancement ว่าจะนำมาปรับใช้เข้ากับประเทศไทยมั๊ย รวมถึงการประสานงานต่างๆเมื่อต้องการจะสร้าง Feature ใหม่ๆเข้า Pipeline
เกริ่นมาซะยาว แค่จะบอกว่าเนื้อหาบลอคก็อาจจะเปลี่ยนโทนไปตามสายงานปัจจุบันของตัวเองเท่านั้นแหละค่ะ
ถ้างั้นแล้ว เข้าเนื้อหากันเลยดีกว่าเนอะ :3
Tip feature คืออะไร?
ฟีเจอร์เล็กๆ ตรงตัวและเข้าใจง่ายอันนี้เป็นการเพิ่มเงินพิเศษให้กับไรเดอร์ คนกลางที่ทำหน้าที่สั่งอาหารแล้วนำมาส่งให้กับ user อย่างเราๆนี่เอง
ระบบการให้ทิปนั้นไม่ได้เป็น norm หรือ บรรทัดฐานสำคัญในประเทศไทยที่ทุกคน “ต้อง” ให้เพิ่มกับผู้ให้บริการ เราจะเห็นการให้ทิปได้บ่อยกับผู้ให้บริการบางประเภท เช่น พนักงานเสิร์ฟ, คนโบกรถ และ พนักงานยกกระเป๋า ในส่วนของพนักงานส่งอาหารเดลิเวอรี่นั้น ก็มีการให้บ้างแล้วแต่ธรรมเนียมของผู้รับบริการ ตลอดไปจนถึงพฤติกรรมของตัวผู้ให้บริการเอง
แล้วทำไม Grab ถึงเพิ่มฟีเจอร์นี้เข้ามาในระบบล่ะ?
The why
การให้ทิปไม่ใช่เรื่องใหม่ เป็น User behavior ที่มีอยู่แล้ว แม้กระทั่ง user ของ Grab เอง ก็ยังมีการให้ทิปกัน offline ก่อนที่จะมีการ launch feature นี้ขึ้นมาเสียด้วยซ้ำ
อ้างอิงจากบทความของ NST จะเห็นว่าในช่วงการแพร่ระบาดของ Covid-19 จนเกิดการ lockdown ในประเทศมาเลเซีย ได้ส่งผลให้พฤติกรรมการใช้งานของ user ได้เปลี่ยนแปลงไป หลายคนๆหันมาใช้บริการเดลิเวอรี่มากขึ้น ตระหนักถึงความสำคัญของไรเดอร์มากขึ้น และเริ่มให้ทิปแสดงความขอบคุณมากยิ่งขึ้น Grab เองก็รับรู้ถึงความเปลี่ยนแปลงตรงนี้ (อีกทั้งยังมี user’s feedback เวลาที่ตัวเองลืมให้ทิปกับไรเดอร์หลังจากใช้บริการ) จึงคว้าโอกาสในการพัฒนาฟีเจอร์ใหม่ที่ตอบโจทย์ผู้ใช้ ถึงแม้ว่าจะไม่ได้มี direct benefit กลับเข้ามาหาตัวบริษัทเองก็ตาม
แล้ว In-direct benefit ล่ะ?
Grab เป็น application ที่ทำงานเป็นตัวกลางในการประสานงานระหว่างบุคคลต่างๆ ไม่ว่าจะเป็นร้านอาหาร (กรณีสั่งเดลิเวอรี่) ไรเดอร์ และตัว user เอง stakeholders เหล่านี้เป็นปัจจัยที่คุมได้ยาก ตัวบริษัทเองจึงต้องสร้าง protocal ต่างๆขึ้นมาเพื่อควบคุมคุณภาพของการใช้งาน อย่างที่เห็นได้จาก Partner’s code of conduct, ระบบรีวิวและคอมเมนท์ เป็นต้น
ส่วนตัวเราว่าฟีเจอร์การให้ทิปนี้ก็เป็นอีกหนึ่ง protocal ที่ส่งผลทางอ้อมให้ stakeholder environment เป็นไปในทิศทางที่ดีขึ้น ตัว user สามารถแสดงน้ำใจหรือคำขอบคุณในรูปแบบที่ง่ายและรวดเร็ว อีกทั้งยังการันตีว่าไรเดอร์ไม่สามารถปฏิเสธด้วยการยัดเงินคืนใส่มือกลับไปได้ ส่วนตัวไรเดอร์เอง เมื่อได้รับทิป ก็จะช่วยผลักดันให้มีกำลังใจในการให้บริการที่ดี ส่งผลกลับมาเป็น service ที่มีคุณภาพ แถมยังสามารถนำฟีเจอร์ไปโฆษณาต่อเพื่อสร้างภาพลักษณ์ที่ดีให้กับทางบริษัทได้อีกด้วย
The how
นอกจากเหตุผลที่ทำให้ Grab สร้างฟีเจอร์นี้แล้ว วิธีการที่เค้าออกแบบการใช้งานก็น่าสนใจเช่นเดียวกัน ส่วนตัวเราว่าเค้าออกแบบมาได้ดีและไหลลื่นมากๆ
มาค่ะ เดี๋ยวพาไปดู
- Design the component
ก่อนอื่น เริ่มด้วยตัว component ก่อน ภายในกล่องสีน้ำเงินที่ Highlight ไว้ จะเห็น 2 ส่วนหลักๆที่เราเน้นเอาไว้ อย่างแรกคือ suggested tip amount ที่เซ็ทจำนวนเงินไว้ตั้งแต่น้อยไปมาก ผ่านปุ่ม 6 ปุ่ม ตัว user เองสามารถกดจิ้มทีเดียวแล้วจบได้เลย แต่ถ้ายังไม่มีจำนวนที่ต้องการ ก็สามารถกดปุ่ม custom amount เพื่อใส่จำนวนเงินตามใจตัวเองได้
Fast checkout แบบนี้ทำให้เราคิดถึงกฏ 20 วินาที ที่ว่าถ้าอะไรใช้เวลามากกว่านั้นในการเริ่มต้นทำ มีโอกาสมากเราจะรู้สึกไม่สะดวกและล้มเลิกไป เพราะงั้น User flow ธรรมดาที่ต้องคิดว่าจะทิปเท่าไหร่ กรอกตัวเลขลงไป จึงใช้เวลาและความคิดมากเกินไป การเตรียมตัวเลือกไว้ตั้งแต่แรกสามารถกระตุ้นให้ user ทำในสิ่งที่ UI เชื้อเชิญไว้ง่ายยิ่งขึ้น
อย่างที่สองคือ Worry-free clarification จะเห็นได้ว่าด้านล่างมีตัวอักษรขนาดกลางๆอธิบายเนื้อหาบางส่วนที่อาจจะทำให้ user ไม่สบายใจ บนสุดคือข้อความที่เน้นย้ำว่าเงินทิปทั้งหมดจะเข้าตรงไปยังไรเดอร์ Grab เองไม่มีส่วนแบ่งจากตรงนี้ ส่วนบรรทัดถัดมา จะเห็นว่าหน้าจอที่เราแคปมาเป็นช่วงที่ไรเดอร์กำลังมาส่งสินค้าให้เรา งานบริการยังไม่จบ แต่ Grab เลือกที่จะโชว์ Tip component ก่อนเพื่อแก้ปัญหา user ลืมให้ทิป (ตามที่สัมภาษณ์ในบทความของ NST) แต่ก็ยังไม่ลืมชิงอธิบายไปด้วยว่าถ้างานยังไม่จบ ทิปก็จะยังไม่จ่ายนะจ๊ะ
พอผสานรวมความง่ายในการใช้งานกับความอุ่นใจในการ take action ฟีเจอร์ทิปจึงเป็นส่วนเล็กๆที่สร้างแรงจูงใจในการส่งต่อ positive vibe จาก user ไปสู่ rider ได้ดีจริงๆ
2. User flow
นอกจาก component ที่คิดมาอย่างดีแล้ว Flow การใช้งานก็ยังไหลลื่นและ intuitive อีกด้วย จากที่เห็นรูปข้างบน Tip component ไม่ได้แสดงแค่ก่อนจะได้รับสินค้า แต่เมื่อบริการจบลง Grab ก็ยังสามารถสอดแทรกการให้ทิปเข้าไปใน flow อย่างแนบเนียน
ฟีเจอร์การให้ทิปนั้นจะไม่ได้แสดงออกมาอย่างดื้อๆ แต่ตัวแอปเองจะวิเคราะห์ก่อนว่า user นั้นพึงพอใจกับการบริการของไรเดอร์มากน้อยแค่ไหน ถ้าลองสมมติเหตุการณ์ในชีวิตจริง เมื่อเรารับของจาก messenger ที่ทำงานได้ห่วยมากๆ แล้วคนนั้นๆยื่นมือขอทิปเราทันทีที่สินค้านั้นมาถึงมือเรา เราจะรู้สึกยังไง?
ในแอปก็คงให้ความรู้สึกไม่ต่างกัน
ดังนั้น จะเห็นว่าตอนแรกที่เรากดรีวิว 4 ดาว แอปจะแค่ถาม feedback ว่าไรเดอร์ควรปรับปรุงในเรื่องใด แต่ถ้าเราประทับใจมากๆ กด 5 ดาวเต็มไปเลย Tip component จึงจะโผล่มา เพราะประเมินแล้วว่ามีสิทธิ์สูงกว่าที่เราจะอยากให้ทิปกับการบริการที่ยอดเยี่ยม และถ้าสังเกตดีๆ set คำถามและคำตอบก็ปรับเปลี่ยนเป็นการชื่นชมให้ตรงตาม context ด้วยเช่นกัน -w-
Wrap up
สรุปแล้ว เราเรียนรู้อะไรจากฟีเจอร์เล็กๆอันนี้?
เรารู้ว่า enhancement ไม่จำเป็นต้อง lead to direct benefit ฟีเจอร์ทิปเป็นตัวอย่างที่ดีมากๆจากการศึกษา user behavior แล้วนำมาปรับให้เข้ากับสภาพแวดล้อมใหม่ภายในแอป และได้รับผลลัทธ์เป็น indirect benefit
เรารู้ว่า Design ไม่ได้จบแค่หน้าต่างหน้าเดียว ในแต่ละ flow การใช้งานนั้น user รู้สึกยังไง คิดอะไร จะอยากหรือไม่อยากทำอะไร สิ่งเหล่านี้สามารถนำมาพัฒนาการออกแบบให้เกิด user experience ที่ดีที่สุดได้ และสามารถกระตุ้นให้ user take action ในสิ่งที่แอปต้องการได้เช่นเดียวกัน (ถ้าสนใจเรื่องนี้ ศึกษาเรื่อง Empathy Mapping เพิ่มได้)
จากตัวอย่างในวันนี้ เราว่า Grab ทำออกมาได้ดีทีเดียว : )
