อาทิตย์นี้เป็น unemployed week ของเรา เพราะมันคือแก๊ปว่างงานก่อนเริ่มงานใหม่ ไหนๆก็ไหนๆแล้ว มาอัพบลอคเล่าในสิ่งที่เล่าได้แอบลำบากในช่วงขณะที่เป็นมนุษย์เงินเดือนกันดีกว่า

ตามคำโปรยใต้บลอคนั่นแหละ เราลาออกจาก 2 บริษัทภายในระยะเวลา 1 ปี
และนี่คือสิ่งที่เราตกผลึกได้ 👇

ในการทำงาน ณ ที่หนึ่งๆ สำหรับเรา มันมีความสัมพันธ์อยู่ 3 ประเภท:

1. ความสัมพันธ์ระยะยาว — Company culture & structure

วัฒนธรรมและโครงสร้าง คือตัวตนที่แท้จริงของบริษัทนั้นๆ มันคือสิ่งที่ทุกคนต้องเชื่อและต้องทำเพื่อเติบโตไปพร้อมๆกับบริษัท จะ Blend-in ไปตามได้มากน้อยก็แล้วแต่บุคคล และต่อให้เราไม่ได้ทะเยอทะยานอยากเติบใหญ่หรือเป็นผู้นำใครๆ การมองสิ่งที่หัวหน้าหรือระดับเฮดๆของบ.ทำอยู่ จะช่วยให้เห็นภาพว่าการทำงานหรือคุณลักษณะนิสัยแบบไหนคือ “สิ่งที่ใช่” ของบริษัทนั้นๆ

ส่วนตัวเราเป็นคนเรื่องมากประมาณนึง สเปคบริษัทที่เลือกจะคัดมาแล้ว (แต่ก็ยังเฟล ลาออกแทบทุกปีอยู่ดี 😶) สเปคคร่าวๆคือต้องเป็นบริษัทอินเตอร์ประมาณนึง ไม่ seniority จ๋า ไม่การเมืองหนัก ไม่เห็นค่าความอยู่นานมากกว่าความสามารถ ไม่บูชาการทำงานหนักว่าเป็นความทุ่มเท see employee as a person and treat us well ไม่เอาอารมณ์เฮดๆเป็นใหญ่ในการตัดสินใจ มีระบบระเบียบให้เป็นแก่นไว้ยึดเหนี่ยวแต่ก็ไม่ strict เกินไปจนขยับตัวไปไหนไม่ได้ ฯลฯ

…แต่ก็ว่าแหละนะ การสัมภาษณ์ไม่กี่ครั้งไม่สามารถช่วยให้เราเห็นทุกอย่างของบริษัท จนเราเข้าไปผจญภัยเองนั่นแหละ

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

สองบ.ที่ผ่านมาเรารู้ตัวว่า Company’s culture ไม่แมทช์ เลยแอบ question กับบ.ไปบ้าง (ซึ่งเรา reflect กับหัวหน้าตลอด หาทางแก้ไขไปด้วยกันตลอด) แต่ตัวเร่งปฏิกิริยาในการยื่นใบลาออกจริงๆมันคือข้อถัดไป

2. ความสัมพันธ์ระยะกลาง — Work content

เราเป็นมนุษย์เงินเดือน งานหลักของเราคือการทำงาน เพราะงั้นเนื้อหาของงานจะเป็นสิ่งที่ติดพันกับเราที่สุด เป็นสิ่งที่เราต้องเจอมันทุกวัน และมันจะเกี่ยวพันกับเราไปจนถึงอนาคตอันใกล้ อย่างน้อยในระยะ 1 ปี+- เราก็ต้องใช้ชีวิตการทำงานส่วนใหญ่ไปกับเนื้องานนั้นๆ

สำหรับเรา Red flag ที่รุนแรงมากๆคือเมื่อเราเริ่มถามตัวเองบ่อยๆในแต่ละวัน ว่าเรากำลังทำอะไรอยู่ เราได้อะไรจากงานตรงนี้ และ/หรือ เรา contribute อะไรให้กับงานตรงนี้ ถ้าเราถามตัวเองซ้ำๆ คำตอบไม่น่าพอใจซ้ำๆ ผนวกกับความไม่ตรงจริตในข้อแรก ปลายทางคือการลาออกแน่นอน ถ้าไม่ชอบเนื้องาน ทนซักปีก็อาจจะยังพอ rotate ไปตำแหน่งอื่นได้ แต่ถ้าไม่ชอบ Company’s culture & structure ด้วยก็ไม่รู้จะฝืนอยู่ต่อไปในระยะยาวที่ไม่น่าพึงใจไปทำไมเหมือนกัน

เอาจริงเคยคุยเรื่องนี้กับแฟน ต่อให้เรามี valid reason ในการลาออกแต่ละที่ การเปลี่ยนงานมา 4–5 ที่ก็ชวนทำให้ recruiter กังวลเหมือนกัน เพราะเหตุผลลาออกมันก็คลาสสิค ทำไมคนอื่นทนได้แต่เราทนไม่ได้?

…แต่ก็อีกนั่นแหละ ทุกครั้งที่เราเปลี่ยนบริษัท เปลี่ยนสายงาน มันก็มีที่ๆพร้อมจะต้อนรับเราอยู่ เลยยังไม่เคยได้ลองทนให้ถึง 2 ปีซักที ;w;

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

3. ความสัมพันธ์ระยะสั้น — People

ส่งท้ายด้วยสิ่งที่เราไม่เคยพบเจอว่าเป็นปัญหา แต่ก็ไม่ได้แข็งแรงมากพอจะยื้อให้เราอยู่ต่อ 😂 คือบุคคลากรในบริษัทนั้นๆ aka เพื่อนร่วมงาน ผู้คนรอบตัว

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

2 บริษัทที่ผ่านมาเราโชคดี เจอแต่คนดีๆ เพื่อนร่วมทีมที่น่ารัก stakeholders ที่ทำงานด้วยง่าย (อาจจะมีอยากหยุมหัวบ้างเวลางาน conflict แต่จบงานแล้วก็จบกัน ไม่เอามาปน) หรือแม้กระทั่งคนเดินผ่านมาผ่านไป รู้จักกัน คุยเล่นกัน แต่ไม่ได้ทำงานโดยตรงด้วยกันก็ยังเฟรนลี่ หัวหน้าที่เราเจอทุกคนใจดี รับฟังความคิดเห็นตรงๆของเรา (and never take it personally //กราบ) พร้อมจะยื่นมือเข้าช่วยเหลือเราเสมอ เราสบายใจมากๆที่มีทุกคนรอบข้าง ช่วยให้เราผ่านแต่ละวันไปได้อย่างไม่โหดร้ายเกินไป แต่ก็อย่างที่บอกไป ต่อให้ทีมดีแค่ไหน เนื้องานไม่ตอบโจทย์ วัฒนธรรมที่ไม่ถูกจริต ปัญหามันก็จะยังคงค้างคาอยู่ต่อไป แล้วสุดท้ายเราก็ลาออกอยู่ดี

เพราะมิตรภาพจะยังคงอยู่ต่อไป ไม่ว่าเราจะย้ายไปที่ไหนก็ตาม :)

ส่งท้ายนิดนึง ถ้าใครตามบลอคเราคงจะพอรู้เรื่องที่เราเป็น Career path explorer มาโดยตลอด ที่ทำงานใหม่ที่ล่าสุดที่กำลังจะเริ่มงานก็ยังถือว่าเป็นการเปลี่ยนสายอยู่ดี เราเปลี่ยนสายแทบทุกครั้งที่เปลี่ยนงานแหละ ด้วยวัย 30 กับการสัมภาษณ์ครั้งล่าสุด เราเองก็พอ sense ได้ว่าเริ่มใกล้หมดเวลากับการ explore สายงานแล้ว (เพราะเราก็เปลี่ยนสายมาแทบจะทุกสายที่เกี่ยวข้องกับ Product team แล้วแหละ…) ขนาด Analyst, QA ที่ไม่เค๊ยยยยยคิดที่จะเป็นก็เป็นมาหมดแล้ว 😂 เหลือแค่ PO/PM ที่ชั่วโมงบินยังไม่สูงพอแล้วแหละนะ

แค่อยากแชร์ว่า เราก็ยังแฮปปี้กับการเปลี่ยนสายไปเรื่อยๆนะ หลายๆอย่างเราไม่มีวันรู้ถ้าเราไม่ได้เอาตัวเองไปลงมือทำจริงๆ แล้วทุกสกิลที่ติดมือกลับมาจากแต่ละสายงาน เราเอามันไปใช้ประโยชน์ได้เสมอ แล้วเราก็รู้สึกว่า ต่อให้สกิลที่เรามีจะ niche แค่ไหน สุดท้ายมันจะก็ยังมีที่ๆต้องการเราในแบบนั้นอยู่ดี (การันตีด้วยการเปลี่ยนสายงานสำเร็จเสมอนั่นแล~)

แค่เราต้องกล้า.. และหามันให้เจอ ;)

สำหรับใครที่ยังไม่รู้.. เราเปลี่ยนสายงานอีกแล้วค่ะ 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 สร้างฟีเจอร์นี้แล้ว วิธีการที่เค้าออกแบบการใช้งานก็น่าสนใจเช่นเดียวกัน ส่วนตัวเราว่าเค้าออกแบบมาได้ดีและไหลลื่นมากๆ

มาค่ะ เดี๋ยวพาไปดู

1. 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 ทำออกมาได้ดีทีเดียว : )

เมื่อวันศุกร์ที่ผ่านมา เราได้จัด Sharing session ผ่านทาง Design Community ซึ่งเป็นหนึ่งใน local activity ภายในบริษัท ก็เลยว่าจะมา recap เก็บไว้เป็นที่ระลึกในบลอคนี้หน่อย

เกริ่นคร่าวๆเรื่องที่มาที่ไป EMIT คือ บริษัท IT ในเครือ ExxonMobil (รายละเอียดไปดูต่อในเพจ EMIT Stories) ซึ่งเราจะมีสิ่งที่เรียกว่า Track acitivites คล้ายๆกิจกรรมชมรมมากมายตามความสนใจ เราอยู่ใน Design Community มาตลอด เพราะเป็นกลุ่มที่สนใจเรื่อง Design ต่างๆ ก็จะมีจัดกิจกรรม จัด session ตามความสนใจ ซึ่ง Track เราจะมีสิ่งที่เรียกว่า Design Jam เป็น Free style session ที่อยากจะมีแชร์อะไรได้ เล่าอะไรก็ได้ หรือทำ workshop ขอความเห็นหรือ brainstorm อะไรก็ได้เช่นกัน

ส่วนตัวเราเพิ่งอ่านหนังสือเรื่อง “Livable Japan - ใส่ใจไว้ในเมือง” จบ รู้สึกว่ามันน่าสนใจดี ประกอบกับเคยไปเก็บประสบการณ์แนวๆนี้มาตอนเรียนโทที่ญี่ปุ่น ก็เลยอยากเอามาเล่าให้ทุกคนฟังกัน รวมถึงคนอ่านบลอคนี้ด้วย (ถ้ายังมีอะนะ lol)

งั้นมาลองดูกันดีกว่า ว่านอกจากหน้าจอมือถือและคอมพิวเตอร์แล้ว UX สามารถทำอะไรได้อีก~

Design shape user’s behavior

ถ้าพูดถึง Design ไม่ว่า UX หรือ UI สิ่งที่คนจะคิดถึงอันดับแรกๆก็อาจจะเป็น ความสวยงาม user flow ที่ไหลลื่น ใช้งานง่าย เพื่อประสบการณ์ที่ดีของ user แต่จริงๆแล้ว Design นั้นทรงพลังกว่านั้น มันสามารถชักจูง user ให้ทำในสิ่งที่ product/service นั้นๆต้องการได้ ยกตัวอย่างง่ายๆคือแอปซื้อของทั่วไป ปุ่ม “สั่งซื้อ” มักจะโดดเด่น เห็นง่าย ตำแหน่งก็จะพอดี๊พอดี เชื้อเชิญให้ user กดซื้อสินค้าซักที ประมาณนั้น

แล้วถ้าเป็น UX นอกหน้าจอล่ะ?

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

แล้วถ้าเป็น scale ที่ซับซ้อนกว่านั้นล่ะ? ยกตัวอย่างสถานีรถไฟ ที่เป็นตัวเลือกการเดินทางหลักๆของชาวญี่ปุ่น เป็นที่โจษจันกันว่าช่วงเวลา rush hour สถานีรถไฟก็คือปลากระป๋องดีๆนั่นเอง สำหรับเราแล้วในบรรดา user flow การเดินทางด้วยรถไฟ คนจะหนาแน่นและติดคอขวดกันเยอะที่สุดก็คือตรง Ticket gate ที่เป็นการติ๊ดเข้าระบบรถไฟ แล้วญี่ปุ่น Design อะไรบ้างเพื่อให้ user เดินทางผ่านจุดนี้ไปได้เร็วที่สุด?

