สรุป UX Meetup : บอกเล่าประสบการณ์การเป็น UX Mentor ที่ San Francisco

UX Meetup ตอน UX ยังไง ? ประสบการณ์การเป็น UX Mentor ที่ San Francisco
https://www.eventpop.me/e/1643
27 March 2017 at 18:30–21:00
at HANGAR Coworking Space by dtac Accelerate

เกริ่น
ด้วยเวลาจัดงานที่เป็นเวลาเลิกงานของเราชาวออฟฟิศกาย แน่นอนก็ต้องหอบหิวตัวเองแหวกการจารจรที่หนาแน่นมาถึงงานแบบหิวโซ ผนวกกับความงงปนไม่แน่ใจว่า เฮ้ย กูมีบัตรจริงๆใช่ไหมเนี่ย เพราะเรากดบัตรตอน 6.18 pm ตอนแรกคิดว่าเต็มแล้วกะว่าจะเปิดดูเล่นๆ ….อ่าว ชิบ ยังไม่เต็มว่ะแบบงงๆ ว่าบัตรหลุดหรืออะไรเพราะเห็นเขาบอกว่างานนี้บัตรเต็มตั้งแต่ 6โมงยังไม่ขึ้น 1 นาทีเลย ถือว่าฟลุ๊คไปละกัน
แต่ดีมากครับที่งานจัดอยู่กลางเมือง เดินทางสะดวกหน่อย

พูดถึงตัวบทความ ตัวบทความนี้จะเป็นบทความที่เขียนเกี่ยวกับประสบการณ์ของพี่ต้อง Karun Warapongsittikul จากการเป็น Mentor ที่ San Francisco ประเทศสหรัฐอเมริกา ประสบการณ์ถึงการได้เป็น Mentor กับ Startup และการทำงานจริงของ UX ที่ต่างประเทศว่าเป็นยังไง บางทีเนื้อหาอาจจะไม่ได้เกี่ยวกับ Ux ทั้งหมดแต่คิดว่าสิ่งที่เอามาแชร์น่าจะมีประโยชน์นะครับ

เริ่ม!

UX Mentor ที่ San Francisco

Startup Guideline

  • คุณต้องเปิดใจกับทุกอย่าง
  • คุณต้องตั้งคำถามกับทุกอย่าง อย่าเชื่อใครง่ายๆ สิ่งที่คนอื่นพูดอาจจะไม่จริงก็ได้
  • กระตือรือร้นตลอดเวลา เตรียมพร้อมอยู่เสมอ
  • มีความรู้หรือรู้อะไรมาก็มาแชร์ให้สังคม
  • โฟกัสไปที่ OKR (Objectives and Key Results)

ซึ่งในฝั่งของ mentor ก็จะมีเวิร์คช็อปก่อนเหมือนกันไม่ใช่อยู่ๆจะมานั่งคุยเลย ซึ่งแต่ละ Startup ก็จะมีข้อมูลให้กับ Mentor ก่อนเพื่อไปศึกษา Startup นั้นๆมาก่อน

Mentors Guidelines

  • เราห้ามตัดสินอะไรทุกอย่าง ให้เรารับมาแล้วพูดคุยกันมากกว่า ไม่ใช่ว่าเราคิดว่าเราฉลาดกว่า เราเก่งกว่าแล้วเราให้คำแนะนำแบบฟันธง
  • พยายามทำความเข้าใจตัวเอง ทำความเข้าใจทั้งโปรดักส์ของเรา หรือกระทั่งทำความเข้าใจ Culture ของเขาเลยด้วยซ้ำ เพราะพฤติกรรมจะไม่เหมือนกัน แต่ละCulture ก็จะต่างกันไป เช่น Startup ประเทศนี้ อาจจะไม่เหมาะกับอีกประเทศนึงก็ได้ มันจึงเป็นสิ่งที่ควรนำมาวิเคราะห์อย่างละเอียด
  • ให้ความสำคัญเรื่องการส่งต่อความรู้ซึ่งกันและกัน
  • สอนให้ใช้เครื่องมือ เหมือนสอนให้ไปตกปลาไม่ใช่จับปลาให้
Mentors Guidelines

Startup Lifecycle

แรกๆของการเติบโตเขาจะ Focus ในทางเทคนิคเป็นสำคัญ เช่น ต้องการแบบนี้โค้ดได้หรือเปล่า ต่อมาก็จะเป็นเรื่องของ Product เป็นเรื่องของ Ux ทำยังไงให้ใช้ง่าย ให้ผู้ใช้รักโปรดักส์เรา จากนั้นจะเริ่มโตก็ทำเรื่องของ Market ทำเรื่องขยายทีมจนไปถึงเรื่อง Finance เรื่องของการทำกำไร

