วาง ‘Design Tokens’ ยังไง ให้เข้ากับโปรดักส์โรดแมป

หลายคนอาจคุ้นกับคำว่า Design Tokens ในฐานะระบบที่ใช้จัดเก็บตัวแปรต่างๆ เช่น spacing สี และตัวอักษร เพื่อให้ทีม UI Design และทีม Developer ทำงานบนข้อมูลเดียวกันอย่างราบรื่น

แต่ในโลกการทำงานจริง การทำให้ tokens ถูกใช้งานได้จริงในโปรดักชันนั้นซับซ้อนกว่าการสร้าง Figma library แล้วส่งต่อให้ dev อย่างมาก โดยเฉพาะในบริบทที่ roadmap เปลี่ยนเร็วและเดดไลน์ถูกขับเคลื่อนตลอดเวลา

บทความนี้ ขอแชร์มุมมองของผู้นำทีม UX/UI ที่ต้องวางระบบให้ทีมสามารถออกแบบงานที่รองรับการเติบโตได้จริง โดยไม่หลุดจากไทม์ไลน์ของโปรดักส์

Design Tokens คือการลงทุนระยะยาวที่ไม่สามารถเห็นผลได้ทันที : ในทีมที่ทุกคนมีงานในมืออยู่เสมอ การเริ่มทำ Design Tokens มักถูกมองว่าเป็นงานที่ “ยังไม่เร่งด่วน” และไม่เห็นผลในระยะสั้น จึงมักถูกลดความสำคัญลงเมื่อเทียบกับงานที่ต้องปล่อยให้ทันรอบ

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

เรียนรู้จากหลายแหล่ง แต่ปรับให้เหมาะกับบริบทของเราเอง : ศึกษาโครงสร้าง tokens จาก Atlassian, Material, Tailwind และระบบ open-source ต่างๆ รวมถึงการตั้งชื่อ การจัดหมวดหมู่ และการเชื่อมต่อกับ dev pipeline

จนได้ข้อสรุปว่า “แผนที่ดีที่สุดคือแผนที่เหมาะกับทีมของเรา” เลือกอิงโครงสร้าง Tailwind เพราะ dev ใช้อยู่แล้ว และใช้ plugin บน Figma พร้อม export เป็น JSON เพื่อให้ dev ใช้งานได้ทันที ลดการส่งงานแบบ manual

Pilot Project คือจุดเริ่มต้นที่ทำให้ทีมเห็นคุณค่าของ Tokens : นำ tokens ไปใช้กับ internal project ที่ทีมเราดูแลเอง เพื่อสร้าง use case ที่จับต้องได้และใช้เป็นตัวอย่างเพื่อสื่อสารกับผู้บริหารและทีมอื่นว่าระบบนี้ช่วยให้ “งานส่งไวขึ้น แก้ง่ายขึ้น และต่อยอดการทำงานได้อย่างมีประสิทธิภาพ” ผลที่ได้คือ dev implement ได้เร็วขึ้น ดีไซน์ไม่ต้องแก้ซ้ำ และ UI มี ความสม่ำเสมอแม้จะมีหลายคนทำงานร่วมกัน

วิธีที่ทำให้ Tokens อยู่ใน Roadmap จริง ฝัง tokens เข้าไปใน feature ที่กำลังพัฒนาแทนการแยก sprint พิเศษ เช่นออกแบบ UI card เพื่อจัดระเบียบ color, spacing, shadow ให้เป็น tokens, แก้ UI เดิมแล้วชวน dev ทำ refactor พร้อมใช้ tokens เพื่อลด design drift, เปลี่ยน CI ลูกค้า โดยปรับ tokens ครั้งเดียวได้ทั้งระบบ ไม่ต้อง re-design ใหม่

พร้อมทั้งวางภาษากลางกับ dev โดยอิงจากหลักการ tailwind เช่น scale-0.5 = 2px, scale-1 = 4px และเชื่อมระบบด้วย Tokens Studio และ Style Dictionary เพื่อให้ export เป็นโค้ดได้ทันที ลดการทำงานที่ไม่สอดคล้องกันระหว่างทีม

Validation: Tokens ลดเวลาได้จริง : ลองเปรียบเทียบ feature ที่ใช้ tokens กับที่ยังไม่ใช้ พบว่าใน design phase มีเวลาเฉลี่ยลดลงประมาณ 10% ต่อ 1 FTE และยังได้ผลลัพธ์อื่นๆ เช่น การสื่อสารเร็วขึ้น งานเป็นระเบียบขึ้น แก้งานง่ายขึ้น และขยายโปรเจกต์ใหม่–เก่าได้ไวกว่าเดิม

สำหรับสิ่งที่ได้เรียนรู้จากกระบวนการนี้คือ Tokens ไม่ควรถูกแยกออกเป็น sprint พิเศษ แต่ควรถูกฝังในงานจริง, การตั้ง convention ร่วมกับ dev ตั้งแต่ต้นช่วยลด friction อย่างมาก, ระบบไม่จำเป็นต้องสมบูรณ์ก่อนเริ่มใช้ เพราะ Design System ต้องพัฒนาไปพร้อมกับ product เสมอ

โดยสรุปแล้ว Design Tokens ที่ดีไม่ใช่แค่เรื่องของ Figma หรือโค้ด แต่คือกลยุทธ์ที่ทำให้ทีมทำงานได้เป็นระบบและขยายได้ในระดับโปรดักส์ แม้จะไม่เห็นผลใน sprint แรก แต่จะคืนทุนชัดเจนใน sprint ถัดๆ ไป โดยเฉพาะเมื่อมีการเปลี่ยน CI, เปลี่ยน dev หรือเร่งปล่อยฟีเจอร์

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

โดย : อ้อมตะวัน มั่งคั่ง ผู้จัดการทีม UX/UI Design บริษัท เซอร์ทิส จำกัด