1. ประตูลักษณะยาว เดินต่อไม่สะดุด
   ถ้าลองวัดระยะทางจากตอน user มาถึง Ticket gate จนกระทั่งเดินผ่านเข้าไปในสถานี จะสังเกตได้ว่าระยะทางจะค่อนข้างยาวประมาณ 2–4 ก้าวเท้าเดิน เพื่อให้ user สามารถเคลื่อนที่ไปข้างหน้าระหว่างที่ ticket gate กำลังอ่านตั๋วก่อนจะคืนให้ user ที่ทางออกประตู ถ้าระยะทางสั้นกว่านั้น user อาจจะต้องหยุดยืนรอตั๋วกลับมาจนทำให้กระทบกับ flow การระบายคนได้
2. เครื่องอ่านตั๋วกระดาษทุกทิศทาง คืนตั๋วหน้าตรงเสมอ
   ถ้าคุณไม่ใช่คนที่เดินทางเป็นประจำ คุณอาจจะไม่มีบัตร IC Card (บัตรเติมเงินที่ใช้ในสถานีรถไฟ) คุณก็จะต้องไปกดซื้อตั๋วกระดาษเป็นตั๋วเดินทางครั้งเดียว ซึ่งที่ญี่ปุ่นจะเป็นกระดาษแผ่นเล็กๆ พิมพ์ข้อความอยู่ด้านบนด้านเดียว โดยที่เครื่องอ่านตั๋วของญี่ปุ่นเนี่ย จะถูกออกแบบมาให้สามารถอ่านตั๋วกระดาษดังกล่าวได้ทุกทิศทาง จะใส่ไปตรงๆตามหน้าตั๋วที่พิมออกมา หรือจะหันตูดเข้า หรือแม้กระทั่งคว่ำหน้าเอาด้านกระดาษที่ว่างเปล่าขึ้นก็ย่อมได้ การที่ Design เครื่องออกมาแบบนี้ทำให้ user ไม่ต้องเสียเวลาพลิกตั๋วไปมาเพื่อหาด้านที่ถูก ใส่ๆไปได้เลย แต่พอตอนเครื่องคืนตั๋วออกมาให้ จะคืนด้านหน้าตั๋วที่ถูกต้องสวยงามให้เสมอนะ
3. ที่แตะบัตรทำมุม 13.5 องศา แตะได้แม่นยำ
   สำหรับคนที่ใช้บัตร IC Card ก็ไม่ต้องน้อยหน้าไป แท่นอ่านบัตรของที่ญี่ปุ่นเองก็ผ่านการศึกษาวิจัยจนการันตีแล้วว่า ที่แตะบัตรทำเป็นเนินชัน 13.5 องศานั้นเป็นองศาที่ง่ายที่สุดที่จะแตะบัตรได้ถูกต้อง ไม่ชันเกินไปจนบัตรร่วงลงมา และไม่ราบเกินไปจน user ต้องใช้ความพยายามในการหยิบบัตรกลับคืน
4. ประตูเปิดโล่ง ผู้ใช้งานไม่ต้องหยุดรอ
   อันนี้จะต่างกับที่ไทย จะเห็นว่าที่ไทย Default คือประตูปิด พอแตะบัตรผ่าน ประตูจึงจะเปิดให้ user เดินผ่านไปได้ แปลว่าในการเดินผ่านประตูแต่ละครั้ง จะมีคนที่แตะบัตร ยืนรอ พอเห็นประตูเปิดแล้วค่อยเดินเข้าไป กลับกัน ฝั่งญี่ปุ่นเค้าก็ศึกษามาแล้วว่า user ส่วนใหญ่จะมีตั๋วหรือบัตรที่ถูกต้อง ทำให้ผ่านประตูไปได้โดยสวัสดิภาพ และเมื่ออิงจากฐานลูกค้าดังกล่าว การ Default ประตูเปิดก็จะช่วยลดเวลา delay ที่ user จะต้องหยุดรอดูประตูเปิด รวมไปถึงส่งผลทางด้านจิตวิทยาทำให้ user มีแนวโน้มที่จะเดินตรงไปโดยไม่หยุดพักมากกว่า

จาก 4 ตัวอย่างที่อธิบายไป จะเห็นว่าแต่ละข้อล้วนเป็นเพียงรายละเอียดเล็กๆน้อยๆ อาจจะช่วยลดเวลาโดยรวมของ user flow ไปได้ไม่มาก แต่ก็เราลองเอาหลายๆข้อมารวมกัน คูณด้วย user ปริมาณมหาศาลที่เป็นโจทย์หลักเริ่มแรก มันก็เป็นปริมาณเวลาที่สามารถสร้าง impact ให้กับทางสถานีรถไฟได้เหมือนกันนะ!

มาลองดูอีกหนึ่งตัวอย่างที่โดดเด่นของญี่ปุ่น เรื่องของการแยกขยะ

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

อีกหนึ่งเคสที่ประทับใจคือที่ทิ้งขยะตามร้าน Fast food เช่น McDonald’s หรือ KFC ถังขยะแบบรูปด้านขวาก็ถูกออกแบบมาอย่างดี มี flow ที่ไหลลื่นตามข้างล่าง:

1. วางถาดไว้ที่ด้านบน ตรงที่วางถาด หยิบแก้วน้ำไปข้อต่อไป
2. เปิดฝา เทน้ำและน้ำแข็งลงช่องสีเงินที่ร้านเตรียมเอาไว้ ลดความเลอะเทอะที่จะเกิดขึ้นในถุงขยะรวม
3. หลอดและฝาปิดแก้วมักจะเป็นพลาสติก เราโยนทิ้งในช่องล่างขวา (พลาสติก) ได้เลย ถ้าแก้วเป็นกระดาษ เราจะวางบนถาดที่เบอร์ 1 เหมือนเดิม
4. หยิบทั้งถาด (ที่ควรจะเหลือแค่ขยะเผาได้ เช่น กระดาษรอง เปลือกเบอร์เกอร์) จิ้มลงไปที่ฝาฝั่งล่างซ้าย (ขยะเผาได้) ช่องทิ้งขยะที่ออกแบบให้กว้างพอจะเปิดรับทั้งถาดได้ด้วยการจิ้มได้อย่างง่ายดาย เราก็แค่เขย่าๆจนขยะทั้งหมดตกลงไปในถัง จากนั้นจึงวางถาดกลับไปบนเบอร์ 1

ปล.ถ้ามือเปื้อน จะมีกล่องทิชชู่วางอยู่ข้างๆเบอร์ 2 ให้หยิบใช้แล้วทิ้งต่อได้เลย

จบ ง่าย สบายมากๆ

ส่วนตัวเรารู้สึกว่า user flow ที่เรียบง่ายและไหลลื่นทำให้เราเต็มใจที่จะทิ้งขยะตามที่ทางร้านจัดเตรียมไว้ได้มากขึ้น เหมือนกฏ 20 วิที่เคยได้ยินมา ว่าถ้าอะไรใช้ effort มากกว่า 20 วินาที มนุษย์มีแนวโน้มที่จะล้มเลิกการกระทำนั้นๆได้ง่าย

Design for better life

นอกจากการปรับเปลี่ยนพฤติกรรมผู้ใช้งานแล้ว Design เองก็ยังมีบทบาทสำคัญในการพัฒนาคุณภาพชีวิตของ user ได้อีกด้วย ยกตัวอย่างง่ายๆ เช่น ซองขนมที่มีรอยบากเล็กๆเพื่อให้ user ฉีกทานได้ทันที หรือ Twitter night mode ที่ทำให้เราไถทวิตก่อนนอนยาวๆได้โดยไม่แสบตาจนเกินไป

แต่ตัวอย่างที่ญี่ปุ่นจะเป็น case scenario ที่ยิ่งใหญ่กว่านั้นเยอะเลย ;)

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

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

ไหนมาลองทายเล่นๆดีกว่าว่าในรูปตัวอย่างข้างล่าง มีอะไรบ้างที่ออกแบบมาเพื่อช่วยเหลือผู้คนเหล่านั้น?

ถ้าอ้างอิงจากข้อมูลในหนังสือ จะมีจุดเล็กจุดน้อยอยู่ตามนี้:

1. สัญญาณไฟคนเดิน พร้อมเสียง
   สัญญาณไฟที่ทุกคนน่าจะพอเดากันได้ ตัวช่วยหลักๆในการแบ่งแยกระหว่างเวลารถผ่านกับเวลาคนผ่าน แต่เคยสังเกตกันมั๊ยว่าสัญญาณไฟที่ญี่ปุ่นจะมีเสียงนกร้องประกอบ แถมมีหลายเสียงด้วยนะ เสียง Piyo-Piyo จะบอกทางม้าลายที่ข้ามไปมาระหว่างทิศเหนือและทิศใต้ ส่วนเสียง Kukkoo จะบอกทางม้าลายที่ข้ามไปมาระหว่างทิศตะวันออกและทิศตะวันตก ทั้งสองเสียงเลียนแบบมาจาเสียงนกที่บินตามทิศนั้นๆ และแน่นอน จุดประสงค์หลักก็เพื่อบอกทางให้กับผู้พิการทางสายตา
2. เส้นหยุดก่อนทางม้าลาย
   อันนี้ก็ตรงตัว เรียบง่าย แบ่งเขตชัดเจนระหว่างส่วนของรถ และ ส่วนของคน ทำให้รถไม่ทับพื้นที่ทางม้าลาย รวมถึงสามารถดำเนินการทางกฏหมายหากฝ่าฝืน
3. ทางม้าลาย
   ก็ตรงตัวตามนั้นแหละ เส้นทางสำหรับคนข้ามถนนโดยเฉพาะ เส้นต้องชัด โดดเด่น มองเห็นง่าย รวมถึงต้องมีความกว้างมากพอให้คนเดินสวนกัน จากในรูปตัวอย่าง ทางม้าลายอาจจะดูขนาดธรรมดาเพราะมันเป็นแค่ซอยเล็กๆ แต่ถ้าไปดูตัวอย่างสถานีใหญ่ๆที่คนเยอะๆเช่น ชิบูย่า ชินจุกุ จะเห็นว่าความกว้างของทางม้าลายเค้าพอๆกับถนน 2–3 เลย เพราะปริมาณคนที่เดินสัญจรไปมานั้นมีจำนวนมหาศาลนั่นเอง
4. ทางลาด 5–9%
   เรื่องทางลาด ทุกคนคงพอเดากันได้ แต่ญี่ปุ่นดีเทลยิ่งกว่าที่เค้าเจาะจงสเปความชัน 5–9% ซึ่งเป็นความชันที่รถเข็นวีลแชร์สามารถเข็นข้ามไปได้ด้วยตัวเอง
5. ขอบทางเท้าสูง 2 ซม.
   เรามีทางลาดเพื่อวีลแชร์แล้ว เราก็ย่อมต้องมีทางเท้าเพื่อผู้พิการทางสายตา ขอบทางเท้าสูง 2 ซม.นี้เป็นความสูงพอดีที่ผู้พิการทางสายตาสามารถแยกแยะระหว่างถนนและทางเท้า ในขณะเดียวกันมันก็ไม่ได้สูงเกินไปจนไม่สามารถเข็ยรถเข็นหรือวีลแชร์ข้ามมันไปได้
6. ถนนรูพรุน
   เกริ่นก่อนว่า ในอดีต การแก้ไขปัญหาฝนตกน้ำท่วมของญี่ปุ่นคือการออกแบบพื้นถนนให้ลาดเอียงนิดๆ เพื่อที่น้ำฝนจะไหลกางไปริมถนนเพื่อรอการระบายลงท่อ แต่ solution นี้ยังไม่สมบูรณ์แบบนัก เพราะพื้นถนนที่ลาดเอียงอาจส่งผลเสียกับเครื่องยนต์ แถมน้ำขังริมทางเท้าก็ยังเกิด super splash ใส่คนเดินถนนได้อีก จนกระทั่งนวัตกรรมล้ำเลิศของถนนรูพรุนได้เกิดขึ้น ถนนรูพรุนคือยางมะตอยชนิดพิเศษที่ทำหน้าที่เหมือนฟองน้ำ เมื่อฝนตก น้ำฝนจะทะลุผ่านรูเล็กๆๆๆของถนนลงไปยังท่อระบายน้ำด้านล่างได้ทันที ไม่มีน้ำขังจนสาดโดนคนได้อีกแล้ว แถมยังมีประโยชน์ทางอ้อมในการดูดซับเสียงเครื่องยนต์ได้อีกด้วย
