Design tokens คืออะไร? มาอ่านบทความนี้กัน

สวัสดีค่าทุกคน วันนี้นัทจะพาทุกคนมาทำความเข้าใจกับ Design tokens หนึ่งในหัวข้อที่มีคนถามกันเข้ามาเยอะที่สุดกับบทความของ Designil เป็นท็อปปิกที่เรียกว่ามาแรงเหลือเกินในช่วงไม่กี่ปีที่ผ่านมา อีกทั้งยังมาพร้อมกับฟีเจอร์ Variables ที่ Figma ได้ปล่อยออกมาอีกด้วย

ก่อนอื่นเลยต้องบอกทุกคนว่า Design tokens นี้เป็นความรู้ด้านการทำงาน UI (User interface) เป็นชื่อเรียกที่เราใช้แทนค่าตัวแปรตัวนึงที่ไว้ใช้เก็บค่าในการตัดสินใจการทำงานด้าน UI ต่าง ๆ ให้เราใช้ตรงกันทั้งฝั่งดีไซน์เนอร์และเดเวลล็อปเปอร์ เป็นความรู้พื้นฐานก่อนที่เราจะเริ่มต้นทำงาน User interface

ซึ่งองค์ความรู้ที่เรากำลังจะเล่าในบทความนี้ สามารถนำไปใช้ตั้งชื่อตัวแปรในฟีเจอร์ Figma Variables ของโปรแกรม Figma ที่ถูกพัฒนามาเพื่อรองรับการทำงานของ Design tokens ได้

ในปัจจุบันการทำงาน Design tokens มีเครื่องมือในการจัดการเชื่อมต่อตัวแปรที่ใช้ตัดสินใจในด้าน UI ไปกับโปรแกรมออกแบบและโค้ด เช่น Token Studios และทูลอื่น ๆ อีกเพียบ เดี๋ยวเราจะมาเล่าต่อเนื้อหาให้ในท้ายบทความนี้ค่า

บทความนี้จะเล่าแบบง่าย ๆ แบบไต่ระดับตั้งแต่ 0 ขึ้นไปเรื่อย ๆ เลยนะคะ มาดูกันเลยว่าจะมีอะไรบ้าง

Design tokens คืออะไร?

Design tokens คือ ตัวแปรที่ใช้เก็บการตัดสินใจในการออกแบบ UI (User interface) ขององค์กร เป็นชื่อเรียกที่ถูกออกแบบมาให้เข้าใจได้ง่าย เป็นตัวช่วยสื่อสารข้อมูลการออกแบบและทำงานร่วมกันระหว่าง Design และ Engineering ช่วยรองรับการเติบโตของ UI ในอนาคต

Design tokens ยังสามารถเก็บค่าต่าง ๆ ได้อีกมากมาย เช่น color, typography, object styles, animation, ฯลฯ โดยเราจะใช้ Design tokens (ชื่อตัวแปรที่ตั้งมาอย่างดี) แทนที่การเก็บค่าข้อมูลประเภท hard-coded ทั้งในไฟล์​ design และ code

ตัวอย่าง: เราจะไม่ใช้งานค่าสีแบบ hex code อย่างเช่น #FFFFFF ในระบบ เพื่อที่จะช่วยให้เราสามารถจัดการ UI แบบซับซ้อนและเพื่อให้รองรับการขยายงานของระบบ UI ได้ในอนาคต

นอกจากนี้ยังเป็นตัวแปรที่เราใช้แชร์กันระหว่าง Platform ได้อีก ไม่ว่าจะเป็น Web, iOS, Android โดยมีไฟล์ Design tokens เดียว ชื่อเดียวกัน และใช้ตรงกัน ทำให้เราสามารถอัปเดตสีได้ทุกแพลตฟอร์มพร้อมกัน พูดคุยภาษาเดียวกันทั้ง Designer และ Developer

ด้วยเทคโนโลยีของ Design tokens ช่วยเชื่อมต่อการทำงานระหว่าง Design tools (Figma) และ Development process ทำให้เราสามารถจัดการสไตล์ของการออกแบบ (design style), แบรนดิ้ง (branding) และ UI (User interface) ได้ง่ายขึ้น

