เก็บข้อมูล 28 ส.ค. 2569
คำว่า Design System ฟังดูเหมือนเรื่องของฝ่ายดีไซน์ และเป็นเรื่องที่คนเขียนโค้ดกับคนที่ไม่ได้อยู่สายเทคไม่จำเป็นต้องรู้
ผมคิดว่าข้อนั้นเปลี่ยนไปแล้ว ด้วยเหตุผลสองข้อที่เกิดขึ้นภายในปีเดียว คือรูปแบบไฟล์กลางของ design token ออกเวอร์ชันเสถียรตัวแรกเมื่อ 28 ตุลาคม 2025 1 และไฟล์ดีไซน์เริ่มถูกอ่านโดย AI agent ได้โดยตรง 5
ถ้าจะให้จำอย่างเดียว ให้มองมันเป็นสูตรกลางของร้านอาหารที่มีหลายสาขา ทุกสาขาทำรสเดียวกันได้เพราะมีสูตรเขียนไว้ ไม่ใช่เพราะเชฟทุกคนจำรสได้ตรงกัน
บทความนี้อธิบายด้วยภาพสามภาพ ไม่ต้องมีพื้นฐานด้าน UX และไม่ต้องเขียนโค้ดเป็นก็อ่านได้
Design system ไม่ใช่คลังรูป แต่คือชุดการตัดสินใจที่เขียนไว้ล่วงหน้า
ความเข้าใจผิดที่พบบ่อยที่สุดคือคิดว่ามันคือโฟลเดอร์เก็บไฟล์ภาพ หรือหน้าตาเว็บที่วาดไว้แล้ว
ถ้าจะให้นิยามสั้นที่สุด มันคือการตัดสินใจเรื่องหน้าตาและพฤติกรรมของผลิตภัณฑ์ ที่ตกลงกันไว้ล่วงหน้าและเขียนลงในที่ที่ทั้งคนและเครื่องอ่านได้
สี่ชั้นนั้นคืออะไร
| ชั้น | ภาษาชาวบ้าน | ในสูตรอาหาร | ตัวอย่างที่จับต้องได้ |
|---|---|---|---|
| Design tokens | ค่าที่เล็กที่สุด ที่ไม่แตกย่อยไปกว่านี้ | ปริมาณวัตถุดิบที่ชั่งไว้แล้ว | สีปุ่มหลักคือ #E8590C ระยะห่างมาตรฐานคือ 16px |
| Components | ของที่ประกอบจาก token แล้วเอาไปใช้ซ้ำได้ | เมนูหนึ่งจาน | ปุ่ม ช่องกรอกข้อมูล การ์ด |
| Patterns | วิธีเอา component มาต่อกันเป็นงานหนึ่งชิ้น | เซ็ตอาหารหนึ่งชุด | ฟอร์มสมัครสมาชิก หน้าชำระเงิน |
| Guidelines | กฎว่าเมื่อไหร่ใช้อะไร และเมื่อไหร่ห้ามใช้ | เมนูไหนห้ามเสิร์ฟคู่กัน | ปุ่มสีแดงใช้เฉพาะการกระทำที่ย้อนกลับไม่ได้ |
อ่านแบบผู้บริหารองค์กร ประโยชน์ที่วัดได้ของสิ่งนี้ไม่ใช่ความสวย แต่คือการลดจำนวนครั้งที่ทีมต้องตัดสินใจเรื่องเดิมซ้ำ ทุกครั้งที่ไม่มีคำตอบเขียนไว้ ใครสักคนต้องเดา แล้วอีกคนต้องมารีวิวสิ่งที่เดา และรอบนั้นเกิดขึ้นทุกหน้าจอ ทุกสัปดาห์ สิ่งที่ design system ตัดออกคือรอบพวกนั้น ไม่ใช่เวลาวาดรูป
ทำไมชั้นล่างสุดถึงเป็นชั้นที่คนข้าม
Guidelines คือชั้นที่เขียนยากที่สุด เพราะมันต้องระบุข้อห้าม ไม่ใช่แค่ตัวเลือก และข้อห้ามเป็นสิ่งที่ต้องมีคนกล้าตัดสินใจ
อ่านแบบผู้บริหารองค์กร องค์กรที่ลงทุนทำ design system แล้วรู้สึกว่าไม่ได้อะไร มักหยุดอยู่ที่สองชั้นบน คือมี token กับ component แต่ไม่มีใครเขียนว่าเมื่อไหร่ควรใช้อะไร ผลคือทีมยังเถียงกันเหมือนเดิม เพียงแต่เถียงด้วยของที่สวยขึ้น ถ้าจะตรวจว่าระบบของเราไปถึงไหนแล้ว ให้ถามหาเอกสารข้อห้าม ไม่ใช่ถามหาไลบรารี component
Design token คือจุดที่ดีไซน์กลายเป็นของที่โค้ดอ่านได้
นี่คือชั้นที่ทำให้เรื่องนี้กลายเป็นเรื่องของคนเขียนโค้ด
Design token คือการเก็บค่าหนึ่งค่าไว้ในที่เดียว แล้วให้ทุกที่อ้างถึงชื่อของมันแทนที่จะเขียนค่าซ้ำ แทนที่จะมีคำว่า #E8590C กระจายอยู่ในไฟล์ 40 ที่ ก็มีชื่อเดียวคือ color.brand.primary และค่าจริงอยู่ที่เดียว
สิ่งที่เพิ่งเปลี่ยนในปีที่ผ่านมา
| รายการ | สถานะ |
|---|---|
| ชื่อข้อกำหนด | Design Tokens Format Module |
| เวอร์ชันเสถียรตัวแรก | 2025.10 ประกาศ 28 ตุลาคม 2025 1 |
| องค์กรที่หนุนหลัง | มากกว่า 24 ราย รวมถึง Adobe, Google, Meta และ Figma 1 |
| เครื่องมือที่รองรับ | Figma, Penpot, Sketch, Tokens Studio, Style Dictionary, Terrazzo และอื่น ๆ 8 |
| สัดส่วนทีมที่ใช้ token | 84% จากผลสำรวจของ zeroheight ราว 300 คน เพิ่มจาก 56% ในปีก่อนหน้า 8 |
อ่านแบบผู้บริหารองค์กร ตัวเลขที่ผมให้น้ำหนักคือการขยับจาก 56% เป็น 84% ภายในหนึ่งปี ไม่ใช่เพราะตัวเลขสูง แต่เพราะความเร็ว การกระโดดขนาดนี้แปลว่าสิ่งนี้ผ่านช่วงเป็นของใหม่ไปแล้ว และกำลังกลายเป็นสิ่งที่คู่ค้าและผู้สมัครงานสมมติว่าเรามี ข้อควรระวังคือผลสำรวจนี้ถามคนที่อยู่ในวงการนี้อยู่แล้ว ตัวเลขจริงทั้งอุตสาหกรรมย่อมต่ำกว่านี้
ข้อที่คนเรียกผิดกันทั้งวงการ
หลายคนเรียกสิ่งนี้ว่า "มาตรฐาน W3C" ซึ่ง ไม่ถูกต้อง เอกสารระบุไว้เองว่ามันเผยแพร่โดย Community Group ไม่ใช่ W3C Standard และไม่ได้อยู่บนเส้นทางสู่การเป็นมาตรฐาน 24
อ่านแบบผู้บริหารองค์กร ความต่างนี้มีผลจริงตอนเขียนสัญญาหรือข้อกำหนดการจัดซื้อ การเขียนว่าผู้รับจ้างต้องส่งมอบตามมาตรฐาน W3C สำหรับ design token คือการอ้างถึงสิ่งที่ไม่มีอยู่ สิ่งที่มีอยู่และอ้างได้จริงคือชื่อและเวอร์ชันของเอกสาร คือ Design Tokens Format Module เวอร์ชัน 2025.10 ซึ่งเจาะจงกว่าและตรวจรับได้จริงกว่า
Design to Code ไม่ได้แปลว่า AI เขียนหน้าจอให้
นี่คือส่วนที่ถูกเล่าเกินจริงมากที่สุด และเป็นเหตุผลที่คนไม่ใช่สายเทคควรอ่านต่อ
สิ่งที่มันทำจริง
Figma มีตัวกลางที่เรียกว่า MCP server ซึ่งเปิดไฟล์ดีไซน์ออกมาเป็นข้อมูลที่เครื่องอ่านได้ แล้วส่งให้ AI agent ที่กำลังเขียนโค้ดอยู่ สิ่งที่ส่งไปคือ ชื่อ component ข้อจำกัดของเลย์เอาต์ ค่าระยะห่าง สไตล์ตัวอักษร และโครงสร้างเลเยอร์ทั้งไฟล์ 5
และตอนนี้มันทำงานสองทางแล้ว คือดันหน้าจอที่เขียนเป็นโค้ดแล้วกลับเข้าไปเป็นเฟรมที่แก้ไขได้ใน Figma 7
อ่านแบบผู้บริหารองค์กร คำที่ควรจับในย่อหน้าข้างบนคือ ชื่อ component และ ค่าระยะห่าง เพราะทั้งสองอย่างจะมีก็ต่อเมื่อมี design system อยู่แล้ว ไฟล์ดีไซน์ที่วาดด้วยกล่องสี่เหลี่ยมไม่มีชื่อ ส่งอะไรให้ agent อ่านก็ได้แค่กล่องสี่เหลี่ยม พูดอีกแบบคือ มูลค่าของ Design to Code ไม่ได้ขึ้นกับความฉลาดของ AI แต่ขึ้นกับความเป็นระเบียบของไฟล์ที่เรามีอยู่แล้ว ใครที่กำลังตัดสินใจว่าจะลงทุนอะไรก่อน ข้อนี้ตอบให้แล้ว
ตัวเลขที่ควรอ่านอย่างระวัง
มีรายงานว่าหน้าจอแดชบอร์ดที่มี component ซับซ้อน 8 ตัว ซึ่งเคยใช้เวลา 2 ถึง 3 วัน ทำเสร็จได้ในบ่ายเดียว และรอบการแก้ลดจาก 4 ถึง 5 รอบเหลือรอบเดียว
ตัวเลขชุดนี้มาจากบทความของผู้ให้บริการและผู้ใช้งาน ไม่ใช่การทดลองที่มีกลุ่มควบคุม และไม่ระบุว่าไฟล์ดีไซน์ตั้งต้นเป็นระเบียบแค่ไหน ซึ่งเป็นตัวแปรที่สำคัญที่สุดตามที่เพิ่งอธิบายไป
อ่านแบบผู้บริหารองค์กร เวลาเจอตัวเลขทำนองนี้ในการนำเสนอ คำถามเดียวที่คุ้มถามคือ ของตั้งต้นในการทดลองนั้นเป็นระเบียบระดับไหน เพราะถ้าเขาเริ่มจากไฟล์ที่มี design system สมบูรณ์ ตัวเลขนั้นไม่ใช่ผลของเครื่องมือ แต่เป็นผลของงานที่ทำไว้ก่อนหน้าหลายเดือน และเป็นงานที่องค์กรเรายังไม่ได้ทำ
สิ่งที่ยังไม่จริง และคำถามที่ควรถามก่อนเริ่ม
สิ่งที่ยังเป็นงานของคน
ในภาพที่สามมีกล่องเส้นประอยู่มุมล่าง ซึ่งเป็นส่วนที่ไม่มีเครื่องมือไหนทำแทนได้ ถ้ากลับไปที่สูตรอาหาร สูตรบอกวิธีทำได้ แต่ไม่ได้บอกว่าวันนี้ควรขายอะไร
- ตัดสินใจว่าหน้านี้ควรมีอะไรบ้าง และอะไรไม่ควรมี
- ตัดสินใจว่าอะไรสำคัญกว่าอะไร เมื่อพื้นที่บนจอมีจำกัด
- ตัดสินใจว่าเมื่อไหร่ควรแหกกฎของตัวเอง
อ่านแบบผู้บริหารองค์กร ทั้งสามข้อเป็นการตัดสินใจเรื่องคุณค่า ไม่ใช่เรื่องเทคนิค และเป็นเหตุผลที่ผมคิดว่าคำว่าแทนที่ดีไซเนอร์เป็นการอ่านสถานการณ์ผิด สิ่งที่เกิดขึ้นจริงคืองานส่วนที่แปลงดีไซน์เป็นโค้ดถูกบีบให้ถูกลง ส่วนงานที่ตัดสินใจว่าจะสร้างอะไรกลับมีสัดส่วนมากขึ้นในต้นทุนรวม ซึ่งเปลี่ยนว่าเราควรจ้างใครและควรวัดผลงานเขาด้วยอะไร
สามคำถามก่อนอนุมัติงบ
| คำถาม | ทำไมถึงถาม |
|---|---|
| ตอนนี้ค่าสีเดียวกันถูกเขียนไว้กี่ที่ | ถ้าตอบไม่ได้ แปลว่ายังไม่มี token และนั่นคือสิ่งที่ต้องทำก่อน |
| มีเอกสารข้อห้ามหรือยัง | ถ้ามีแต่ไลบรารี component แปลว่าระบบยังไม่ครบและจะไม่ลดการเถียง |
| ใครเป็นเจ้าของเมื่อดีไซน์กับโค้ดไม่ตรงกัน | ถ้าไม่มีคนตอบ เครื่องมือสองทางจะทำให้ทั้งสองฝั่งเขียนทับกันเงียบ ๆ |
อ่านแบบผู้บริหารองค์กร คำถามที่สามคือคำถามที่ผมคิดว่าถูกมองข้ามมากที่สุด เพราะเครื่องมือที่ส่งข้อมูลได้สองทางเป็นเรื่องดีตอนสาธิต แต่ในองค์กรจริงมันสร้างคำถามใหม่ที่ไม่เคยต้องตอบมาก่อน คือเวลาไฟล์ดีไซน์กับโค้ดขัดกัน ใครถูก ถ้าไม่ตอบข้อนี้ไว้ก่อน สิ่งที่ได้คือความเร็วในการทำให้ทั้งสองฝั่งไม่ตรงกันเร็วขึ้น
ภาคผนวก
ศัพท์เฉพาะ
| คำ | ความหมาย |
|---|---|
| Design system | ชุดการตัดสินใจเรื่องหน้าตาและพฤติกรรมของผลิตภัณฑ์ ที่ตกลงและเขียนไว้ล่วงหน้า |
| Design token | ค่าตั้งต้นที่เก็บไว้ที่เดียวแล้วอ้างด้วยชื่อ เช่นสี ระยะห่าง ขนาดตัวอักษร |
| Component | ชิ้นส่วนหน้าจอที่ใช้ซ้ำได้ ประกอบขึ้นจาก token |
| Pattern | วิธีเอา component หลายตัวมาต่อกันเป็นงานหนึ่งชิ้น |
| DTCG | Design Tokens Community Group กลุ่มที่ร่างรูปแบบไฟล์กลางของ token |
| Community Group | กลุ่มทำงานภายใต้ W3C ที่ออกเอกสารได้ แต่เอกสารนั้นไม่ใช่มาตรฐาน W3C |
| Style Dictionary | เครื่องมือแปลงไฟล์ token กลางไปเป็นรูปแบบของแต่ละแพลตฟอร์ม |
| MCP | Model Context Protocol มาตรฐานเชื่อมโมเดลกับเครื่องมือและแหล่งข้อมูลภายนอก |
| Dev Mode | โหมดใน Figma ที่แสดงค่าต่าง ๆ ของดีไซน์ในรูปแบบที่คนเขียนโค้ดใช้ได้ |
| Code Connect | กลไกที่ผูก component ในไฟล์ดีไซน์เข้ากับ component จริงในโค้ด |
วิธีเก็บข้อมูลและข้อจำกัด
บทความนี้สรุปจากเอกสารทางการของ Design Tokens Community Group และ Figma พร้อมบทความรายงานที่ระบุไว้ในอ้างอิง เก็บข้อมูล 28 ส.ค. 2569 ภาพประกอบทั้งสามสร้างขึ้นเองจากเนื้อหาในบทความ ไม่ได้นำมาจากแหล่งใด
- ผมไม่ได้ทำ design system ขนาดองค์กรด้วยตัวเอง บทความนี้เป็นการอธิบายแนวคิดและสถานะของเครื่องมือ ไม่ใช่บันทึกจากการลงมือทำ
- ตัวเลข 84% มาจากผลสำรวจที่ถามผู้ที่อยู่ในแวดวง design system อยู่แล้ว ราว 300 คน จึงเอนไปทางสูงกว่าค่าจริงของทั้งอุตสาหกรรม และไม่มีข้อมูลว่ามีผู้ตอบจากไทยหรือไม่
- ตัวเลขเรื่องเวลาที่ลดลงมาจากบทความของผู้ให้บริการและผู้ใช้งาน ไม่ใช่การทดลองที่มีกลุ่มควบคุม ไม่ควรนำไปใช้ตั้งเป้าโดยตรง
- เครื่องมือในหมวดนี้เปลี่ยนเร็วมาก ความสามารถที่ระบุไว้เป็นสถานะ ณ วันที่เก็บข้อมูล และอาจต่างไปภายในไม่กี่เดือน
- บทความนี้ไม่ได้เปรียบเทียบเครื่องมือรายตัว และไม่ได้แนะนำให้ใช้ผู้ให้บริการรายใด