7. บล็อกนำทางผู้พิการทางสายตา
   อันนี่ไม่มีในรูป แต่เป็นอีก 1 common things in Japan บลอคทางเดินยาวๆสีเหลืองๆที่เราเห็นได้ทั่วไปทั้งในและนอกอาคารของญี่ปุ่น ที่เป็นอุปสรรคมากๆเวลาลากกระเป๋าเดินทางข้ามเส้นนั่นแหละ ที่ไทยก็อาจจะพบเห็นได้ประปราย แม้จะทางขาดบ้าง เดินชนเสาบ้าง แต่ที่ญี่ปุ่นเรารับรองว่าคุณสามารถเดินตามทางนั้นไปได้ทุกที่โดยสวัสดิภาพ :)

อะ นี่แค่เรื่องทางเท้านะ สเกลที่ใหญ่กว่านี้ พีคกว่านี้มีอีกมั๊ย?

ในหนังสือยังพูดถึง TOD (Transit-Oriented Development) ซึ่งเป็นการพัฒนาพื้นที่รอบสถานีรถไฟ คือไม่ได้เริ่มจากการที่มีเมืองแล้วขนส่งค่อยตามมา แต่เป็นการออกแบบและวางแผนให้ขนส่งมวลชนเติบโตควบคู่ไปกับเมือง เน้นการใช้พื้นที่ให้คุ้มค่า เกิดมูลค่าทางเศรษฐกิจ มีความหลากหลายและหนาแน่น รวมไปถึงการส่งเสริมการใช้ขนส่งสาธารณะอีกด้วย

ตัวอย่างรูปด้านบนคือสถานีโตเกียว ซึ่งภายในและรอบๆสถานีสามารถแบ่งได้เป็น 3 ส่วนใหญ่ๆ

1. Transportation
   แหม ก็บอกอยู่ว่าเป็นสถานีรถไฟ สถานีโตเกียวเป็นอีกหนึ่งสถานศูนย์กลางการเชื่อมต่อ มีรถไฟหลายสิบสาย ชานชาลากว่า 20 ชานชาลาอยู่ภายใต้ตึกสวยๆ และเพราะขนาดของสถานีที่ใหญ่มหาศาล เราจึงยังจะมีโครงข่ายทางเดินใต้ดินให้ประชาชนสามารถสัญจรไปมาได้โดยง่าย แบบไม่ต้องติ๊ดบัตรเข้าระบบให้เสียเงิน นอกจากนี้ รอบๆสถานีรถไฟก็ยังมี Hub ศูนย์กลางรถบัสเป็นตัวเลือกการเดินทางสาธารณะอีกทางเลือกนึง
2. Commercial
   อย่างที่บอกไปว่า TOD เน้นการสร้างศูนย์กลางทางเศรษฐกิจ สถานีโตเกียวจึงมีสถานที่ทำการค้าทุกอย่างเท่าที่จะนึกได้ บนตึกเป็นโรงแรมห้าดาว ใต้ตึกและรอบๆมีห้างสรรพสินค้ามากมาย รวมไปถึงแหล่งท่องเที่ยวซื้อของฝากที่โดดเด่นอย่าง Character street หรือ Ramen street ที่อยู่ในโครงข่ายทางเดินใต้ดิน ส่วนรอบๆสถานีก็มีตึกสูงระฟ้ามากมายเป็นที่ตั้งของบริษัทชั้นนำต่างๆ พนักงานสามารถเดินทางมาทำงานได้อย่างสะดวก ส่วนตัวบริษัทเองก็ไม่ต้องเผื่อพื้นที่สร้างลานจอดรถไว้รองรับพนักงานจำนวนมหาศาลเหล่านั้น
3. Lifestyle
   แน่นอน สถานีโตเกียวไม่ได้ถูกออกแบบมาเพียงเพื่อมูลค่าทางเศรษฐกิจ ประชาชนเองก็สามารถใช้ประโยชน์/พักผ่อนหย่อนใจได้ที่นี่เช่นกัน ลานกว้างหน้าสถานีโตเกียวสามารถจัดกิจกรรมต่างๆใด ที่เห็นทุกปีคือช่วงฤดูหนาวที่มีการจัดโชว์แสงไฟ illumination สวยๆ ด้านบนสถานีและรอบๆก็มีทั้งแกลอรี่ศิลปะและพิพิธภัณฑ์ของตัวสถานีเอง หรือถ้าเดินออกจากสถานีตรงไปอีกซักพักก็จะเจอ Imperial Palace พระบรามหาราชวัง ที่เป็นทั้งแหล่งท่องเที่ยวและสวนพักผ่อนหย่อนใจขนาดใหญ่

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

เนื้อหาเยอะเนอะ 5555+ แต่ทั้งหมดที่กล่าวมีเป็นแค่ตัวอย่างเล็กๆน้อยๆในหนังสือ Livable Japan — ใส่ใจไว้ในเมือง เท่านั้น ในหนังสือจริงๆยังมีเคสที่น่าสนใจอีกมาก ใครสนใจกดลิงค์ที่ชื่อหนังสือแล้วตามไปตำได้เลย~ คุ้มมากกกกกจริงจัง

ปิดท้ายด้วยอีกหนึ่งหัวข้อเบาสมอง Disclaimer ไว้ก่อนว่าเป็นประสบการณ์ส่วนตัวที่เราได้ยินและได้พบเจอมาตอนเรียนโทที่ญี่ปุ่น ปี 2016–2018 ข้อมูลไม่ได้มีแหล่งที่มาที่เป็นทางการและเชื่อถือได้ และอาจจะ outdated ไปบ้าง โปรดใช้วิจารณญาณในการรับชม

Design as a service

ตัดอารมณ์ด้วยเรื่อง Casual เบาสบายๆ สมมติคุณทำงานเห็นพนักงานร้านซูชิหมุน เรา ผู้หญิงวัยเกือบสามสิบผู้หิวโซเดินเข้าร้านมาอยากกินซูชิจัดๆ คุณจะพาเราไปนั่งตรงไหน? (กรุณามอง icon คนกลมๆเป็นลูกค้าที่นั่งโต๊ะอยู่)

จดคำตอบเก็บไว้ในใจ แล้วมาฟังเราเม้ามอยอะไรให้ฟังซัก 2 เรื่อง -w-

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

เรื่องสอง เพื่อนเราเคยสงสัยว่าทำไมร้านโอโตยะ (อาหารฝีมือแม่แบรนด์เดียวกับที่ไทยอะแหละ) ที่ญี่ปุ่นมันมักจะหลบอยู่ชั้นสองบ้าง ใต้ดินบ้าง (ถ้าไม่นับร้านในห้างอะนะ) อย่างรูป screenshot ด้านบน จะเห็นว่ารูปร้านส่วนใหญ่จะมีแค่ป้ายสีน้ำเงินเด่นๆที่ยื่นออกมาเท่านั้น ทางเข้าร้านอยู่ในไปหาต่อเอาเอง 555+
พอคุยกันไปกันมาถึงได้รู้เหตุผลเบื้องหลัง แรกสุดเลย target customer ของโอโตยะจะเป็นผู้หญิง สังเกตได้จากเมนูอาหารสุขภาพ มีเลขบอกแคลอรี่ในเมนู มีตัวเลือกข้าวธัญพืช ฯลฯ แล้วพอ target หลักเป็นผู้หญิงเนี่ย เค้าก็คิดเผื่อผู้หญิงญี่ปุ่นไปอีก 1 step กลายเป็นว่า ถ้าหน้าร้านอยู่ริมถนน มันมีสิทธิที่คนที่เดินสัญจรไปมาสามารถมองเข้ามาจากข้างนอกแล้วเห็นได้ว่าคุณผู้หญิงในร้านทั้งหลายกำลังกินอะไร กินยังไง กินเยอะน้อยแค่ไหน ซึ่งมันผิดวิถีสตรีญี่ปุ่นจริงๆแกรร โอโตยะเลยมักจะตั้งทำเลร้านตัวเองในชั้นอื่นๆเพื่อสร้างมุมส่วนตัวที่เพิ่มขึ้นให้กับ user ของทางร้านนั่นเอง

เอาล่ะ ไหนลองกลับมาดูรูปร้านซูชิร้านแรกหน่อย

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

คุณตอบคำตอบเดิมมั๊ย?

.

.

.

ตอนที่เราพูดใน session (ทั้งรอบซ้อมละรอบจริง) trend ของคำตอบตอนก่อนกับหลังฟังเรื่องเล่าของเรานั้นไม่เหมือนกันเลย

ทั้งๆที่ setting ก็เหมือนเดิม ร้านเดิม คนนั่งเหมือนเรา เราเป็น user คนเดิม

แต่พอทุกคนเริ่มรู้จัก story เริ่มรู้จัก insight แล้ว input ที่เหมือนเดิมก็สามารถส่งผลให้เกิด output ที่เปลี่ยนไป

สำหรับเรา..นั่นคือ Magic of UX :)

เฉลย: จากประสบการณ์การกินซูชิคนเดียวใน 2 ปีที่ผ่านมา เรามักจะได้นั่งตรงนี้:

เอาจริงมันก็ขึ้นอยู่กับที่นั่ง ณ เวลานั้นๆแหละ แต่ถ้ามี counter bar ที่ค่อนข้างว่าง (ซึ่งเค้ามักจะจัดคนที่มาคนเดียวไปนั่งตรงนั้นแหละ utilize space ให้คุ้มที่สุด) เค้าจะจัดเราไปซอกหลืบที่ห่างคนให้มากที่สุด ส่วนลูกค้าเดี่ยวคนอื่นๆที่ส่วนใหญ่จะเป็นมนุษย์ลุงออฟฟิศ จะถูกเติมจาก counter bar ฝั่งที่มีคนนั่งอยู่แล้ว ไหลมาเรื่อยๆจนมาถึงเรา

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

ซึ่งแปลนของร้านจะแบ่งเป็นสองส่วน หนึ่งคือโซนหลักที่มีไลน์บุฟเฟ่ต์ตรงกลาง แล้วโต๊ะที่นั่งรอบๆ สองคือโซนที่นั่งด้านหลังซึ่งเป็นอีกห้องนึงต่างหาก 3–4 ที่เราไปกินคนเดียว เราโดนพนักงานโยนไปโซนข้างหลังตลอดดด บางครั้งคือพี่แกเพิ่งเปิดแอร์โซนนั้นเลยด้วย ทั้งๆที่โต๊ะตรงกลางยังมีที่ว่างเยอะแยะอะ

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

ถ้าใครมีโอกาสไปญี่ปุ่น (เมื่อไหร่นะ…ฮึก) ก็อยากให้ทุกคนลองสังเกต pattern การเลือกที่นั่งให้ลูกค้าแต่ละประเภทของแต่ละร้านดูนะ สนุกดีทีเดียวล่ะ :)

ส่งท้าย เรื่องทั้งสามแบบที่เราเอามาแชร์ในวันนี้ เราอยากบอกให้ทุกคนรู้ว่า Design มันเป็นมากกว่าแค่ความสวยงามหรือใช้งานง่าย มันสามารถโน้มน้าวการกระทำใดๆก็ได้ สามารถพัฒนาคุณภาพชีวิตผู้ใช้งานได้ แล้วมันก็ไม่ได้มีรูปแบบตายตัวว่าจะต้องเป็น application, program, product หรือ system ใดๆ สิ่งของที่จับต้องไม่ได้อย่าง service ก็สามารถ design for better experience ได้

แล้วคนที่ drive design เหล่านั้นก็ไม่จำเป็นจะต้องเป็นแค่ Designer เท่านั้น จะเป็น Developer, Analyst, Project Manager หรือแม้กระทั่ง IT support ถ้าเรามองเห็น user ถ้าเราศึกษาเค้า ทำความเข้าใจว่าเค้าเป็นใคร เค้าต้องการอะไร เค้า “คิด” ว่าเค้าต้องการอะไร แล้วจริงๆแล้วเค้าต้องการอะไร เราก็อาจจะเจอจุดเล็กๆน้อยๆที่เราสามารถแก้ไขหรือพัฒนา จนมันเกิด the best experience ให้กับ user ของเราก็ได้เช่นกัน ✨

Happy designing everyone 😘

.

.

.

