จาก Conversation เล็กๆ ที่ต่างก็สงสัยว่าแต่ละคน แต่ละ scale ในไทยว่าเขา Initiate & manage design system กันยังไงนะ? ลุกลามจนเป็นชวนคนใน Community มานั่งแลกเปลี่ยนประสบการณ์กัน
ต้องขอบคุณทีมเหล่านี้เป็นอย่างมาก ที่ฝ่าจราจรยามเย็นมา Dinner discussion กันอย่างเป็นกันเอง ไล่ไปตั้งแต่ Scale 1–2 คนในทีม ไปจนถึงทีม 81 คน ไม่ว่าจะเป็น INFINITAS by Krungthai, KBTG, Agoda, Thoughtworks, NocNoc, MAQE, Axons, Conicle, Lineman x Wongnai, Ko-fi, Amity
Brainstorming ปัญหา ข้อสงสัย และสิ่งที่อยากชวนคุย
ปัญหา Top vote idation นั้นเทไปทางเรื่องของ Operation อย่างเห็นได้ชัด ย้ำเตือนความทรงจำจาก Meet up #0 Close Beta ว่า Thailand market ของเรากำลังมุ่งหน้าจาก Maturity level 2 → ไป Level 3 จริงๆ ตาม Ranking topic categories นี้
- Manage design artifacts/deliverables (level 2)
- Manage team (level 2)
- Influence (level 1–2)
- Measurement (level 3)
พร้อมทั้งหัวข้อ Top vote ที่คาดว่าชาว Design team ต่างๆ ก็คงเผชิญกับความท้าทายเหล่านี้อยู่ไม่น้อย
- Manage micro-copy to be consistent throughout products [10]
- Influence business and getting budget [7]
- How do designers who work on the same project sync up work inside the team? [7]
แต่ด้วยเวลาที่มีจำกัด จากกว่า 64 หัวข้อ Popular vote เหล่านี้จึงจำต้องถูกยกยอดไป Discuss กันในโอกาสหน้า (หากสนใจอยากร่วมแลกเปลี่ยน สามารถฝากช่องทางติดต่อไว้ที่ด้านล่างได้เลยครับ)
- Design token [7]
- Calculate design system ROIs [6]
- Maturity of design system [5]
- Onboarding VS Document [5]
- อื่นๆ สามารถดูในรายละเอียดจากรูปได้เลยครับ
จากนี้เราจึงอยากขอสรุป Conversation บางส่วนของเราไว้ ณ ที่นี่ เผื่อเป็นประโยชน์ของ Design Community ของไทยเรา
Manage micro-copy to be consistent throughout products
“Writer ≠ Translator” — by P’Bird Axons
ประโยคสั้นๆ ที่ Inspire พวกเราเอามาก หากคุณได้เคยประสบกับการ design แล้วไม่จบ ยังต้องพาลพบกับการแปลภาษาไปมา ไม่ว่าจะจาก UI ของเราหรือ Artifacts จากทีมอื่นๆ
ความท้าทายของปัญหานี้ ส่วนใหญ่เรามักเริ่มต้นด้วย Guideline และการ Educate & onboarding ให้คนอื่นๆ สามารถเข้ามามีส่วนร่วมในการเขียนและการ Review ได้ ในเบื้องต้น จากประสบการณ์ของทีมหลากหลาย Scale เราพบว่าการทำงานเชิงนี้ ได้ผลเป็นอย่างดีเมื่อต้องทำงานร่วมกับทีมอื่นๆ อย่าง Dev และ Marketing
และเรายังสามารถ Manage สิ่งเหล่านี้ได้ ไม่ว่าจะผ่าน 3rd parties tools/platform อย่าง Fortitude, Ditto, Sheet plug-in, หรือ Variants & Variable string ของทาง Figma โดยตรง ซึ่งช่วยลด Cognitive load ของ Researchers/designers และทีมอื่นๆ เป็นอย่างมาก แถมไม่แตกแถวด้วย — แต่ก็ยังคงต้องเผชิญกับ Effort ที่เพิ่มมาแม้จะ Manage ได้ดีและใกล้ชิดก็ตาม
อีก 1 วิธีที่น่าสนใจในการ Manage request ผ่านการทำ Request form ที่ Transfers ผ่านช่องทาง Slack ซึ่งการ Automate request นี้ช่วยลดภาระในการ Communicate แบบลักกะปิดลักกะเปิดเป็นอย่างมาก แต่แน่นอนว่าทีมก็อยู่ในระหว่างการเปลี่ยนผ่านของ Culture อยู่
พร้อมทั้งออกแบบกระบวนการ Review กับทีมอื่นๆ ผ่าน Tool อย่าง Figma โดยตรง ซึ่งช่วยลด Overhead communication จากหลากหลายช่องทาง Format การ Review & feedback รวมไปถึงการใช้ Consolidated writing นี้ยังช่วยให้ Designers แก้ไขงานได้ง่าย และยังเปิดโอกาสให้ Copywritor/UX writer หรือคนอื่นๆ เข้ามาแก้ไขได้อีกด้วย
แต่ในปัญหาถัดไปที่ท้าทายมากขึ้นคือเรื่องของ Localization (L10n) และ Internalization (I18n) ซึ่งทางทีม Agoda ได้แชร์ว่า การมี Baseline ที่เรายึดไว้เป็นหลักอย่าง American English นั้นช่วยให้ทุกอย่างง่ายขึ้น และยังสามารถอ้างอิง และสร้าง Guideline based on regions เข้ามาเสริมทัพอีกที
ทำอย่างไรดีกับการเพิ่ม Investment ในตัว Design System
โดยทั่วไปแล้วจากที่ฟังบทสนทนา คล้ายๆ กับว่าในแต่ละรูปแบบธุรกิจนั้นช่างแตกต่าง ไม่ว่าจะเป็น Large enterprise, consulting firm, agency, in-house team ทุกที่ล้วนเผชิญกับปัญหา ของดีที่ยั่งยืน แต่ยังไม่ตระหนักถึงการลงทุน เพราะโดยปกติเรามักมองใน Goals ระยะสั้น และปริมาณและหน้าตาของของที่จะออกไปมากกว่าเรื่องคุณภาพในระยะยาว และมันคงไม่เป็นไรหากเราตั้งใจจะ Launch ออกไปแล้วให้มัน Kill ตัวเองในไม่ช้า หรือเราสามารถรับความเสี่ยง และ Cost ที่จะเพิ่มขึ้นภายหลังจากการ Launch แล้ว ซึ่งนั่นคุ้มหรือไม่กับความเร็ว “คำตอบของตลาดตอนนี้คงเป็น YES” แต่แทบจะทุกครั้งที่เราพบว่า ไม่นานพวกเขาก็จะเผชิญกับการรื้อทำใหม่อีกรอบเพราะง่าย เร็ว และถูกกว่าการแก้ไขของที่สร้างไว้ แต่สุดท้ายแล้วมันยั่งยืน และคุ้มเงินจริงๆ หรือ?
วิธีต่างๆ ที่เราสามารถใช้ในการ Convince ให้ลงทุนเพิ่ม หรือหันมาสนใจใน Design system ได้นั้น มีหลากหลาย และมาก Detail เราจึงขอจัดออกมาเป็น Bullet แทนละกัน
- Time & speed: Lead time to market ของ Product ในระยะยาว
- การสะสมของ Cost & effort ในการ Develop product ทั้งในเชิง Dev และ Research & Design รวมไปถึง Dev and design debt
- Impact ของ Change request ในแต่ละครั้ง ตั้งแต่ Complexity, Difficulty, Recovery time
- Branding ที่เผชิญกับ Inconsistency และ Customer perception feedback
- Use case เล็กๆ จากการทำแบบเงียบๆ ของคนในทีม
- การเริ่มต้นเล็กๆ แต่เฉพาะเจาะจงไปที่ Metrics ที่ติดมากับ Component หรือ Flow นั้นๆ
- Pain points ของ Development team
- การสอดแทรก Design system ให้เป็น Sensible default ของ Contract
ทั้งนี้เราจะพบได้ว่าทีมที่ไปได้ไกล และมี System ที่เสถียรมักจะมี Dedicated design system team เสมอ พร้อมทั้งพวกยังสามารถปรับปรุงและมี Focus ต่อการทำงานระหว่าง ทีม Design กับทีมอื่นๆ รอบข้าง โดยเฉพาะ Dev
Working together ให้มีประสิทธิภาพ ในขณะที่ทีมเราโตขึ้นทุกวันๆ
Direction ที่พวกเราเห็นตรงกันเป็นอย่างยิ่งคือการพัฒนาทีมอย่างยั่งยืน นั่นหมายถึงการมองการไกล ไม่ว่าจะในมุมของทีมเอง มุมของตัวบุคคล หรือในตัวโครงสร้าง โดยในที่นี้เราต่างวัดผ่าน Metrics เหล่านี้
- 360º feedback
- Collaborating satisfaction rate on someone
- Team health
- Individual happiness
- Personal goals & KPIs
- Business thought
- Skillset
การ Sync up นั้นก็มีการแบ่งออกเป็น Layer ทั้ง Horizontal และ Vertical slice
Horizontal slice
- จากมุมมองของทีมโดยรวม ภาพกว้าง ที่ Head/Lead มักจะเป็นคนดูแล และยังมี session ให้ discuss อย่างสม่ำเสมอ
- Team/Squad lead ที่คอยดูทีมอย่างใกล้ชิด และ Sync กันเองทุก week เพื่อแชร์ข้อมูล ข่าวสาร และความช่วยเหลือกันระหว่าง Product teams
- Monthly or weekly sync up สำหรับทุกคนที่จะมาคอยอัพเดทเรื่องราวใน Zone research & design ร่วมกัน เพื่อตกลง Principle, Culture และ Make decision บางอย่างร่วมกัน
Vertical slice
- Across-check by self working team
- Authority in decision making ซึ่งนอกจากจะเพิ่มประสิทธิภาพและความคล่องตัวจากการแบ่งอำนาจในการตัดสินใจและ Supporting model เวลาในแต่ละขั้นปฏิบัติการไม่สามารถทำได้เอง แถมลดปัญหาในการรอ และการคอขวด จากผู้นำชั้นด้านบนอีกด้วย เพื่อเสริมสร้างให้เราต่างคิดและตัดสินใจได้ด้วยมาตรฐานและความเข้าใจเดียวกัน
ทั้งนี้ ส่วนที่สรุปมาคร่าวๆ เป็นส่วนหนึ่งของการสนทนาตลอด 2–3 ชั่วโมงที่สนุกมาก อย่างไรก็ดีสิ่งที่สำคัญนั้นไม่ใช่ว่า Practice ใดถูกผิด แต่มันคือการปรับให้เข้ากับรูปแบบองค์กร และทีมของคุณ หรือเรียกได้ว่า Based on your context และการใช้แนวคิดแบบ Organizational desin
สุดท้ายนี้นอกจากขอบคุณผู้ร่วมสนทนาแล้ว การที่เราได้มาเจอกัน แลกเปลี่ยน และรับรู้เรื่องราวและปัญหา ทำให้เรารู้ว่าเราไม่ได้ประสบปัญหาเพียงคนเดียว และการที่เราช่วยทีมเพื่อนร่วมวงการ ยังสามารถช่วยกันยกระดับ Thai design community ไปข้างหน้าพร้อมกันอีกด้วย
“ทุกที่นั้นมี Ops เป็นของตนเองอยู่แล้ว แต่คำถามคือหน้าตาของ Ops คุณนั้นเป็นอย่างไรกันแน่?”
เพื่อการส่งเสริมและผลักดัน Design community เราได้จัดทำ ✏️ Survey, Initial maturity landscape of research & design survey by Opsian ด้วย Data และ Insights ที่เราจากการตอบ Survey 5–10 นาที นี้จะช่วยให้เราสามารถวาดเส้น Landscape of excellent operation in Thailand ได้ และยังช่วยให้เรา Opsian, designOps practitioner community และ partners ของเรา ได้รับข้อมูลเพื่อนำกลับมาสร้างคุณค่าให้กับพวกเราได้อย่างตรงเป้าหมายขึ้น