ยกตัวอย่างเช่น สามารถส่งค่าสี, ตัวหนังสือ เป็นไฟล์ JSON ออกจาก Figma ไปยัง Github ได้เลยแบบอัตโนมัติ เพียงแค่กดปุ่ม หรือจะส่งโค้ดจาก Github กลับมายัง Figma ก็ทำได้เหมือนกัน

เรียกว่าช่วยจัดการด้าน style ต่าง ๆ ได้อย่างรวดเร็วและสะดวกสบาย ลดปัญหาการตบตีกันระหว่าง Designer กับ Dev เชื่อมต่อการส่งค่าการตัดใจระหว่างทีมงานได้อย่างรวดเร็ว และยังลดข้อผิดพลาดในการอัปเดตในอนาคตอีกด้วย

เรามี W3C specifications ที่เป็นมาตรฐานในการเขียนฟอร์แมตของไฟล์​ Design tokens สามารถอ่านได้จาก Design tokens community group (DTCG)

---

เคสตัวอย่างการทำงานในองค์กรที่มี Design tokens

ยกตัวอย่างเคส A

ในการทำ User inteface ที่เราจะเจอกันบ่อย ๆ คือการเปลี่ยนสีจากทางแบรนด์ เมื่อมีการเปลี่ยนสีเกิดขึ้น เช่น Instagram อยากจะเปลี่ยนสีจากสีน้ำตาล ให้กลายเป็นสีม่วงปี๊ดป๊าด

คนที่ทำงานฝั่ง UI ไม่ว่าจะเป็น Designer หรือ Developer จะต้องทำการอัปเดตสีของแบรนด์ได้อย่างรวดเร็วมากที่สุด ทั้งไฟล์ Figma และ ในไฟล์ของโค้ด การมี Design tokens จะทำให้การตัดสินใจการอัปเดตต่าง ๆ ที่มาจากฝั่ง Business หรือ Brand ส่งต่อไปยังหน้างานได้อย่างรวดเร็ว

ยิ่งถ้าหากมีการใช้งาน Design tokens (Adoption rate) สูง มีการใช้งาน tokens ที่ถูกต้องตรงกันทั้งระบบแล้ว นักพัฒนาในทีม Design system จะสามารถแก้ไขค่าสีได้จากทางฝั่งของ Design system ได้เลย โดยแก้ที่ตัวแม่ และตัวลูกก็จะเปลี่ยนดีไซน์ไปพร้อมกันเลย ทั้ง Web, iOS, Android หรือว่าแพลตฟอร์มอื่นๆ ที่ใช้โค้ดชุดเดียวกัน ทำให้ลดเวลาในการอัปเดตและลดเวลาในการการจัดการเรื่อง UI ในอนาคตได้อย่างมาก

ยิ่งถ้าหากเราตั้งชื่อให้มีความหมายเข้าใจได้ง่าย สื่อถึง component การแก้ไขก็จะสามารถทำได้ง่าย แค่แก้จากตัวแม่ ปุ่มที่เป็นสีน้ำตาลก็จะกลายเป็นสีม่วงปี๊ดป๊าดได้อย่างรวดเร็ว

ยกตัวอย่างเคส B

เช่น การทำธีมสีแบบ Light mode, Dark mode, High contrast mode ทำให้ผู้ใช้งานสามารถตั้งค่าหน้าจอของ UI ให้เหมาะสมกับการใช้ของตนเอง และยังตอบโจทย์ด้าน Accessibility ที่ดีด้วย

ยกตัวอย่างเคส C

ข้อดีของ Design tokens นั้นยังรองรับการทำงาน UI ใน Product ที่มีโครงสร้างแบบ Multi-theming, Multi-branding ตัวอย่างเช่น Product ที่มีหลายแบรนด์ย่อย อาทิ…

• การทำงานของ Spotify ที่มีการทำ UI สีของตัวเล่นเพลงบางหน้าให้เข้ากับธีมแบรนด์ของค่ายเพลง หรือ นักร้อง เป็นต้น