ปล. ของแถม โพสต์ตัวเองเมื่อ 4 ปีที่แล้วเรื่อง UX ในห้องน้ำญี่ปุ่น

Log In or Sign Up to View

UX นอกหน้าจอ feat. Livable Japan was originally published in EMIT Stories on Medium, where people are continuing the conversation by highlighting and responding to this story.

ตำแหน่งงานปัจจุบันของเราคือ Analyst

เนื้องานหลักๆก็คือการประสานงานไปมาระหว่าง business และ developer รวมไปถึงวิเคราะห์ requirement หรือหา root cause

ส่วนนึงของงานเราก็คือการทำ QA (Quality Assurance) ไปในตัว เพราะเราต้องทำ internal test เอง บวกกับดูแลเรื่อง deployment ต่างๆตามระบบที่บริษัทได้วางไว้

ส่วนงาน developer เป็นของแถมที่ได้มา เนื่องจาก bot ตัวที่ 2 ในแพลนนั้นมีความไม่สมดุลระหว่าง resource และ timeline เราที่เคยโค้ดมาก่อนก็เลยเข้าไปรับหน้าแทน

เป็นการทำงานที่เหมือนเราเดินวนๆที่เดิม 3 รอบด้วยมุมมองที่ต่างกันออกไปตามเลนส์ “หน้าที่” ที่สวมใส่ วันนี้ก็เลยอยากมาแชร์แต่ละมุมมองในแต่ละขั้นตอนให้ฟังกัน

⚠️ เตือนไว้ก่อน นี่เป็นแค่ประสบการณ์ส่วนตัว ในโปรเจ็คที่มีลักษณะเฉพาะเท่านั้น ถ้าโปรเจ็คอื่นที่สเกลแตกต่างจากนี้ก็จะมีรายละเอียดอื่นๆที่ไม่ตรงกันนะ

Project’s scope

โปรเจ็คนี้เป็นการสร้าง RPA (Robotic Process Automation) เพื่อให้ bot ทำงานแทนมนุษย์ในส่วนที่มีเนื้องานที่ซ้ำๆและปริมาณมาก bot จะรับข้อมูล input จาก user, ทำการตรวจสอบข้อมูลผ่าน validation criteria ต่างๆ แล้วจึงเข้า SAP ไป process transaction ตามที่ได้โปรแกรมไว้ ซึ่งทีมเราจะใช้ UiPath Orchestrator ในการพัฒนาและสั่งงาน bot

Requirement Analysis

ตอนเริ่มโปรเจ็ค เราก็ทำงานตามประสา Analyst ทั่วไป พอเรารู้ process ที่เค้าอยากจะ automate แล้ว ก็เริ่มประชุม พูดคุย เจาะลึก detailed process กับ user จริงๆ เพื่อให้เข้าใจ manual process ที่เค้าทำ ก่อนจะเริ่มตีโครงออกมาว่าจะปรับเปลี่ยนรายละเอียดต่างๆยังไงให้มันสามารถกลายเป็น automation process ได้

👶 Analyst: ควรระวังเรื่อง scope งอกเหนือ timeline ควรให้ business เตรียมข้อมูลเก่าที่เคยทำงานไว้เยอะๆเพื่อเป็นหลักฐานในการต่อรอง ถ้าเริ่มคุยลงดีเทลไปที่เคสหนึ่งเคสใดให้รีบชิงเปรียบเทียบ % ที่จะเกิดขึ้นจริงแล้วประเมินความคุ้มค่าที่จะทำร่วมกัน

👩 Dev: พยายาม involve กับขั้นแรกๆให้ได้มากที่สุด ถ้าเข้าประชุมไม่ได้ให้ catchup ข้อสรุปหรือการเปลี่ยนแปลงที่เกิดขึ้น เพราะบางอย่างที่คนอื่นรู้สึกว่ามันเป็น common logic อาจจะเป็น tool limitation ที่ทำได้ยากมากๆก็เป็นได้

👵 QA: จับตามองรายละเอียดต่างๆที่คุยกันระหว่างประชุมให้ดี ทางที่ดีคือขอตัวอย่างข้อมูลมาสำรองไว้จะทำให้เทสได้ง่ายขึ้นเยอะ

Process Planning

พอเก็บ requirement คร่าวๆมาได้แล้ว เราจะสามารถวางแผนได้ดีขึ้นว่าแต่ละส่วนจะใช้เวลาประมาณเท่าไหร่ ถึงจริงๆส่วนใหญ่ที่เจอคือ user มาพร้อมกับ timeline ในใจแล้วก็ตาม…

👶 Analyst: ทำหน้าที่เป็นคนกลางระหว่างทั้งสองฝั่ง พยายาม balance ให้ดีระหว่าง business impact และ technical constraint การวาง timeline คร่าวๆ วาง checkpoint ให้สองฝ่ายได้มาคุยกันจะทำให้ติดตามงานได้ง่าย

👩 Dev: ขั้นตอนนี้จะสามารถต่อรอง-โยกย้ายแผนการทำงานได้ง่ายที่สุดแล้ว ถ้าทำการบ้านกับ analyst มาดีพอ เราสามารถชี้แจง limitation ต่างๆแล้วตัดทอนส่วนที่ไม่สำคัญออกเพื่อให้ plan ดูสมจริงยิ่งขึ้น

👵 QA: ในการต่อรองขั้นตอนนี้ จะสามารถแยกแยะส่วนสำคัญ-ไม่สำคัญได้ การจดบันทึกจะช่วยให้เราเอาไปใช้กับการลิสต์ known issue ในภายหลัง

Process Design

เมื่อสรุป process โดยรวมแล้ว ขั้นตอนต่อไปคือการ document ออกมาเป็น step-by-step ชี้แจงขั้นตอนการทำงานของ bot โดยละเอียด ครอบคลุมทั้งสิ่งที่ bot ทำได้และทำไม่ได้ หลังจากนั้นก็ให้ Business approve เป็นหลักฐาน ขั้นตอนนี้จะทำให้เสร็จก่อนค่อย dev หรือจะทำไปพร้อมๆกันก็ได้ เพราะมันยังเป็นแค่ initial draft ในการเขียนบอทจริงๆอาจจะมีการแก้ไขปรับปรุง ซึ่งพอจบ deliver ถึงจะอัพเดท final documentation อีกที

👶 Analyst: ไม่จำเป็นต้องทำเหมือน manual process เป๊ะๆ พยายามหาทางลัดหรือการดึงข้อมูลจากหลังบ้านแทนเพื่อเพิ่มความเสถียรและลดเวลาให้กับ bot

👩 Dev: การมีความรู้ใน system ใดๆที่ bot ต้องทำงานบนนั้นจะช่วยให้ทำงานง่ายขึ้น พยายามลองหา API หรือ library ใดๆมาช่วยลดความซับซ้อนของแต่ละขั้นตอน

👵 QA: คอยสังเกตความเปลี่ยนแปลงต่างๆในการเขียนบอท การดึง API, Library ต่างๆมาใช้ย่อมมีข้อจำกัด ศึกษาและเตรียม test script รอเอาไว้ได้เลย

Implementation & Test

ต้องเขียนอะไรเยอะแยะล่ะ ทำงานค่ะทำงานนน

👶 Analyst: เตรียม test data ของแต่ละเคส รวมถึงประสานงานกับฝั่ง business เพื่อเตรียมข้อมูลจริงในการทำ UAT รวมถึงการเจาะหาเคสที่เป็น business scenario ซึ่งฝั่ง IT อาจจะไม่ได้รู้มาก่อน

👩 Dev: เขียนโค้ด จบ 5555555+
หลอกๆ ทักษาเฉพาะตัวเราว่าไม่ต้องพูด แต่จะเพิ่มเรื่องการอัพเดท analyst เวลามีการเปลี่ยนแปลงใดๆเพื่อวิเคราะห์ผลกระทบร่วมกัน แล้วถ้าเจอเคสหรือ limitation อะไรพิเศษก็ให้ QA ลิสต์เก็บไว้เทสภายหลังเพื่อความแน่นอน

👵 QA: ลิสต์ความเป็นไปได้ต่างๆ ทั้งการทำ data validation, การใช้ API/Library, business scenario ที่เกิดขึ้นได้ ทำงานควบคู่กับ Analyst เพื่อที่จะลดทอนเคสที่ไม่เกิดขึ้นจริงลงไป ทำงานร่วมกับ dev ในการทำ test ไปจนถึงการ list known issues หากการแก้ไขเป็นไปได้ยากหรือดูไม่คุ้ม effort เพื่อนำไปคุยในขั้นตอนถัดไป

UAT & Deploy

เมื่อผ่านการตรวจสอบคุณภาพจากฝั่ง IT แล้ว ก็จะต้องกลับไปหา user และทำ UAT (User Acceptance Test) เพื่อเป็นการ confirm final product รวมไปถึง final document ที่จะสรุปรวบยอดทุกอย่างและทำการ business approve เป็นหลักฐาน เมื่อทุกอย่างลงตัวสมบูรณ์แล้ว ก็ deploy ขึ้นระบบจริงแล้วเตรียมใช้งานกันได้เลย

👶 Analyst: คล้ายๆขั้นตอน planning ถ้าเราขลุกอยู่กับ Dev และ QA มากพอ เราก็จะเข้าใจ limitation ต่างๆ และสามารถนำมา balance กับ business impact เพื่อพิจารณาการแก้ไขและผลกระทบกับ timeline ต่อไปได้

👩 Dev: ช่วงเวลาการส่องประกายของผลงาน อาจจะมีช่วยประเมินเวลาที่จะต้องใช้ในการแก้ไขสิ่งใดๆตามที่ business ขอมาบ้าง เมื่อทุกอย่างผ่านแล้วก็ทำการ deploy ได้เลย เนื่องจากเราใช้ orchestrator ในการทำงาน การ deploy ก็เลยใช้ตาม service ที่เค้ามีให้ได้เลย

👵 QA: Known issues ที่ลิสต์เอาไว้จะมีประโยชน์มากๆ ทีมจะเห็นแล้วว่าในเวลาที่เหลืออยู่ มีอะไรบ้างที่อยากแก้หรืออะไรที่ยังไม่ต้องแก้ตอนนี้ก็ได้ ลิสต์จะเก็บไว้เป็นทั้งยันต์ป้องกันภัยในอนาคต แล้วก็อาจจะเป็น to-do list ในการ planning ครั้งต่อไปด้วยเช่นกัน

และนั่นก็คือการทำงานคร่าวๆของ RPA Project ที่เราทำมาตลอดครึ่งปีที่ผ่านมา จะเห็นว่าตัวฝั่ง technical เองจะไม่ซับซ้อนอะไรมาก ที่ยุ่งยากจะเป็นการ simplify process ให้เป็นมาตรฐานสำหรับ bot กับการติดต่อประสานงานไปมาซะมากกว่า ส่วนตัวรู้สึกว่าถ้าแบ่งงานกันดีๆ ทำงานไปด้วยกันเป็นทีมก็น่าจะแข็งแกร่งอยู่พอตัว

แต่พอรวมทุก roles มาอยู่ในคนเดียว ความอ่อนล้าที่ต้องทั้งประสานงานไปมา ทั้งคิดหา solution ดีๆเพื่อความเสถียร ไม่รวมถึง learning curve ที่เจอ ก็ทำให้หนักหนาสาหัสอยู่เอาเรื่อง แต่ส่วนที่หนักมากๆสำหรับเราจริงๆก็คือการที่ต้องคิดเองทำเองเทสเองนั่นแหละ เราไม่มี second opinion หรือ outside viewpoint มาช่วยจี้จุด ช่วง UAT เลยค่อนข้างยือเยื้อเพราะต้องให้ฝั่ง user แจงเคสแปลกๆที่ไม่เคยเจอมาให้แทน Analyst หรือ QA

ก็ถือว่าเป็นอีก challenge ที่ดีที่ทำให้เรามองเห็นภาพรวมมากขึ้นนะ

แต่ถ้าให้แนะนำ…ก็ไม่จำเป็นต้องลองหรอก 😂

3 roles, 2 bots ใน 1 คน was originally published in EMIT Stories on Medium, where people are continuing the conversation by highlighting and responding to this story.

เมื่ออาทิตย์ก่อนได้เข้าไปร่วมวงสนทนาของน้องๆที่สนใจในสายงานด้าน UX โดยที่บางก็เป็น Dev บางคนก็ทำงานสาย IT อื่นๆ ตัวเราเองก็ได้แชร์ประสบการณ์และความคิดที่มีกลับไป พร้อมกับมนุษย์ UX อีกจำนวนหนึ่งในวงสนทนานั้น พอกลับมาบ้านก็เลยรู้สึกว่าอยากมาลองแชร์ประสบการณ์ตรง ลงดีเทลให้มันสุดๆไปเลย เพราะถึงแม้ว่าบลอคที่แล้วจะพูดถึงการเปลี่ยนสายไปแล้ว แต่มันเป็นแค่มุมมองกว้างๆ ไม่ใช่ Hand-on แบบอ่านจบปุ๊บ ทำปั๊บ ยื่นสมัครงานได้เลย