ตอนที่เป็น Mentor ก็จะมีการไกด์ให้เราต้องทำการบ้านของ Startup นั้นๆ ตั้งแต่ก่อนเข้าไปและหลังจากนั้นด้วย ซึ่งสิ่งหลักๆที่เขาอยากจะให้ถามกับ Startup ที่มานั้นก็คือ ถามเกี่ยวกับ Current state และ อะไรคือ Challenge ของคุณ ที่นั้นจะพยายามให้คนรู้ตัวเองก่อน ถ้าเราจะแก้ปัญหาได้ เจ้าของโปรดักส์จำเป็นที่จะต้องรู้ก่อนว่ามันมีปัญหา นอกจากนั้นและเขาก็จะโฟกัสไปที่ OKR, การตั้งคำถาม คุณต้องสงสัยทุกอย่าง ไม่ใช่สิ่งที่ Mentor พูดจะถูกเสมอไป เราต้องท้าให้เขารู้ตัวเอง ให้รู้ว่าอะไรคือข้อดี-ข้อเสียหรือปัญหาของเขา ให้รู้ถึงกระบวนการคิดเพื่อให้ไปถึงจุดที่เขาตั้งไว้ให้ได้ ซึ่งจะเรียกวิธีการนี้ว่า

Five Why ?

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

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

maturity time

ซึ่งในส่วนที่จะแนะนำให้กับแต่ละ Startup ก็จะแบ่งเป็นส่วนของ

1. Technical

  • มันสามารถเป็นไปได้หรือเปล่า คุณทำมันได้หรือเปล่า
  • ที่นู้นถือว่าเป็นสิ่งที่จำเป็นต้องทำเลย เรียกได้ว่าถ้าทีมไหนไม่ทำแทบไม่ต้องมาคุยกันเลยก็ว่าได้ เพราะมันตามคนอื่นไม่ทัน
  • Effort/Impact เอา Feature มากางดูว่าอันไหนลงแรงน้อยหรือมากแล้วจะได้ impact แบบที่เรารับได้ไหม ไม่ใช่ลงแรงมากแต่ได้ impact น้อยก็ท่าจะไม่เวิร์ค
  • ไม่หวงไอเดียกัน ใครมีอะไรเอามาแชร์กันหมด ไม่กลัวว่าจะขโมยกันเพราะยังไง
    ไอเดียมันก็แค่ไอเดีย แข่งกันที่คุณภาพสินค้าดีกว่า
  • เรื่องของเวลา Startup บางตัว ถ้ายังไม่ถึงเวลา คลอดมามันก็อาจจะไม่เกิดก็ได้

2. Product

ให้ความสำคัญกับ Ux มากๆ กระบวนการคล้ายๆกัน Tools คล้ายกัน(Persona, User journey, Usability testing) แต่สิ่งที่แตกกันกับประเทศไทยแบบจังๆเลยก็คือ Mind Set ซึ่งเขาจะคิดแบบละเอียด คิดแล้วแชร์กับคนอื่น กล้าที่จะรับ Feedback แบบตรงๆ
, Culture ที่นั้นจะไม่โยนงาน Ux ไปให้กับ Ux Designer คนเดียวเพราะมันสำคัญหมด จนไม่สามารถทำได้ด้วยตัวคนเดียว เขาจะแชร์ไปให้กับทุกคนในทีม ไม่ว่าใครทุกคนต้องรู้ Ux และเจ้าของต้องเชื่อใน Ux ด้วย

design sprint framework
https://developers.google.com/design-sprint/