• Atlassian มีสินค้าอยู่ข้างในหลากหลายตัว เช่น Jira, Confluence, Trello, Loom, Bitbucket ฯลฯ แต่อยากจะมีการแชร์โครงสร้างของการตั้งชื่อตัวแปรที่คล้ายคลึงกัน แต่เปลี่ยนค่า values ออกไปในแต่ละแบรนด์ หรืออยากจะแชร์​ Design components ร่วมกัน

ยกตัวอย่างเคส D

Design tokens ช่วยให้การตัดสินใจในการทำงานแบบ Cross platforms ทำได้ง่าย เช่น หากเราต้องทำ UI ให้รองรับกับหลายหน้าจอ หลายสเกล เช่น จอโทรทัศน์ โทรศัพท์ สมาร์ตวอช หรือ หน้าจอแสดงผลต่าง ๆ

---

ตัวอย่างประเภทของ Design tokens

---

โครงสร้างของ Design tokens

Raw value – คือค่า hard coded ที่เราจะไม่ใช้งานกันใน UI เราจึงสร้าง Design tokens ในระดับต่าง ๆ ขึ้นมาเพื่อแทนที่ค่าเหล่านี้ และนำไปใช้งานใน UI ของเรา

1. Primitives (Tier 1) – ไว้ใช้อ้างอิง เพื่อเก็บตัวเลือกที่เรามีจำนวนมาก เช่น พาเลตสี
2. Semantic (Tier 2) – ใช้งานได้หลากหลาย เก็บการตัดสินใจทางด้านการออกแบบ
3. Component (Tier 3) – ค่อนข้างเฉพาะเจาะจงกับการใช้งาน

ชื่ออื่น ๆ ที่มักจะได้ยินกัน เช่น Atomic (Tier1)

การจัดเก็บลำดับขั้นของ Design tokens หลัก ๆ จะมีทั้งหมด 3 ระดับด้วยกัน และในแต่ละองค์กรจะมีการเรียกชื่อที่แตกต่างกัน ดังนั้นอาจจะต้องลงไปดูคู่มือของแต่ละบริษัทอีกครั้งว่าเขาเรียกว่าอะไร

ในบางครั้งบางบริษัทก็มีการจัดเก็บค่า Tier เหล่านี้ไม่เท่ากันด้วย เช่น บางบริษัทอาจจะมีแค่ Tier 2 แต่ข้อดีของการทำ component token (tier 3) ที่พิสูจน์แล้วว่ามีประโยชน์จริง คือ ช่วยให้เราสามารถทำงานแบบ automation ได้ง่ายขึ้น

อย่างของ Adobe เองก็ยังมีหลายระดับที่แยกย่อยลงไปอีก

นอกจากนี้แล้วโครงสร้างของ Design tokens ยังมีการเขียนได้อีกหลายแบบ ไม่ว่าจะเป็นแบบ…

Computational – เราสามารถคำนวนค่าใน value ที่ใช้งานใน design tokens ได้
เช่น “Calc({spacing-base}*1.5)” เช่น base เราอยู่ที่ 8 เราก็จะใช้สูตรคณิตศาสตร์คูณตัว base เข้าไป เพื่อให้ระบบคำนวนเลขที่เหลือให้โดยอัตโนมัติ

ยกตัวอย่างการใช้งาน Design tokens แบบ Computational กับ Token type ที่เป็นประเภท number ต่าง ๆ เช่น ค่าของตัวหนังสือ, ค่าสี ใช้คำนวนค่าสีที่ผ่านมาตรฐานของ Constrat ratio เพื่อให้รองรับ Accessibility, ค่า spacing เป็นต้น

Adaptive – เราสามารถสร้างชุดสีตาม mode ได้ เช่นใช้ชื่อระดับ semantic เดียวกัน
แต่ปรับสีจาก Light เป็น Dark

เช่นสีนี้ ในโหมด Light: อ้างอิงไปที่ color.blue.700
เช่นสีนี้ ในโหมด Dark: อ้างอิงไปที่ color.blue.100

---

ส่วนประกอบและคำศัพท์ของ Design Tokens ที่ควรรู้

• Alias – การเชื่อมต่อค่าระหว่าง Tier เช่น การใช้ค่าสี Red100 ใน Primitive ส่งมายัง Semantic เราจะเรียกว่า Aliasing ค่ากันได้