บลอคนี้เลยจะมาพูดถึงการเตรียมตัว เตรียมใจ แล้ววิ่งเข้าใส่ตำแหน่ง UX จากคนที่เคยเป็น Developer มาก่อน :3

*หมายเหตุ* เป็นประสบการณ์ส่วนตัว ซึ่งแต่ละคนมีมุมมองและบรรทัดฐานต่างกัน กรุณาใช้วิจารณญาณในการอ่าน และอีกอย่างที่ต้องย้ำคือ ข้อมูลชุดนี้เก่าแล้วนะ อาจจะไม่ได้อัพเดททันโลกปัจจุบันเท่าไหร่ (เราตั้งเป้าจะย้ายสายราวๆ 4ปีครึ่งก่อนหน้านี้ เตรียมตัวยื่นป.โทครึ่งปี เรียนโทอีก 2 ปี แล้วกลับมาสมัครงานเป็น UX ครั้งแรกเมื่อ 2 ปีที่แล้ว)

1. ถามตัวเองให้แน่ใจ

อะ แน่นอน การเปลี่ยนสายคือการเริ่มต้นใหม่ แล้วการเปลี่ยนสายไปเลยอย่างจริงจังคือการเริ่มใหม่จากศูนย์ เพราะงั้นสิ่งแรกที่แนะนำให้ทำคือการคุยกับตัวเองก่อน ตกลงกับตัวเองก่อน ว่าทำไมถึงอยากเปลี่ยนสาย ทำไมถึงไม่อยากทำงานปัจจุบันแล้ว แล้วทำไมถึงอยากไปสายใหม่ แล้วถ้าไปสายใหม่แล้วเจอปัญหาแบบเดิมจะทำยังไง จะรู้สึกยังไง จะยังทำมันอยู่มั๊ย หรือถ้ายังไม่แน่ใจ ถามตัวเองว่าพร้อมเสี่ยงแค่ไหน รับความล้มเหลวได้มากเท่าไหร่ Hint ให้นิดนึงว่าถ้าล้มเร็วก็ลุกได้เร็ว อย่ากลัวพลาด อย่ากลัวเสียเวลา ทุกอย่างที่เกิดขึ้นมาแล้วย่อมดีเสมอ ;3 (การันตีจากคนที่ปัจจุบันไม่ได้ทำงาน UX แล้วแต่ไม่เคยเสียใจที่ตัวเองเปลี่ยนสายมาทางนี้เลย เดี๋ยวอธิบายเพิ่มท้ายบลอค)

ส่วนตัวเรา ถ้าอิงจากบลอคที่แล้วก็นั่นแหละ งานเขียนโค้ดคือสิ่งที่เราทำได้ ก็สนุกดี แต่พออยู่ในสภาพแวดล้อมที่คนเก่งๆเยอะๆแล้วก็รู้สึกว่าเราไม่ได้ into it แบบเขา แล้วเรามองไม่เห็นภาพตัวเองเขียนโค้ดไปตลอดชีวิต ส่วนงาน UX คือการ shift สายไปด้าน Design ที่ตัวเราเองก็สนใจตั้งแต่เด็กๆ แต่เลือกที่จะมาสาย Coding ตอนมหาลัย เลยรู้สึกว่ามันไม่ใช่ out-of-nowhere thing อะ มันเป็นส่วนประกอบในชีวิตเรามาโดยตลอด เลยคิดว่ามันน่าจะพอไปไหว ความเสี่ยงตอนนั้นก็ไม่มี (จบมาทำงานได้ 2 ปี ฐานเงินไม่สูง ไม่มีภาระอะไรมากมาย) ก็เลยโกๆจ้า

2. เตรียมใจ

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

เพราะงั้นเตรียมใจเยอะๆ เราจะต้องเหนื่อยกว่า ต้องพยายามเยอะกว่า เมื่อเทียบกับคนที่จบมาตรงสาย แต่มันก็ไม่ได้แปลว่าสิ่งที่เราสะสมมาคือไร้ค่า อย่าง Tech background ในงาน UX คืออาวุธชั้นดี เราสามารถการันตีได้ว่า Design ของเราไม่ลอย ไม่เพ้อฝัน มันทำได้จริง แถมเรายังสามารถต่อรองกับ Dev ได้เก่งกว่าใครด้วย มีอีกคำแนะนำที่ดีจากเพื่อน UX ก็คือ ถ้าเคยโค้ดมาก่อน ขายตัวเองด้วยจุดเด่นนี้ได้ แต่อย่ายอมให้ใครมาเอาเปรียบใช้สกิลนี้จากเรา เช่น รับมาทำงาน UX แต่ไปๆมาๆ ต้อง Design ด้วย เขียนโค้ดเองด้วย กลายเป็นว่าเหมา 2 role แต่เงินเดือนจึ๋งนึง จงยืนหยัดในเส้นทางที่อยากเดิน ถ้าคุยไม่เคลียร์ ถ้าเค้าจะกดให้ได้ เราก็เชียร์ให้ออกมานะ มันไม่คุ้มกันหรอก จงอย่าลืมว่าเราย้ายสายไปทำไม เรามาที่นี่เพื่ออะไรกันแน่

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

ตอนเราย้ายสาย เราทำใจไว้เลยด้วยซ้ำว่าเงินจะลดลง เพราะฐานเงินเดือน Dev มันสูงอยู่แล้วอะนะ แล้วนี่ไปเรียนโทมา 2 ปี กลับมาก็กล้าเรียกเงินเพิ่มแค่ไม่กี่พัน จำได้ว่าตอนนั้นไปคุยๆในวงเพื่อนเรื่องนี้แล้วโดนสวดว่าเรียกน้อยมาก 5555+ ส่วนตัวเราแค่ประเมิณความรู้ ความสามารถที่ตัวเองมีในตอนนั้นๆ ประกอบกับตั้งว่าเงินเดือนเท่าไหร่คือเพียงพอที่เราจะใช้ชีวิตได้อย่างไม่ลำบากและสามารถทำงานคืนกลับให้บริษัทได้ตามที่เค้าคาดหวัง เพราะงั้นก็ แล้วแต่คนอะเนอะ แต่ถ้าใครตั้งเพดานไว้สูง ก็เตรียมคำตอบเวลาเค้าถามกลับมาดีๆละกัน -w-

3. เตรียมตัว

เข้าสู่ของจริงละ ถ้าทุกอย่างมั่นใจแล้ว พร้อมลุยสนามแล้ว ก่อนยื่นใบสมัครงานไปเราต้องมีอะไรบ้าง นี่คือสิ่งที่เราทำ:

3.1 เตรียมความรู้

แน่นอน แค่ความสนใจมันไม่มากพอให้ใครยอมอ้าแขนรับเราเข้าไปทำงาน เมื่อ 4 ปีที่แล้ว เรายังไม่สามารถเข้าถึงข้อมูลด้าน UX ได้หลากหลายขนาดนี้ ทางออกของเราคือการไปเรียนโท แต่ถ้าเป็นวันนี้ เราจะแนะนำให้ตัวเองอ่านบลอค อ่านบทความ อ่านหนังสือ เข้า workshop เข้า conference เข้า meetup ทั้งหลาย ลองทำงาน mock-up เล่นๆ แล้วเก็บ feedback จากคนรอบตัว ถ้าขยันหน่อยก็รับงานนอก ลองเจอลูกค้าจริงๆ ตบตีกับลูกค้าจริงๆ ทั้งหมดเหล่านี้มันน่าจะเพียงพอที่จะเติมความรู้และอาวุธในมือของเราให้มีมากพอที่จะไปสมัครงานย้ายสายได้ เพราะมันคือการเติมความรู้ทั่งฝั่งทฤษฎีและปฏิบัติ (เน้นย้ำว่าสองอย่างนี้ต้องไปพร้อมๆกัน แค่ฝั่งใดฝั่งนึงมันไม่เพียงพอนะครัช) ทำให้เรารู้และเข้าใจคร่าวๆแล้วว่ากระบวนการคิด การทำงานมันเป็นยังไง แล้วมันก็จะเป็นการยืนยันความรู้สึกเราไปพร้อมๆกันว่าทางที่เราเลือกจะเดินไปต่อเนี่ย มันใช่จริงๆแล้วรึเปล่า

3.2 เตรียมพอร์ท

เมื่อความรู้แน่นแล้ว จะกดสมัครงานแล้ว Portfolio คือการสื่อสารอย่างเดียวที่เราจะ present ตัวเราในฐานะ candidate ได้ แต่ต่อให้พูดว่าพอร์ทก็เหอะ ของเราเองคือไม่มีอะไรเลยยยยย เพราะจากที่พ่นๆมาข้อที่แล้ว เราไม่ได้ทำ… ;w; เราแค่ไปเรียนโทกิ๊กก๊อก เขียนบลอคก๊องแก๊ง แต่เราก็สมัครงานด้วยความมั่นใจที่เรามีอะ 5555+

สิ่งที่เราเอาไปสัมภาษณ์มี 2 อย่าง:

• Thesis ป.โทที่เราทำเรื่องตุ๊กตาพูดได้ที่จะเชียร์ให้ user ไป interact กับคนอื่นๆ (เน้นอธิบายวิธีพัฒนาไอเดีย กับการทำ quantitative/qualitative research ที่น่าจะ apply กับ user research ได้)

• Medium บลอคนี้ที่เราฝึกเขียนเรื่อง UX โดยเน้นบทความที่เราฝึกออกแบบ BNK Market App ตั้งแต่ตั้งต้นไอเดียยันเอาไปเทสกับเพื่อนเราเอง (ความติ่งก็มีประโยชน์นะ 😂) เพราะเราสามารถอธิบายการทำงานทั้งหมดได้แบบครบลูป แม้ว่าจะเป็นเพียงแค่การทดลองทำแบบผิวๆก็ตาม จะแอบเห็นว่าช่วงนั้นเขียนบลอคภาษาอังกฤษด้วยเพราะอยากฝึกภาษา (+เผื่อสมัครบ.อินเตอร์…)

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

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

3.3 ทำงานจริง = เจ็บจริง

ขั้นตอนสุดท้ายอันแสนเจ็บปวด 555555+ คือการย้ายสายสำเร็จมันไม่ใช่จุดจบอะ มันคือจุดเริ่มต้น การทำงานจริงๆให้สมกับความไว้วางใจ(และเงินเดือน)ที่บริษัทมอบให้ มันคือสภาพแวดล้อมและการทำงานที่เปลี่ยนไปจากที่สิ่งที่เราคุ้นเคย มีทั้งส่วนที่สนุกที่เราตั้งตารอคอย และสิ่งไม่คาดฝันที่เราต้องกลับมาถามตัวเองว่าจะยังไงดี จากประสบการณ์ส่วนตัวที่เปลี่ยนสายงานมา 2 รอบแล้ว (//ทำท่าเขินอายแปป) ช่วงประมาณ 3 เดือนทั้งก่อนและหลังย้ายสายคือความสับสนขั้นสุด เราคิดถูกป่าววะ? หรือเราไม่ควรย้าย? ทำไมมันยากจัง? แต่ก็ไม่อยากทำอันเดิมแล้ว? ความคิดตบตีสับสนกันไป เป็นเรื่องธรรมดาของการเปลี่ยนแปลงใดๆก็ตาม ได้แต่ประคองสติตัวเอง โฟกัสแค่ระยะสั้นไว้ก่อน ค่อยๆจูน ค่อยๆปรับ พอทุกอย่างเริ่มลงตัวแล้ว ค่อยกลับมาคิด มาตัดสินใจว่าทางที่เราจะเลือกเดินต่อไปควรเป็นทางไหนดี อย่าลืมว่านี่ไม่ใช่ตั๋ว One-way ถ้าย้ายไปแล้วยังรู้สึกไม่โอเคจริงๆ (แต่ต้องทิ้งระยะให้นานพอจนแน่ใจว่าเพราะมันไม่ใช่จริงๆหรือแค่ยังปรับตัวไม่ได้) จะหันหลังกลับไปทางเดิม หรือ explore หาทางที่สาม ที่สี่ มันก็เป็นไปได้ทั้งนั้น

และใช่ค่ะ ตอนนี่เราอยู่ทางที่สาม 😂😂😂 ตอนนี้เป็น Business Analyst มาครึ่งปีแล้วค้าบบ เหมือนอย่างที่บอกไปไว้บลอคที่แล้วว่า 6 เดือนที่เป็นเวลาที่เหมาะสมในการ confirm กับตัวเอง ซึ่งตอนนี้ตกผลึกแล้วว่าเราชอบด้าน UX แหละ แต่มันก็เป็นแค่ Personal interest ไม่ใช่ Professional interest เราสนใจด้าน Design แต่เราไม่ได้อยากทำงานด้านนั้น (อาจจะเพราะเวลายังไม่พร้อม เรายังไม่พร้อม หรือบริษัทปัจจุบันอาจจะยังไม่พร้อม 🙈) แต่เราไม่เคยเสียดายที่เราได้ย้ายสายไปลองทำงานนั้นๆ และเราคงไม่มีวันรู้ถ้าเราไม่ได้ทำมัน แถมความรู้ ทักษะใดๆก็ตามที่เราได้จากการย้ายสายครั้งนั้น ปัจจุบันมันก็ยังได้ใช้อยู่ แล้วเราก็ต่อยอดมาถึงทุกวันนี้ได้ก็ด้วยการตัดสินใจครั้งนั้น มันไม่ใช่ความผิดพลาด มันไม่ใช่การเสียเวลา ทุกอย่างที่เกิดขึ้นแล้วมันย่อมดีเสมอจริงๆ :))

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

