วาง Design Tokens ยังไงให้เข้ากับ Product Roadmap จริง
- Omtawan Mangkang
- 4 วันที่ผ่านมา
- ยาว 2 นาที
บทเรียนจากการจัดการทีม UX/UI
หลายคนอาจคุ้นกับคำว่า Design Tokens ว่าเป็นระบบสำหรับจัดเก็บตัวแปรต่าง ๆ ในการออกแบบ เช่น ขนาดของ spacing สี และตัวอักษร เพื่อให้ทีม UI Design และทีม Developer สามารถใช้ค่าเดียวกันได้อย่างสอดคล้องและลดความซ้ำซ้อน แต่ในโลกแห่งความเป็นจริง กว่าที่ระบบ tokens จะถูกนำไปใช้งานจริงใน production โดยเฉพาะในบริบทที่ roadmap เปลี่ยนทุกเดือน และ deadline ขับเคลื่อนทุกการตัดสินใจ สิ่งนี้กลับเต็มไปด้วยความท้าทายมากกว่าการสร้าง Figma library แล้วส่งให้ dev ใช้
ในบทความนี้ เราอยากแชร์ประสบการณ์จากมุมของผู้นำทีม UX/UI ที่ต้องวางกลยุทธ์ ออกแบบระบบ และทำให้ทีมดีไซน์สามารถผลิตงานที่สามารถขยายและรองรับการเติบโตได้อย่างมีมาตรฐาน โดยไม่หลุดจาก product timeline
Design Tokens คือการลงทุนระยะยาวที่ไม่เห็นผลทันที
พูดในฐานะคนทำจริง การเริ่มทำ Design Tokens ดูเหมือนเป็น “งานที่ใหญ่เกินตัว” ในบริบทที่แต่ละคนในทีมมี project on hand แทบตลอดเวลา การหยิบ Design Tokens ขึ้นมาทำ อาจดูเป็นภาระเพิ่มเติมที่ไม่ได้เร่งด่วนหรือเห็นผลชัดในระยะสั้น
การลงทุนในสิ่งที่ “ไม่ออกหน้า” อย่างนี้ จึงมักถูกมองว่า “ไม่ใช่ priority” โดยเฉพาะเมื่อเทียบกับงานที่ต้องปล่อยให้ทัน deadline
แต่สิ่งที่ทำให้เราตัดสินใจเดินหน้าคือ เราเห็นว่า Tokens คือเครื่องมือเชิงระบบที่จะช่วยให้ product ขยายตัวและเติบโตได้อย่างมีประสิทธิภาพ และเป็นโครงสร้างที่ทำให้ทีมออกแบบทำงานเร็วขึ้นในระยะยาวโดยไม่ต้องกลับมาแก้ไขโค้ดหรือดีไซน์ซ้ำ ๆ ทุกครั้งที่มีการเปลี่ยน CI หรือขยายฟีเจอร์
เรียนรู้จากหลายแหล่ง แต่กำหนด definition ให้เหมาะกับเรา
ก่อนจะลงมือทำ เรากับทีมได้ศึกษาระบบ Design Tokens จากหลายบริษัท เช่น Atlassian, Material, Tailwind รวมถึงแนวทางจาก community และ open-source system ต่าง ๆ จากนั้นจึงเรียนรู้เรื่องการตั้งชื่อ การจัดหมวดหมู่ การเชื่อมต่อกับ dev pipeline พร้อมทั้งลองปรับใช้ให้เหมาะกับบริบทของเราเอง
สิ่งที่เราได้เรียนรู้คือ: "แผนงานที่ดีที่สุดคือแผนที่เหมาะกับบริบทและทีมของเรา" ไม่จำเป็นต้องลอกใครมาใช้แบบตรงตัวหรือทำตามสูตรสำเร็จ เพราะแต่ละทีมมีความต้องการและข้อจำกัดที่ต่างกัน
เช่น:
เราอิงการตั้ง tokens จากโครงสร้างของ Tailwind CSS เพราะ dev ฝั่งเราใช้อยู่แล้ว
เราเลือกใช้ plugin บน Figma + export format ที่ dev ใช้งานได้เลย เช่น JSON เพื่อลด manual handoff และ speed up การ implement
Pilot Project คือจุดเริ่มที่เปลี่ยนความคิดของทีม
เราเริ่มจาก internal project ที่ทีมเราเป็นเจ้าของเต็มตัว ซึ่งกลายเป็น pilot สำหรับทดลองใช้ Design Tokens อย่างจริงจัง โดยมีเป้าหมายคือ
สร้าง use case ที่จับต้องได้
ใช้เป็นตัวอย่างเพื่อสื่อสารกับผู้บริหารและทีมอื่นว่า tokens ไม่ใช่งาน “system” ที่จับต้องไม่ได้ แต่มันทำให้งาน “ส่งไวขึ้น แก้ง่ายขึ้น และขยายการทำงานได้จริง”
ผลลัพธ์คือ:
ทีม dev สามารถ implement ได้เร็วขึ้น
ทีม Designer ทำงานต่อได้โดยไม่ต้องแก้ซ้ำ
UI มี consistency แม้จะมีหลายคนทำงานร่วมกัน
วิธีที่เราทำให้ Tokens ฝังอยู่ใน Roadmap
1. ฝัง Tokens เข้าไปใน Feature จริง ไม่แยกออกเป็น sprint พิเศษ
แทนที่จะสร้าง epic แยกเฉพาะ tokens เราเลือก “แทรก” tokens เข้าไปในแต่ละ feature ที่กำลังขึ้น dev อยู่แล้ว เพื่อให้การทำ tokens กลายเป็นส่วนหนึ่งของการพัฒนา product ไม่ใช่งานข้างเคียง
ตัวอย่าง:
ออกแบบ UI card เพื่อใช้โอกาสนี้จัดระเบียบ color, spacing, shadow, radius เป็น tokens
แก้ UI เดิม เพื่อชวน dev ทำ refactor พร้อมใช้ tokens เพื่อลด design drift
เปลี่ยน CI ลูกค้า เพื่อปรับ tokens ได้ทั้งระบบ ไม่ต้อง re-design ใหม่
2. สร้างภาษากลางร่วมกับ Dev ตั้งแต่ต้น
เราวาง convention ร่วมกับ dev โดยอิงจากโครงสร้างของ tailwind เช่น
size/scale-0.5 = 2px size/scale-1 = 4px size/scale-2 = 8px จากนั้นเรานำ tokens ไปเชื่อมกับระบบจริงด้วยเครื่องมืออย่าง Tokens Studio และ Style Dictionary เพื่อ export เป็น format ที่ dev ใช้งานได้ทันที ลด manual task และ misalignment ระหว่างทีม
Validation: Tokens ไม่ใช่แค่แนวคิด แต่ช่วยลดเวลาได้จริง
เพื่อให้เห็นผลลัพธ์ชัดเจน เรา validate โดยเปรียบเทียบระหว่าง feature ที่ใช้ tokens กับ feature ที่ยังไม่ได้ใช้
ในระยะเวลาเท่ากันของ design phase → Tokens ช่วยลดเวลาทำงานลงได้ประมาณ 10% ต่อ 1 FTE
หมายเหตุ: ตัวเลขนี้ได้จาก 1 feature เรายังมีแผนจะ validate เพิ่มอีก 2 feature เพื่อให้ได้ข้อมูลที่แม่นยำขึ้น
นอกจากเรื่องเวลา เราพบว่าทีมได้ benefit อื่น ๆ อย่างชัดเจน ได้แก่
งานมีระเบียบมากขึ้น
การสื่อสารระหว่าง Designer และ Developer รวดเร็วขึ้น
แก้งานได้เร็วขึ้น และไม่ซ้ำซ้อน
ขยายทั้งโปรเจกต์ใหม่และโปรเจกต์เดิมได้ง่าย
สิ่งที่เราได้เรียนรู้จากกระบวนการนี้
Tokens ไม่ควรถูกแยกออกไปเป็น sprint พิเศษ แต่ควรถูก “ฝัง” อยู่ในงานจริงและ roadmap จริง
การตั้ง convention ร่วมกับฝั่ง dev ตั้งแต่เริ่มต้น สามารถลด friction ได้อย่างมหาศาล
อย่ารอให้ระบบสมบูรณ์แบบก่อนค่อยเริ่ม rollout เพราะ Design System ไม่มีคำว่า “เสร็จ” มันต้อง evolve ไปพร้อมกับ product เสมอ
สรุป
Design Tokens ที่ดีไม่ใช่แค่เรื่องของ Figma หรือโค้ด แต่มันคือกลยุทธ์ในการสร้างระบบงานที่มีมาตรฐานและสามารถขยายการใช้งานได้ในระดับ product
การลงทุนกับ tokens อาจไม่เห็นผลใน sprint แรก แต่จะเริ่มคืนทุนใน sprint ที่ 3, 5 และ 10 เมื่อทีมของคุณ้เมื่อทีมต้องเปลี่ยน CI ลูกค้า เปลี่ยน dev หรือเร่ง launch ฟีเจอร์ให้เร็วกว่าเดิม
หนึ่งในโปรเจกต์ที่เราได้ประยุกต์ใช้ Design Tokens อย่างเป็นทางการคือ Sertis KMAI / Private LLM ซึ่งเป็นแพลตฟอร์มผู้ช่วยอัจฉริยะสำหรับองค์กรที่เชื่อมต่อข้อมูลภายในกับ AI ได้อย่างปลอดภัยและตรงจุด ทีมของเรารับผิดชอบ UX/UI design และวางระบบ tokens ให้พร้อมสำหรับการใช้งานจริงในระดับ enterprise
สนใจดูว่า KMAI ทำอะไรได้บ้าง? อ่านเพิ่มเติมได้ที่นี่ → Sertis KMAI เครื่องมือ AI ยกระดับการจัดการข้อมูลในองค์กรแบบครบวงจร
Design Tokens อาจดูเหมือนงานระบบที่อยู่เบื้องหลัง แต่เมื่อทำถูกจุด มันสามารถเป็นตัวเร่งการพัฒนา product และเพิ่มความเชื่อมั่นให้กับทีมได้อย่างชัดเจน
ถ้าคุณกำลังมองว่า tokens เป็นงานแถม ลองเปลี่ยนมุมมอง เพราะมันอาจเป็นเครื่องมือที่ทำให้ทั้งทีมเดินไวขึ้น และ product ไปได้ไกลกว่าเดิม