การส่งค่าต่อการระหว่าง Tier เหล่านี้ (Aliasing) จะช่วยให้ทีม Design system สามารถทำการแก้ไขและอัปเดตค่าของตัวแปรที่จะเพิ่มขึ้นหรือลดลงได้ในอนาคต โดยไม่ต้องไปแก้ชื่อตัวแปรที่ใช้งานในระบบ เช่น กรณีที่แบรนด์มีการตัดสินใจใหม่ เปลี่ยนสี, เปลี่ยนฟอนต์, เปลี่ยนดีไซน์

ผู้ใช้งาน (consumers) ที่ใช้ชื่อ Design tokens ตัวแปรจากระดับ Tier 2, Tier 3 หมดกังวลในการอัปเดต UI ค่าต่างๆ ในอนาคตได้เลย เพราะค่าตัวแปรต่าง ๆ จะถูกอัปเดตจาก Tokens ระดับ Tier 1 ได้อย่างง่ายดาย และยังช่วยเพิ่ม Consistency ให้กับแบรนด์และรองรับ Accessibility อีกด้วย

• Name and Value – ชื่อ Token และค่าของ Tokens เช่น #FFFFFF
• Type – ประเภทของ Tokens เช่น ประเภท color, number, boolean ฯลฯ
• Group – การแบ่งกลุ่มของ Tokens มีผลต่อการตั้งชื่อ
• Composite (Design) Token – tokens แบบซับซ้อน (แบบ object) ที่เก็บค่าตัวแปรหลายค่าในชื่อเดียว
• File format – ประเภทของไฟล์ที่จัดเก็บ Tokens

Name: “token name”
Value: “#fff000”
Type: “color”

การตั้งชื่อ Tokens จะมี Case sensitive มาเกี่ยวข้อง ดังนั้นจะทำตัวเล็ก ตัวใหญ่ จะใส่ขีด ต้องคิดให้ดี ๆ

{
“font-size“: {
“$value”: “3rem“,
“$type”: “dimension”
},

“FONT-SIZE“: {
“$value”: “16px“,
“$type”: “dimension”
}
}

เรื่องการจัดการ Token ในแต่ละ platform ของการใช้งาน ยังมีเรื่อง case sensitive และวิธีการเขียนชื่อตัวแปรนี้อีกมากมาย ไม่ว่าจะเป็นการเขียนแบบ

Kebab Case – การใช้ขีดกลางในชื่อ

color-text-default
color-text-primary

Camel Case – การใช้คำแรกเป็นตัวพิมพ์เล็ก ขึ้นคำใหม่เป็นตัวพิมพ์ใหญ่

colorTextDefault
colorTextPrimary 

Pascal Case – การใช้ตัวพิมพ์ใหญ่ทั้งหมด

ColorTextDefault

Snake Case – การใช้ตัวพิมพ์เล็กทั้งหมดและ underscore

color_text_default
color_text_primary

Dott Case – การใช้ตัวพิมพ์เล็กทั้งหมดและจุด

color.text.default
color.text.primary

---

การตั้งชื่อ Design tokens

การตั้งชื่อ Design tokens คือส่วนสำคัญที่จะทำให้ Adoption rate ของ Design tokens ของเรานั้นสูงขึ้นได้ การตั้งชื่อเลยจะต้องคำนึงถึงการอัปเดตที่จะเกิดขึ้นในอนาคต และเข้าใจตรงกันได้ง่ายทั้ง Designers, Developers และผู้ใช้งาน Consumers คนอื่น ๆ ที่ใช้งาน Design system

สิ่งที่ไม่ควรทำในการตั้งชื่อ Design tokens คือ

1. ตั้งชื่อให้ตรงกันกับค่า value เพราะจะทำให้การเปลี่ยนแปลงค่า value นั้นทำได้ยากในอนาคต
2. ตั้งชื่อให้ซ้ำกันระหว่าง tier1, tier2, tier3 โดยไม่ได้สื่อถึงความหมายให้เฉพาะเจาะจง
3. ตั้งชื่อให้เข้าใจยาก อ่านแล้วไม่รู้ว่าสรุปใช้ตรงไหนกันแน่