Happy exploring นะคะทุกคน ;3

เผื่อใครยังไม่รู้ เราเปลี่ยนสายงาน “อีกแล้ว” 5555+
ไหนๆก็เปลี่ยนไปๆมาๆเป็นว่าเล่นอยู่ละ เลยอยากมาแชร์ประสบการณ์ให้ฟังกัน :)

Disclaimer: ทั้งหมดในบลอคคือประสบการณ์ส่วนตัว และมุมมองส่วนตัว มันไม่ได้ถูกต้อง 100% แน่ๆ เราอยากแชร์เพื่อให้ใช้อ้างอิง แต่ไม่ได้แนะนำให้ทำตามนะ 😆

Start as a dev

จุดเริ่มต้นแรกสุด จากคนที่จบคณะซอฟต์แวร์ ก็ต้อง Developer น่ะสิ! สมัยที่ยังมี Native Android Dev ราวๆ 6 ปีที่แล้วได้ 5555+ ก็เป็นเด็กธรรมดา เรียนรู้ไปพลาง พัฒนาตัวเองไปพลาง ตัวเราชอบการเขียนโค้ดนะ เราสนุกกับ logic ต่างๆแล้วรู้สึกดีเวลาที่โค้ดเราเวิร์ค จนถึงปัจจุบันนี้ ถ้ามีคนถามโมเมนต์การทำงานที่เราแฮปปี้ที่สุด เราก็ยังจะตอบว่าเป็นตอนนึงในฐานะ dev ที่เรา figure out algebra ตัวนึงขึ้นมาแล้วปรับใช้เข้ากับ logic ในโค้ดจนมันสำเร็จ ถึงแม้ว่าตอนนี้เราจะเปลี่ยนสายงานไปไกลแล้ว ก็ยังไม่เจออะไรที่รู้สึกดีได้เท่าตอนนั้นเลยจริงๆ

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

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

Master for non-master

ถึงจะบอกว่าการเรียนต่อเป็นทางออกที่ง่ายก็เถอะ แต่มันก็ไม่ได้ง่ายอย่างที่คิด ขนาดเราเป็นคนเอาเงินไปจ่ายค่าเล่าเรียนเอง บางคณะก็ยังไม่อยากรับเราเข้าไปเลย 555555+ ป.โทอะเนอะ บางคณะมันคือการต่อยอด เพราะงั้นถ้าเราไม่มีฐานความรู้เดิมให้ต่อ เค้าก็ไม่สามารถช่วยอะไรเราได้ 😢 เราใช้เวลาหาๆอยู่ซักพักจนเจอคณะที่สอนเกี่ยวกับ Innovation ซึ่ง key สำคัญของเค้าคือ Innovation = Technology + Design + Business เพราะงั้นเค้าจึงรับคนจากทั้งสามสาขา หรือสาขาอื่นใดเข้ามา ทำให้การเรียนรู้ต่อยอดนั้นเกิดจากการพูดคุยแลกเปลี่ยนร่วมกันระหว่างนักเรียน (ปล. เราไปเรียนที่ญี่ปุ่น เรียนภาคภาษาอังกฤษ ก็จะได้เรียนรู้ความหลากหลายจาก nation & culture มาเพิ่มเติม)

แต่ก็นั่นแหละ (บลอคนี้น่าจะมีคำว่าแต่เยอะมากแน่ๆ lol) คณะที่รับคนหลากหลาย หลักสูตรก็อาจจะจับฉ่ายพอประมาณ คือมันมีตั้งแต่ group discussion พยายามสร้าง innovation ใดๆมาแก้ปัญหา, Design Thinking ฉบับอยู่ในกรอบเป๊ะๆตามสไตล์ญี่ปุ่น ไปจนถึงคอร์สเบสิคของการเขียนโปรแกรม/การทำ Digital Media, หรือแม้กระทั่ง Otaku Culture (ที่อาจารย์คอสเพลย์มาสอนทุกคาบ..) สิ่งที่พอจะเป็นประโยชน์กับงาน UX ในอนาคตที่เราคาดหวังไว้ก็คือการทำ Thesis ที่เราได้แสดงความคิดสร้างสรรค์ในการสร้าง product ใหม่ๆมาแก้ pain point ที่มี บวกกับการทำ research ทั้ง quantitative & qualitative เพื่อนำผลมาพิสูจน์ไอเดียของตัวเอง

พอส่งธีสิสเสร็จแล้ว 2 เดือนที่เหลือก่อนกลับไทยเราก็ค่อนข้างล่กพอประมาณ เพราะไม่รู้สึกว่าธีสิสในมือมันจะมากพอไปยื่นสมัครงานสายใหม่ได้ ก็เลยเพิ่ม skill UX ตัวเองด้วยบลอค Medium เนี่ยแหละ ตอนนั้นตั้งเป้าว่าอ่านบลอคทุกวัน เขียนบลอคทุกวีค (ใช่ค่ะ มันคือจุดกำเนิดของบลอคนี้) พยายาม conclude ความรู้ที่ตัวเองหามา ทำ Design breakdown บ้าง ออกแบบแอปใหม่แล้วเทสกับเพื่อนๆเพื่อจำลองการทำงานให้ครบ flow บ้าง พอกลับไทยก็เอาสองอย่างนี้แหละ เป็นอาวุธไปหางาน UX

UX Designer for a startup

ที่แรกที่เราเข้าทำงานคือ บ.Startup เล็กๆ ส่วนตัวรู้สึกว่าในการเปลี่ยนสายงาน บ.แนวนี้จะเข้าได้ง่ายกว่า เพราะคุยกันง่าย ต่อรองง่าย คู่แข่งน้อย แลกด้วยค่าตอบแทนและสวัสดิการที่น้อยตาม (เอาจริงตอนแรกเตรียมใจไว้แล้วด้วยซ้ำว่าเงินเดือนจะน้อยกว่าตอนเป็น dev 😂) แต่ก็เป็นสนามฝึกฝีมือที่ดี ได้ลองทำอะไรหลายๆอย่างจากความยืดหยุ่นของบ.

แต่ (เราจะเริ่ม paragrah 2 ของทุก session ด้วยแต่ไม่ได้..) แต่ๆๆๆ พอได้ทำงานจริงๆ เรารู้สึกว่าเราทำงาน Design ได้ไม่สวยอะ 5555555 คือเรามีพื้นฐานด้าน Dev ทำให้ข้อดีของงานเราคือการเจรจาและ flexibility กับทีม dev และการรับประกันว่า design นั้นทำได้จริง ส่วนข้อเสียก็คือ บางครั้งเรายึดติดกับ feasibility จนเกินไป บางครั้งความรู้เราก็ outdate ไปแล้ว ทำให้งานที่ออกแบบมามันไม่ได้ออกนอกกรอบขนาดนั้น แล้วพื้นฐานด้านการดีไซน์ พวกทฤษฎีสีหรือ typography เราก็ยังไม่แม่น ทำให้เราไม่ค่อยรู้สึกว่างานตัวเองสวยซักเท่าไหร่

ตอนนั้นงาน UX เริ่มเป็นที่รู้จักมากขึ้น ทำให้เรารู้ว่านอกจาก UX Design แล้วยังมี UX Research ด้วย ก็เลยอยากลองย้ายไปทำตรงโซนนั้นดู เพราะคิดว่าอาจจะได้ใช้พวก analytical skill ที่ตัวเองพอมีของอยู่บ้าง แต่การจะทำ Research ใน Startup ที่ไม่ได้มีงบ มี user จริงจังก็เป็นเรื่องยาก เลยต้องย้ายไปบ.ที่ขนาดใหญ่ขึ้นกว่านี้แทน

UX Research for a corporate

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

อะ รอคำว่าแต่กันใช่มะ ไปจ้ะ 😂 แต่ๆๆ พอเราได้ทำ Research จริงๆ ก็อีกนั่นแหละ เราก็ยังพบ pain บางอย่างในตัวเรา ทั้งๆที่บริษัทมี internal user ที่เราสามารถ reach หาได้ตลอดเวลา กลับเป็นที่ตัวเราเองที่ไม่ได้ comfortable มากพอจะเข้าหาคนอื่นขนาดนั้น ประกอบกับอีก 1 major pain point ที่ได้พบจาก product ที่ยิ่งใหญ่มากๆตามไซส์บริษัท คือไม่ว่าเราจะเสนออะไรไปตามความรู้ UX ที่เรามี 80% คือโดนฝั่ง Business ที่เป็น Key person ตบกลับมาว่ามันทำไม่ได้ ยกตัวอย่างเช่น ถึงเราจะเห็นว่า Design ตรงนี้ทำให้ดีขึ้นได้ แต่ถ้า user ฝั่งเอเชียกับฝั่งยุโรปใช้งานกันคนละแบบ เราก็จะต้อง maintain Design แบบเดิมที่ตอบโจทย์ได้ทั้งสองฝั่ง เป็นต้น ซึ่งส่วนหนึ่งเป็นเพราะเราเองยังไม่ได้เข้าใจ product และ user ได้ครอบคลุมขนาดนั้น เวลาครึ่งปีมันยังไม่มากพอที่เข้าใจมันทั้งหมดจริงๆ

เกริ่นก่อนว่าก่อนเราจะย้ายมาเป็น UX Research เราก็เริ่มถามตัวเองแล้วแหละ ว่า UX คืองานที่ใช่สำหรับเราจริงๆรึเปล่า แล้วถ้าไม่ใช่ เราจะหา plan B ต่อไปยังไงดี ปัจจัยนึงที่ทำให้เราเลือกมาอยู่บ.ปัจจุบันนี้ก็เพราะว่าเค้ามีระบบเปลี่ยนงานทุก Cycle ทำให้คนๆนึงสามารถหมุนเวียนไปเรียนรู้เรื่องต่างๆได้มากมาย ซึ่งสำหรับเรามันฟังดูเป็นทางออกที่ดีถ้าเราอยากเปลี่ยนทางเดิน พอเราเริ่ม Struggle กับปัญหาใน Role ล่าสุด เราก็แอบไปเปรยๆเบิกทางกับซุปตัวเองไว้ก่อน แต่ก็ตั้งใจว่าจะรอดูซักปี เผื่อว่าพอรู้อะไรๆมากขึ้นจะเห็นอะไรชัดขึ้น

เผอิ๊ญญญญ หลังจากเฟรยกับซุปไปไม่นาน ก็เกิดการเปลี่ยนแปลงในบริษัท มีการ relocation พนักงานมากมาย กับเราที่ใจตัวเองสั่นคลอนไปเล็กน้อยแล้ว เลยมองเห็นตรงนี้เป็นโอกาส ยกมือบอกซุปทันที หนูอยากย้ายทีมค่าาาาา!!

Another stepping stone