เราจะมีกระบวนการในการเทสไอเดียนั้นๆว่ามันเวิร์คจริงไหม แบบรวบรัดและรวดเร็ว สิ่งนี้เรียกว่า Design sprint (ถูกพัฒนาไอเดียโดย Google ) อย่าใช้เวลาเกินอาทิตย์ ควรใช้แค่ประมาณ 3–4 วัน เทสให้เร็วที่สุด ซึ่งจากรูปนั้นจะเห็นได้ว่าวิธีการแบบเดิมๆที่เราใช้กัน(เส้นสีเทา)ที่เริ่มจาก ออกแบบตามไอเดียหรือสมมุติฐานที่เรามีอยู่ (Idea) → พัฒนาผลงานออกมาตามไอเดีย (Build) → เปิดให้คนทั่วๆไปได้ใช้ (Launch) → วัดผลและศึกษาพฤติกรรมของผู้ใช้โปรดักส์เราซะ (Measure & Learn)
… 
แน่นอนว่ามันจะเกิดความเสี่ยงที่จะไม่เป็นไปตามเป้าแน่นอน แถมขั้นตอนมันยังช้าและกินเวลาไปด้วยล่ะไอ้ทิด ก็เลยเกิดแนวคิดแบบ Design Sprint (เส้นสีฟ้า)ขึ้นมาที่จะมีแค่ขั้นตอนของ Idea → Measure & Learn โดยมีหัวใจหลักคือ “ทำยังไงก็ได้ให้ผู้ใช้ได้ใช้งานให้เร็วที่สุด เพื่อที่จะทดสอบไอเดียนั้นว่าเวิร์คจริงไหม” จะเน้นไปที่การสร้าง Prototype เป็นหลัก ทำและทดสอบว่าไอเดียที่เราคิด พฤติกรรมของคนใช้นั้นมันโอเคพอที่จะเอามาทำเป็นโปรดักส์จริงๆหรือเปล่า (สามารถดูตัวอย่างการทำ Design Sprint ได้จาก http://www.gv.com/sprint/ นี่เลย)

3. Market

  • It is a Sprint and Marathon
  • แต่ละ Startup ก็มี Market Strategy ที่ต่างกัน
  • Fake it till you make it (แสร้งทำ ทำเล่นๆ จนเกิดขึ้นจริงๆ) แม่ง Bullshit งานนั้นจะออกมากากและห่วยแตก จงจริงจังกับมันซะ
  • END OF UNICORN ERA

4. Scale

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

Scale

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


What is OKR?

OKR = Objectives & Key Results เป็นการให้เป้าหมายกับทีมที่ชัดเจนแต่ท้าทาย ท้าทายพอที่จะทำให้เรามุ่งไปข้างหน้า (คล้ายๆ KPI แต่ไม่ใช่นะ) ซึ่งบางเป้าหมายถ้ามันง่ายไปเราก็จะไม่ค่อยมีพลังในการทำ แต่ถ้ามันยากไปเราก็จะท้อซะก่อน ฉะนั้นเราต้องหาจุดตรงกลางเพื่อให้ท้าทายพอที่จะกระตุ้นทีมเพื่อให้เดินตาม Vision ของเราได้ ในหนึ่งบ. ไม่จำเป็นที่จะต้องมีแค่ OKR เดียว ให้สร้างมันไปกับแต่ละส่วนแต่ละทีมใน บ. ของเรา

OKR example

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

OKR example

Q&A ท้ายงานแบบนิดๆหน่อยๆ

ปล. จำคำถามที่ถามไม่ได้ เอาไปแต่คำตอบละกันนะ

  • ความจริงแล้วมันไม่ควรมีแค่ Ux/Ui เพราะ Ux มันก็ใหญ่เกินที่คนคนเดียวจะทำได้ครอบคลุม แถมยังไปพ่วงกับงานตำแหน่งอื่นอีก ซึ่งที่จริงมันควรอยู่ในหัวของทุกคน ตั้งแต่ตำแหน่งบนๆ หัวหน้างานรวมไปถึงตำแหน่งปลายน้ำเลยด้วยซ้ำ ไม่ใช่เอะอะจะมายัดให้อยู่แต่กับ Designer อย่างเดียว
  • บางคนก็เป็น Uxer ที่ดีได้โดยไม่จำเป็นต้องรู้เทคนิคอะไรมากมาย แต่แค่ควบคุม User Requirement ให้อยู่หมัดก็พอ

เพราะคนที่เข้าใจในมนุษย์ จะไม่โดนแย่งงานโดยหุ่นยนต์

  • บางปัญหาที่ User เจอนั้นจะมีความคิดว่าเอามาปรับแก้ดีไหม? ให้ลองมาวัด Effort & Impact ในปัญหานั้นๆดู คือให้วัดว่าเราต้องใช้พลังงานใช้ทรัพยากร(Effort) มากไหมและผลตอบแทนหรือผลกระทบ(Impact) มันอยู่ในจุดที่เราพอใจแล้วหรือเปล่า เพราะเราไม่สามารถแก้ปัญหาของ User ทุกๆคนได้ เลือกแก้ปัญหาให้คนส่วนใหญ่มีความสุขในการใช้โปรดักส์เราก่อน
  • Uxer ที่ดีคือต้องช่างสังเกตุและไม่หยุดที่จะเรียนรู้

ถ้าจะเริ่มนำ Ux มาปรับใช้กับองค์กรหรือไม่รู้จะไกด์ทีมหรือโน้มน้าวหัวหน้ายังไงดี ลองอ่านบทความนี้ก็ได้ครับ สรุป UX Meetup : สร้างองค์กรแนวหน้า ผ่านแนวคิด UX Design


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

เหมือนเดิมครับของพี่ต้อง Karun Warapongsittikul และก็ทีมงาน UX Connext คุณสามารถติดตามงานแบบนี้ได้ที่เพจเขาเลย และทุกๆคนที่มีส่วนเกี่ยวข้อง ขอบคุณสปอนเซอร์และสถานที่ HANGAR Coworking Space ด้วยฮะ

ขอบคุณครับ

Posted by
Chanala Wilangka

กำลังพยายามเป็นนักออกแบบ

Leave a Reply

Your email address will not be published. Required fields are marked *