---

โมเดลการตั้งชื่อ Design tokens ยอดนิยม

1. C-T-I approach

เป็นการตั้งชื่อเอา Category ขึ้นก่อน ตามด้วยประเภท ตามด้วยสิ่งของ

ตัวอย่างชื่อ:
color-background-primary

2. BEM approach

เป็นการตั้งชื่อเอา Block ขึ้นก่อน ตามด้วย Element คือของที่ใช้งาน ตามด้วยตัวจัดการ Modifier

ตัวอย่างชื่อ:
input-left-icon-color-fill

3. Functional approach

เป็นการตั้งชื่อสไตล์ใครสไตล์มัน

ตัวอย่างชื่อ:
primary-background-color
tab-color-text-hover

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

ยกตัวอย่างการตั้งชื่อยอดนิยมอื่นๆ
Style dictionary: [category-type-item-subitem-state]
Nathan Curtis: [namespace-object-base-modifier]
Spectrum: [context-commonunit-clarification from]
Atlassian: [foundation-property-modifier]

---

โปรแกรมยอดนิยมที่ใช้ในการทำงาน

⭐️ โปรแกรมออกแบบ
ที่รองรับการทำงาน Design tokens
– Figma
– Sketch
– Tokens studio for Figma

⭐️ โปรแกรม Translation tool
เป็นโปรแกรมที่ใช้ทำงานแปลงค่า Design tokens ให้เป็นภาษาของแต่ละ Platform
– Theo
– Style Dictionary
– Diez
– Specify

⭐️ โปรแกรมทำ Documentation tool
ใช้สำหรับทำเอกสารเพื่อจัดเก็บข้อมูล เพื่อให้ผู้ใช้งานของเราศึกษาข้อมูลก่อนนำ Design tokens ไปใช้งานในฟีเจอร์ของตนเอง
– Storybook
– Zeroheight
– Backlight
– Specify
– Supernova
– Knapsack

อย่างในปัจจุบันจะเห็นคนทำ Documentation ของ Design tokens บน Airtable ก็มีเช่นกันค่ะ แล้วต่อเข้ากับโปรแกรม Automate อย่างเช่น Github หรือ Figma ได้เลย ซึ่งก็แล้วแต่เราว่าจะใช้ระบบอะไรในการจัดการค่าต่าง ๆ เหล่านี้ เทคโนโลยีฝั่งของ Design system เองก็พัฒนาต่อไปอย่างไม่หยุดยั้ง เพื่อที่จะลดขั้นตอนและเวลาในการส่งต่องานระหว่าง Design กับ Dev ทำให้เราสามารถทำงานเชื่อมต่อกันได้ดีขึ้นเรื่อยๆ

ฝั่ง Tool เองก็ยังพัฒนาต่อไปเพื่อลบช่องว่างระหว่าง Design กับ Dev ด้วยเช่นกัน ซึ่งเราก็คงจะต้องติดตามกันต่อไปในเร็ว ๆ นี้ ว่าจะมีเทคโนโลยีอะไรใหม่ ๆ มาให้เราลองใช้งานกันอีก

---

ถ้าใครอยากรู้เรื่องการจัดการ Design system สำหรับ Digital product ให้สามารถ scale ได้ง่าย รองรับการเติบโต มาเจอกับคลาสเรียนของเราได้ทาง Design tokens with Figma สอนโดยเสือขาวค่า

ปัจจุบัน Designil สอนเกี่ยวกับ User interface design + Design tokens มาเป็นระยะเวลากว่า 3 ปี หากสนใจสามารถดูรายละเอียดได้ด้านล่างนี้เลยนะคะ ^_^

---

อ้างอิงจาก

• Design tokens naming playbook – Romina
• Design Tokens Community Group
• Design Tokens Format Module
• Reimagining Design Systems at Spotify
• Adobe design tokens

บทความที่แนะนำสำหรับการตั้งชื่อ

• Naming Tokens in Design Systems – Nathan Curtis
• Creating a flexible design token taxonomy for Intuit’s Design System – Nate Baldwin
• A beginner’s guide to Design Tokens – Steve Dennis