การเปลี่ยนสายครั้งที่สอง เอาจริงก็ถามตัวเองบ่อยเหมือนกันนะ ว่าคิดถูกมั๊ย คิดตื้นไปมั๊ย เหลาะแหละไปรึเปล่า เท้าที่ก้าวออกไปมันคือเดินไปข้างหน้าจริงๆใช่มั๊ย? แล้วอะไรคือ passion ที่เราเฝ้าตามหา เคยเฟลถึงขั้นที่ว่ายืนตกผลึกกับตัวเองตอนซื้อโตเกียวว่า คนขายโตเกียวก็ไม่ได้มี passion ในการทำโตเกียวทุกคนปะวะ? ถ้าเค้าตั้งเป้าหมายว่าจะมีเงินเลี้ยงดูครอบครัว จะขายโตเกียวหรือขายหมูปิ้งก็อาจจะไม่มีผลอะไรเท่าไหร่ แล้วถ้าเราไม่ได้ตั้ง goal ว่าจะต้องเจอ passion ถ้าสิ่งที่เราต้องการจริงๆเป็นเพียงแค่สนุกในการทำงาน ก้าวหน้าในการทำงาน career goal ก็อาจจะไม่จำเป็นต้องเป็นหนึ่งแสงจากปลายอุโมงค์ก็ได้ การที่เราหาตัวเองไปเรื่อยๆ ค่อยๆแก้ปมไปทีละจุด plan checkpoint ข้างหน้าไว้สองสามอัน แล้วปล่อยให้หัวใจเป็นเข็มทิศชี้นำทางไป ก็อาจจะเพียงพอแล้วก็ได้

ปล. อีกหนึ่งแรงบันดาลใจจากการตกผลึกครั้งนี้ คือ TED talk อันนี้:

Role ปัจจุบันของเราคือ Business Analyst เป็นตำแหน่งที่เราสามารถต่อยอดความรู้ทั้งด้าน Dev และ UX ของเราได้ เป็นตำแหน่งที่เราสามารถแก้ pain point ของตัวเองที่ไม่รู้เรื่อง Business process ใดๆได้ เป็นตำแหน่งที่เรารู้ว่าเราทำอะไรได้ เป็นตำแหน่งที่เรารู้ว่าเราจะได้อะไร ส่วน checkpoint ข้างหน้า มีวาง option หลวมๆทั้ง Product Owner และ Data Analytic แต่ก็นั่นแหละ ยังคงต้องเรียนรู้และเก็บข้อมูลไปอีกซักพัก และแม้ว่าตำแหน่งนี่เราจะมองมันเป็นเพียงแค่อีก 1 stepping stone ที่ตัวเองต้องมาเก็บของเพื่อตามหาตัวเองต่อไป เราก็จะทำมันให้เต็มที่ เพราะไม่มีใครรู้ว่าอะไรจะเกิดขึ้น อยู่ดีๆอาจจะ spark joy ขึ้นมา หรืออาจจะได้ค้นพบทางเดินใหม่ที่คาดไม่ถึงเลยก็เป็นได้

เพราะงั้น ในอนาคตไม่ว่าอะไรจะเกิดขึ้น เราก็จะอ้าแขนรับมัน :)
(นอกเรื่องจากการเปลี่ยนสายไปไกลรึเปล่านะ lol)

สรุป

ในการเปลี่ยนสายทั้งหมดที่เดินทางมา มี core ideas อยู่ไม่กี่อันสำหรับเรา:

1. หา pain ให้เจอ
   ถ้ารู้สึกว่าไม่ชอบงานที่ทำอยู่ คุยกับตัวเองเยอะๆ ถามให้นานพอจนมั่นใจว่าความรู้สึกของเราเป็นของจริง ถามให้ลึกพอจนรู้ว่า root cause ของมันคืออะไร
2. ลองทำตามซัก solution(s)
   ถ้ามั่นใจในปัญหาแล้ว ลองหาทางแก้ไขดู พิจารณาว่าของในมือเรามีอะไรไปแลกกับ solution นั้นๆ ถ้าของยังมีไม่พอ ไปฟาร์มของซะ ถ้ามีของพอแล้ว ก็โกๆ บางครั้งทางออกอาจจะไม่ใช่การเปลี่ยนสาย แต่เป็นการแก้ปัญหาบางอย่างที่ทำให้เราไม่พอใจในสถานะปัจจุบัน
3. Checkpoint กับตัวเอง
   ไม่ว่าจะตอนหาปัญหา ตอนหาทางแก้ หรือตอนที่ลงมือแก้ไขปัญหา คอยคุยกับตัวเอง เช็คกับตัวเองบ่อยๆ การหลงทางเป็นเรื่องปกติ แต่ทุกการเดินอ้อมจะไม่มีเสียเปล่า คุณไม่มีทางรู้ว่าคุณจะได้ใช้ของที่มีในมือตอนไหน
4. อย่า rush จนเกินไป
   สำหรับเรา ช่วงเวลาในการ confirm pain point ของตัวเองที่ดีคือประมาณ 6 เดือน ส่วนเวลาในการแก้ไขปัญหาจะหลากหลายกันไปตามสเกล แต่สิ่งที่บอกตัวเองบ่อยๆคืออย่ารีบ บางครั้งเรารู้ว่าเราอยากได้ดาบ เราก็อาจจะต้องเก็บเหล็กเก็บหินไปก่อน จนกว่าจะถึงวันที่เราแข็งแกร่งพอที่จะหลอมดาบจากวัตถุดิบเหล่านั้น เพราะงั้น อย่ากดดันตัวเอง (ย้ำกับตัวเองรอบที่ล้าน แงงงง)

และนั่นคือทั้งหมดของบลอคในวันนี้ หวังว่าจะเป็นประโยชน์กันนะคะ

ถ้ามีอะไรอยาก discuss เพิ่มเติมก็เม้นมา ทักมาได้ ยินดีแลกเปลี่ยนกัน :)

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

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

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 เพื่อร่วมงานด้วยกันนั่นเอง :)

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

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

พอได้รับ 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

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

Design the prototype

ถ้า 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

เมื่อ 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

เพื่อพัฒนาเสร็จเรียบร้อยแล้ว ขั้นตอนสุดท้ายคือการ 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

ใช่ค่ะ 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 นาจา~

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

Unexpected outcome of UX was originally published in EMIT Stories on Medium, where people are continuing the conversation by highlighting and responding to this story.

หลังจากทำงานเป็น UX มาซักพัก ก็เริ่มอยากขยับขยาย work scope ให้กว้างขึ้นนอกเหนือจากงาน Design ที่เคยๆทำมา พอดีมีเพื่อนร่วมทีมที่ต้องไปสัมภาษณ์ลูกค้าที่อินโดนิเซีย + หัวหน้าเห็นว่ามันเป็นโอกาสดีที่เราจะได้เรียนรู้เพราะเรายังไม่เคยทำ research จริงจัง ก็เลยได้ตามไปทำงานด้วย จนตอนนี้กลับมาปั่นรีพอร์ทและส่งมอบงานแล้ว เลยอยากเขียนบลอคนี้ไว้เป็นที่ระลึกและร่วมแชร์ให้เพื่อนๆฟังกัน

อนึ่ง ความหมายของ Research และวิธีการต่างๆจะแตกต่างกันออกไปตามแต่การเรียนรู้ บริษัท วัฒนธรรม และแม้กระทั่งบุคคล เพราะงั้น Feel free to share นะคะ :3

Background

เกริ่นก่อนถึงที่มาที่ไปของการทำ Research ในครั้งนี้ บริษัทเราเป็นการค้าขายแบบ B2B (Business to business) ซึ่งลูกค้าที่เราจะไปหาในครั้งนี้คือบริษัท Distributor ที่ซื้อของลอตใหญ่ๆจากบ.เราไปขายต่อให้กับลูกค้ารายย่อยอีกที เพราะงั้น Customer ≠End consumer นาจา~

ซึ่งลูกค้าที่ซื้อสินค้าจากทางเรา ก็จะมีการใช้ Online platform ตัวนึงในการสั่งซื้อและจัดการต่างๆ โปรเจคที่ส่งพวกเรามาหานางๆก็คือเกี่ยวกับ Platform นั้นแหละ แต่ Goal จริงๆไม่ใช่แค่การมาถามความคิดเห็นเกี่ยวกับ system แต่จะเป็นการเรียนรู้เกี่ยวกับ Process การทำงานโดยรวมเพื่อมองหา opportunities ใหม่ๆในการพัฒนาหรือปรับปรุงประสบการณ์ต่างๆในการทำงานร่วมกัน

สำหรับคนที่คุ้นๆกับ UX Cycle เฟสนี้ก็คือการ Discover นั่นเอง ซึ่งเราจะโฟกัสกับการเรียนรู้และทำความเข้าใจในปัจจุบัน เรื่อง solution หรือความเป็นไปได้ใดๆ จะยังไม่พูดถึงในตอนนี้

Getting ready to see customer

อย่างที่บอกไปว่าลูกค้าของเราคือ B2B ทำให้เราไม่สามารถใช้ incentive หรือแรงจูงใจใดๆในการทำให้เค้าเปิดอกคุยกับเราขนาดนั้น แถมเฟสที่เราทำคือการ discover ไม่ใช่ feedback sharing การเข้าไปบริษัทหนึ่งๆ ยิ้มร่าขอสอบถาม process การทำงานทั้งหมดจากเค้ามันไม่ใช่เรื่องง่ายๆ

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

ครั้งนี้เรายังโชคดีที่มี Sale manager เป็นตัวกลางคอยช่วยดูแล เคยมีปัญหาที่คนอื่นในทีมไปขอสัมภาษณ์ลูกค้าเองแล้วโดนถามกลับมาเหมือนกันว่าไหนหลักฐานว่าคุณคือใครมาจากไหน (แต่ก็เพราะบ.เราค่อนข้างบ้า security ด้วยแหละ บัตรพนักงานเลยไม่มีโลโก้หรือข้อความใดๆสื่อถึงตัวบริษัทเลย…) เพราะงั้นถ้าไม่มีตัวเชื่อมความสัมพันธ์ การให้เวลากับการ on-board และ ice-breaking ก็น่าจะพอช่วยแก้ปัญหาไปได้ระดับนึง

ซึ่งก่อนที่จะติดต่อผ่านตัวกลางเพื่อนัดสัมภาษณ์ การเตรียม material ทุกอย่างไว้ก่อนก็สำคัญ เพราะเราไม่รู้ว่าลูกค้าที่จะคุยด้วยเป็นคนแบบไหน บางคนก็ชิลๆนัดวันมาได้เลย บางคน strict หน่อยก็จะอยากรู้ว่าเราสัมภาษณ์อะไร ทำอะไรบ้าง จะเอาข้อมูลไปให้ใครมั๊ย ซึ่งทางเราก็ต้องส่ง interview script + privacy policy สำหรับการขอบันทึกบทสัมภาษณ์ล่วงหน้าไปให้ลูกค้าพิจารณาประกอบการตัดสินใจ

อีกหนึ่งข้อที่พึงระวังสำหรับการไปหาลูกค้าต่างชาติคือ เช็คให้ชัวร์ว่าเค้าพูดภาษาอังกฤษได้ระดับไหน ถ้ารวยหน่อยก็เตรียมล่ามมืออาชีพไปด้วยเลยก็ดี คือบางทีคนรับเรื่องอาจจะเป็นคนที่ติดต่อกับบ.เราอยู่แล้ว ภาษาเลยไม่ใช่ปัจจัย แต่การสัมภาษณ์คนระดับ operation ต่างๆเพื่อเข้าใจ process โดยรวมก็อาจจะเจอกำแพงภาษาเหมือนกัน ของเราโชคดีที่มี script คร่าวๆ + Sale manager อาสาช่วยแปลให้ แต่ก็จะมีปัญหาเล็กน้อยที่เค้าไม่ใช่คนที่ทำงานด้าน UX หรือ Translator มาโดยตรง ทำให้เราไม่มีทางรู้ได้เลยว่าในการแปลนั้นๆ เค้าเผลอใส่ leading question หรือเพิ่ม bias ในการสัมภาษณ์ไปมากน้อยแค่ไหน

Interview Time :D

อันนี้ไม่มีอะไรมาก script สัมภาษณ์เราค่อนข้างหลวมๆ อยากรู้ว่าแต่ละ Operation ทำงานยังไง ประสานงานยังไง input-output ข้อมูลแบบไหน มีปัญหาหรือขัดใจอะไรบ้างมั๊ย พอสัมภาษณ์ครบทุกส่วนงานแล้วก็จะมีขอไป observe นั่งดูเค้าทำงานจริงๆซักชม. เพื่อเพิ่มเติมข้อมูลส่วนที่เค้าไม่พูดถึง เช่น พนักงาน Logistic คนนึงตอนสัมภาษณ์ก็บอกว่าใช้ input ข้อมูลจากระบบ แต่ตอนไปดูการทำงานจริงๆคือพี่แกปริ้นใบออกมาจากระบบแล้วยื่นให้คนขับรถเอาไปจัดการต่อในคลัง เป็นต้น

เมื่อได้ข้อมูลครบแล้ว สุดท้ายคือการรวมคนจากทุก operation มาทำ Journey map ร่วมกันเพื่อดู flow การทำงานทั้งหมดว่าแต่ละแผนกติดต่อประสานงานกันยังไง มีคอขวดมั๊ยไรงี้

ซึ่งเอาจริงนะ การสัมภาษณ์คนแปลกหน้าเป็นภาษาอังกฤษติดต่อกันอาทิตย์ครึ่งคือเหนื่อยลากเลือด ขนาดสลับคนถาม-คนจดกันก็แล้ว สมองมันล้าและตื้อได้เหมือนกัน ในการแพลนครั้งหน้า เราว่าการเว้นช่วงเป็นสิ่งสำคัญ อาจจะสัมภาษณ์ลูกค้าบ.นึงซัก 2–3 วัน แล้วเว้น 1 วันไว้พักสมอง + synthesize คร่าวๆเพื่อดู pattern และ trend พอวันถัดไปที่ไปสัมภาษณ์ลูกค้าอีกเจ้า เราจะเริ่มโฟกัสได้แล้วว่าอะไรเหมือนหรือต่างกันสำหรับ customer group นี้

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

Synthesize & Report

เมื่อจบการสัมภาษณ์ แยกย้ายกลับประเทศ งานสุดท้ายคือวิเคราะห์ข้อมูลและสรุปผล ซึ่งเราเองก็ยัง newbie มากๆในขั้นตอนนี้ เราอาจจะพอจับ pattern คร่าวๆได้บ้าง แต่ยังไม่สามารถวิเคราะห์ได้ว่าอะไรเป็น key สำคัญที่ทำให้ลูกค้าทำพฤติกรรมแบบนี้ เพราะงั้นตรงนี้ยังไม่มี tips ให้นะ 5555+

แต่อย่างนึงที่รู้สึกได้คือ ถ้าเราทำการบ้านก่อนการสัมภาษณ์ มีการ picture ไว้คร่าวๆว่าจะทำ report แบบไหน จะโชว์ flow โชว์ข้อดีข้อเสียยังไง มันจะช่วยทำให้เรา shape คำถามได้ตรงจุดมากขึ้น ไม่ต้องกลับมากรีดร้องในใจว่าทำไมฉันไม่ถามคำถามอันนี้ไปในภายหลังแบบเรา 😂

อีกหนึ่งอย่างที่อยากทำให้ดีขึ้นคือ Question funnel เป็นการวางโครงคำถามในการสัมภาษณ์ เริ่มจากคำถามกว้างๆทั่วไป และค่อยๆเจาะลงมาถึงสิ่งที่เราอยากรู้จริงๆ ซึ่งเราเองก็ไม่ได้ทำการบ้านดีพอว่าอะไรคือสิ่งที่เราอยากรู้แบบ the finale ทำให้อิงตาม script โครงคร่าวๆของคนในทีม ซึ่งเราเองก็ไม่ได้เก่งมากพอที่จะเจาะคำถาม on the go ได้ เลยคิดว่าการวาง funnel ที่เหมาะสมจะช่วยลดความล่กระหว่างสัมภาษณ์และทำให้ได้ result ที่ครอบคลุมในการสรุปผลตอนท้าย

อะ ปิดจบบลอคดื้อๆงี้แหละ

และนี่คือประสบการณ์และบทเรียนของการทำ User Research แบบจริงจังเป็นครั้งแรก ใครมีข้อแนะนำหรือความคิดเห็นใดๆก็เม้นมาคุยกันได้นะ บัยจ้ะ 😉

Disclaimer: This is my personal experience based on my point-of-view only. Some occurrences might or might not similar to other case scenarios in other companies, countries, or products. Would appreciate any sharing or discussion 😉

For a while that I worked in this in-house project as a UX Designer. Most of the work is to collaborate with POs (Don’t forget that s — yes, we have many POs in this project) to come up with the design for each story they created. If I’m lucky enough, we’d have some time to do the research to leverage their ideas. But if that happened, maybe this article won’t exist 😂

So, what are my challenges working in this project?

You are not your user, and never will be

A big common, most frequently, and classic problem I’d say. We all are not our users: me — the designer, POs — the owner, all of us, we’re just people who came up with ideas and hope to make it help our users and reach our goal at the same time.

The challenge is that users are not the main key point in our project. For other B2C products or startup companies, sometimes users are the main key point that we need to keep them stay with us. Unless they‘ll just leave and go to our competitors. Thus, for our corporate in-house product, users usually have a lower role compare to the PO, they’re forced to use the system as a part of the process to achieve the high-level’s goal.

And that’s when the big UX challenge encountered, we can’t just follow the POs’ guide and hope our users will understand and adapt themselves to what we created. Users are important to us, as much as the project’s goal, the POs’ visions, and all stakeholder’s opinions. We need to stay strong in our position and try our best to balance those things together. And that never be an easy task.

Too. Many. People.

Another common problem for corporate companies lol. We’re a big team, we need many people to help us achieve our gigantic goal. Thus, more people leads to more problems. Collaboration is a key to accomplish our task but it also takes time, especially when there are sooo many people to talk to.

There’s once I talked with 1 PO who takes care of a specific story that I need to redesign the page. We’re not sure about displaying one specific field so we decided to go out and ask users whether they use it or not. I ask 1 team in my location and that PO asks some representatives of few teams in their location (yes, this is a global project with many users from all over the world). Both of us got the same result that we can remove the field so we continue with that. The week after, I talked with another PO who‘s mainly responsible for my country. Since she has more experienced than me, she insisted that this field is important to many users, maybe the team I interviewed last time due to limited constraints isn’t cover that case. So, almost 2 weeks spent clarifying whether we should keep of discard that little field. Not to mentioned collaboration with developers for more complicated case scenarios.

Even though talking back-and-forth is exhausting and takes lots of time. I’d still suggest discussing among team as much as possible. No matter how much time you need to talk with many people in the team for alignment before the design or the implementation. It’s still worth the value and less cost compared to the time you need to follow up and fix after the false design or implementation is rolled out.

Writing up until now, I don’t think all challenges I explained are limited to the ‘Corporate in-house product’ as I stated in this blog’s title. They're all common problems that occur in every project and every organization. Just the use case that I brought to you is referred to that particular project I worked on.

Agile / Whirlpool

The last challenge I’d like to talk to is the agile system. Another common problem applying agile to the team is not enough understanding leads to using agile for a time limitation for the implementation. We divided tasks into a sprint, define the task’s detail and hope everything works out after sprint ends. It’s not a real iteration that we do a quick version, test it, collect feedback, and adapt to the next sprint. Just a whirlpool that we keep rolling, rolling in the same place believing it’ll bring us the bright fortune someday.

It’s not an easy task applying ‘real’ agile to a big company, especially when our corporation existed for too long and not yet 100% ready to adapt to the new era. Yet, we’re trying, for a while, and it’s gonna be better 🙏

Also, applying UX research in the agile framework is another tough task. Sprint system forced us to finish the design before the development while doing research takes time and seems impossible when the story is defined only 1 sprint ahead with no plan in mind.

Some suggestion is to prior book slot every month or couple months as ‘research phase’ to guarantee that we have time for it. Another suggestion is to involve all stakeholders in the research so they can see and understand the importance of research and allow us to perform more. Another suggestion is to show our value to the stakeholders e.g. how much we’ll lose for a feature that we didn’t do enough research, so they might understand us and give us more time for the research. The common idea is to prove the importance and value gained from the research so that everyone allows us to do it. Guys, it’s really important! 😱

And that’s all the challenges I encounter for a couple of months already. Our team is aware of these problems and still in progress in solving them. I don’t know how long it’ll take to overcome these challenges, but we believe in the little glimpse we all see at the end of the tunnel. So we’ll keep walking! Hope someday I can come back to this blog and share with you how we can solve it, hopefully 😂

That’s it for this blog! Thank you for reading up until here and feel free to share any thoughts, pains, or suggestions. Would love to hear it all 😃

Happy UXing, everyone 😉

ช่วงเดือนที่ผ่านมาได้มีโอกาสทำ workshop มากมายภายในบริษัท เนื่องจากอยู่ในทีม UX ที่ทุกคนไว้เนื้อเชื่อใจว่า expertise กันเรื่องนี้ (ซึ่งจริงๆ activity lead คือรุ่นพี่ในทีม ตัวเราเน้นช่วยประสานงานและมีส่วนร่วมเฉยๆ) ซึ่งธีมหลักๆก็มีไม่กี่อย่าง Design Thinking (หลังจากนี้จะย่อเหลือ DT) และ User Centered-Design (ที่หลังจากนี้ก็จะย่อเหลือ UCD) แล้วสองอย่างนี้เหมือนหรือต่างกันมั๊ย อะไรยังไง ก็เลยว่าจะมาเล่าให้ฟังกัน

Design Thinking = Framework

เคยดูลิงค์ E-learning สั้นๆเปรียบเทียบระหว่าง 2 อย่างนั้นอยู่ (ขออภัย มันนานมากแล้วเลยหาลิงค์ไม่เจอ 555+) สรุปง่ายๆตามที่เข้าใจและจำได้ก็คือ DT เป็น framework เป็นกรอบไอเดียคร่าวๆที่สามารถนำไปใช้ apply กับอะไรก็ได้

เราสามารถ empathize ทำความเข้าใจใครหรือสิ่งใดสิ่งหนึ่ง, define ระบุปัญหาและ pain point ของเรื่องนั้นๆ , ideate ระดมความคิดหาทางแก้ไขปัญหา, prototype & test ทดสอบว่าไอเดียของเรามันเวิร์คจริงๆมั๊ย ซึ่งกระบวนการนี้เราจะเอาไปใช้ในการทำงาน การใช้ชีวิต การวางแผนนู่นนี่ได้ทั้งหมด

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

จะเห็นได้ว่าสิ่งที่เธอพูดออกมาทั้งหมดคือ DT process ที่เราบอกไปข้างต้น และ key idea ที่น่าสนใจมากๆคือการสร้าง simple solution หลายๆอันขึ้นมาเพื่อผสานทั้งหมดเป็น good solution to the world 😉

User-Centered Design = Process

ถ้า DT คือโครงสร้าง แล้ว UCD คืออะไรล่ะ? จาก E-learning ที่เราจำลิงค์ไม่ได้อันนั้น UCD ก็คือ 1 ใน subset ของ DT ที่ใช้ framework ตาม DT โดยตรง ซึ่งจะเห็นได้ว่า process และ step ต่างๆนั้นแทบจะเหมือนกันเลย

สิ่งที่ต่างออกไปคือ UCD เป็น DT process ที่นำมาประยุกต์ใช้ในการพัฒนา software โดยเฉพาะ เริ่มตั้งแต่การทำ research เก็บข้อมูลจาก users & stakeholders, concept & design เพื่อหา solution ที่ต้องการจะพัฒนา, develop prototype ไม่ว่า low / mid / high fidelty ใดๆก็ตามแต่ แล้วนำไป test เพื่อหาข้อสรุปก่อนจะ develop product จริงๆแล้ว iterate วนลูปวนไป

เพราะงั้นในการทำงานจริงๆ (ซึ่งเราก็อยู่ในทีม IT ในวงการ software มาตลอดอะนะ) ก็เลยจะได้ใช้คำว่า UCD ซะเยอะ อีกหนึ่งอย่างที่ชอบคือชื่อ process มันความหมายตรงตัวดี ทุกครั้งที่พูดออกมาก็เหมือนจะคอยตอกย้ำให้จำฝังใจว่า you’re not your user นะ ไปถามคนใช้จริงๆ คิดถึงคนใช้จริงๆซะ อะไรประมาณนี้

สรุป

2 อย่างนั้นคือสิ่งเดียวกัน core idea เหมือนกัน ต่างกันเพียงแค่การนำไปประยุกต์ใช้ในสถานการณ์ต่างๆ สำหรับเราการเรียกผิดเรียกถูกไม่ได้ส่งผลอะไรใดๆกับการทำงาน ตราบใดที่ยังยึดมั่นในหลักการว่า user คือคนสำคัญ และโฟกัสไปที่ปัญหามากกว่าตัว solution ที่หลายๆคนชอบตั้งธงไว้ในใจตั้งแต่แรกก่อนจะเริ่ม process

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

Happy Design นะคะทุกคน 😘

Design Thinking VS User-Centered Design was originally published in EMIT Stories on Medium, where people are continuing the conversation by highlighting and responding to this story.