Design Token hoạt động thế nào? Bắt đầu từ ba nút cùng màu
Tổng hợp cách Salesforce, W3C DTCG, Material Design 3, Adobe Spectrum, IBM Carbon và Nathan Curtis định nghĩa design token, minh hoạ bằng ba nút cùng màu và một bài thực hành trên biểu mẫu nhỏ.

Mục lục
Ba nút cùng một màu xanh. Đổi màu một lần, chỉ hai nút đổi theo. Chi tiết nhỏ đó cho biết giao diện của bạn có đang dùng design token hay chỉ đang “trông giống nhau”.
TL;DR
- Design token là một lựa chọn thiết kế có tên, tối thiểu là một cặp tên và giá trị, để thiết kế, công cụ và code cùng tham chiếu (W3C DTCG, Material Design 3).
- Nhìn màu giống nhau chưa biết là đã dùng token. Điều cần kiểm là chỗ đó lấy giá trị từ đâu.
- Các hệ thống lớn đều tách ít nhất hai tầng: bảng giá trị gốc và vai trò sử dụng. Material gọi là reference / system / component, Spectrum gọi là global / alias / component, Carbon đặt tên token theo vai trò (Material, Spectrum, Carbon).
- Cùng màu hôm nay chưa chắc cần đổi cùng nhau. Câu hỏi để quyết định dùng chung: những chỗ này có cần đi cùng nhau khi thiết kế thay đổi không?
- Bắt đầu nhỏ: một biểu mẫu, bốn vai trò, liên kết rồi thử đổi một giá trị. File token không tự đồng bộ Figma với code; vẫn phải kiểm từng chặng tới giao diện thật.
1. Design token là gì, và vì sao chỉ nhìn màu là chưa đủ?
Token là một lựa chọn có tên. Hai thứ cùng màu chỉ thật sự “dùng chung” khi cùng tham chiếu tới lựa chọn đó.
Lấy một ứng dụng quản lý đơn hàng giả định. Màn tạo đơn, màn sửa đơn và hộp xác nhận đều có một nút màu xanh.
Hai nút đầu lấy màu từ lựa chọn chung mang tên “nền hành động chính”. Nút thứ ba được nhập mã màu trực tiếp. Trên màn hình, cả ba chưa có gì khác biệt.
Giờ mình đổi “nền hành động chính” sang màu khác. Hai nút liên kết đổi theo. Nút nhập tay giữ màu cũ.
| Nút | Cách lấy màu | Khi lựa chọn chung thay đổi |
|---|---|---|
| Tạo đơn | Tham chiếu “nền hành động chính” | Nhận giá trị mới |
| Lưu đơn | Tham chiếu cùng lựa chọn chung | Nhận giá trị mới |
| Xác nhận | Nhập mã màu trực tiếp | Giữ giá trị đã nhập |
THỬ TRỰC TIẾP
Nền hành động chính
#3D8BFFCùng màu, nhưng chỉ hai nút đầu theo nguồn.
Thử bấm đổi màu nguồn. Bản thử chỉ mô phỏng cơ chế, không nối với Figma hay sản phẩm thật.
Với người mới, mình đọc một token qua ba câu hỏi:
- Tên: mình đang chọn thứ gì?
- Giá trị: lựa chọn ấy hiện được thể hiện như thế nào?
- Nơi dùng: những phần nào đang lấy giá trị từ đó?
Trong ví dụ trên, tên là “nền hành động chính”, giá trị hiện tại là một màu xanh, còn nơi dùng là hai nút đã liên kết. Nếu chép mã màu ra dùng riêng, liên kết sẽ đứt.
Các nguồn lớn định nghĩa design token thế nào
Định nghĩa khác chữ nhưng cùng một ý: đặt tên cho lựa chọn thiết kế để mọi nơi tham chiếu thay vì chép giá trị. (Mở để xem thêm)
🏷️ Salesforce (2014) - nơi khái niệm design token ra đời.
Theo nhóm cộng đồng Design Tokens của W3C, Jina Anne đặt ra thuật ngữ “design tokens” cùng Jon Levine khi làm ở Salesforce. Nathan Curtis (EightShapes) ghi nhận Salesforce là nơi khởi xướng khái niệm này từ năm 2014.
📐 W3C Design Tokens Community Group - DTCG Format 2025.10
Đặc tả định nghĩa token là thông tin gắn với một tên người đọc được, tối thiểu là một cặp tên và giá trị. Giá trị của token có thể là tham chiếu tới token khác (ví dụ {{color.blue.600}}). Mục tiêu của đặc tả là giúp các công cụ trao đổi token với nhau. Lưu ý: đây là báo cáo của nhóm cộng đồng, không phải W3C Standard.
🎨 Google Material Design 3
Material mô tả token là những quyết định thiết kế nhỏ, dùng lại được, thay giá trị tĩnh bằng tên tự giải thích. Một token gồm tên (như md.ref.palette.secondary90) và giá trị (như #E8DEF8); giá trị có thể là màu, font, kích thước hay một token khác. Khi bản thiết kế và code cùng tham chiếu một token, cả hai dùng đúng một màu, kể cả khi mã màu của token được cập nhật.
🧩 Figma Variables
Trong Figma, token thường được lưu bằng variable rồi liên kết vào thuộc tính của giao diện. Figma mô tả variables, collections và modes là cách lưu, dùng lại và tổ chức các giá trị này. Tạo một variable tên “màu xanh” mới là bước kỹ thuật; nhóm còn cần thống nhất màu ấy được dùng ở đâu.
Điều rút ra
Token không phải là bảng mã màu. Token là một quyết định có tên, và giá trị trong nó được phép thay đổi. Phép kiểm đầu tiên luôn là: chỗ này đang lấy giá trị từ đâu?
2. Tách tầng: giá trị gốc, vai trò, và thành phần
Các hệ thống lớn đều tách giá trị gốc khỏi vai trò sử dụng, để đổi một vai trò mà không kéo theo mọi thứ cùng màu.
Giờ thêm một đường link “Xem chi tiết”. Link cũng màu xanh. Khi muốn đổi màu nút hành động chính, bạn có muốn link đổi theo không?
Nếu câu trả lời là “chưa chắc”, nên đặt hai vai trò riêng. Trong ví dụ này, mình tổ chức như sau:
| Lớp | Ví dụ tên | Mục đích |
|---|---|---|
| Giá trị nền, thường gọi là primitive | blue-600 |
Giữ một sắc xanh trong bảng màu |
| Vai trò, thường gọi là semantic | action-background |
Chọn nền cho hành động chính |
| Vai trò khác | link-text |
Chọn màu chữ của đường link |
Ở đây “nền hành động chính” được viết thành tên action-background: cùng một lựa chọn, một tên để người đọc, một tên để công cụ và code dùng. Ban đầu, cả action-background và link-text cùng tham chiếu blue-600. Nếu chỉ hành động chính cần đổi, mình chuyển tham chiếu của action-background sang màu mới và giữ nguyên link-text.

Sau khi đổi: action-background chọn blue-700, còn link-text tiếp tục dùng blue-600.
Các hệ thống lớn chia tầng thế nào
Tên gọi khác nhau, cấu trúc gần giống nhau. (Mở để xem thêm)
🎨 Material Design 3 - reference, system, component.
Reference token là toàn bộ lựa chọn có sẵn và không đổi theo ngữ cảnh. System token là quyết định gán mục đích cho reference token, và là nơi diễn ra theme: cùng một system token có thể trỏ tới reference token khác nhau ở theme sáng và tối. Component token gán thuộc tính cho từng phần của thành phần, như màu icon trong nút. Nhờ ba lớp này, nhóm có thể đổi quyết định cho toàn hệ thống hoặc chỉ cho một thành phần.
🅰️ Adobe Spectrum - global, alias, component.
Global (primitive) token định nghĩa các giá trị có sẵn trong ngôn ngữ thiết kế và gần như không mang ý định sử dụng. Alias token tham chiếu tới token khác thay vì một giá trị cuối, để làm rõ một quyết định cho ngữ cảnh cụ thể. Component token chỉ dùng tiết chế; Spectrum ưu tiên các token ngữ nghĩa dùng lại được.
🔷 IBM Carbon - token đặt tên theo vai trò.
Carbon định nghĩa token là định danh theo vai trò, không đổi giữa các theme; chỉ giá trị gán cho token thay đổi theo theme. Tên token nói phần giao diện và vai trò, như $text-primary hay $border-subtle. Mỗi theme dùng chung bộ token và vai trò, chỉ khác giá trị.
✍️ Nathan Curtis, EightShapes (2020) - cách đặt tên token.
Curtis đề xuất ghép tên từ các cấp: phần gốc gồm category (màu), concept (hành động, phản hồi) và property (nền, chữ); thêm modifier khi cần như variant (primary), state (hover), scale (100) hay mode; thêm object khi token thuộc về một thành phần; và namespace cho tên hệ thống hoặc theme. Theo ông, tên token tốt giúp nhóm giữ được hiểu biết chung về phong cách thị giác khi hệ thống lan ra nhiều nền tảng.
Quy tắc rút ra
Bảng màu gốc đặt tên theo sắc độ (blue-600); nơi áp dụng đặt tên theo vai trò (action-background). Hai chỗ chỉ nên dùng chung token khi chúng cần đi cùng nhau khi thiết kế thay đổi. Hai khoảng cách cùng bằng 16 px cũng vậy: khoảng cách giữa các trường và giữa hai nhóm nội dung có thể cần đổi độc lập. Không cần đủ ba tầng ngay từ đầu; ít lớp hơn mà đủ quản lý thì bắt đầu với ít lớp hơn.
3. Lợi ích: vì sao các hệ thống lớn đầu tư vào token
Lợi ích không nằm ở việc đổi màu nhanh, mà ở việc mọi người cùng nói về một quyết định. (Mở để xem thêm)
🎯 Một nguồn sự thật
Material Design 3 viết rằng token giúp hệ thống có một nơi ghi lại các lựa chọn phong cách và theo dõi thay đổi. Khi số màn hình tăng, mình không phải nhớ từng nơi đã nhập màu bằng tay.
🌗 Theme và ngữ cảnh
Vì token gắn với vai trò, đổi theme là đổi giá trị chứ không đổi tên. Carbon có bốn theme dùng chung một bộ token; Material dùng system token để chuyển sang bảng màu tương phản cao hoặc thang chữ lớn hơn cho màn hình TV.
🤝 Thiết kế và code nói cùng một ngôn ngữ
Theo Material, khi thiết kế và code cùng tham chiếu một token, nhóm bớt nhầm lẫn lúc bàn giao. Tên vai trò như “chữ thông báo lỗi” dễ ra quyết định hơn “màu đỏ thứ ba”.
⚠️ Khi nào token chưa đáng làm
Material cũng nói rõ token ít giúp ích khi sản phẩm đang dùng giá trị cố định và khó thay đổi trong một hai năm tới, hoặc khi sản phẩm chưa có design system. Lợi ích thực tế phụ thuộc cách giao diện được liên kết và quy trình cập nhật của nhóm.
Tóm lại, token đáng giá khi thiết kế còn thay đổi và chạy trên nhiều màn hình hoặc nền tảng. Nếu giao diện gần như đứng yên, một bảng màu rõ ràng có thể đã đủ.
4. Bắt đầu với một biểu mẫu nhỏ
Bạn chưa cần tạo hàng trăm token. Một biểu mẫu với bốn vai trò đủ cho một vòng làm việc đầy đủ.
Hãy bắt đầu bằng một biểu mẫu có tiêu đề, trường nhập liệu, thông báo lỗi và nút xác nhận.

Biểu mẫu để thực hành: xác định vai trò của chữ, lỗi, nút và khoảng cách giữa hai trường, rồi liên kết từng thuộc tính.
1. Ghi lại các lựa chọn đang lặp lại. Ví dụ: màu chữ chính, màu thông báo lỗi, nền hành động chính và khoảng cách giữa các trường. Đừng vội gom mọi giá trị giống nhau thành một nhóm.
2. Đặt tên theo điều người dùng token cần chọn. “Chữ thông báo lỗi” dễ đưa ra quyết định hơn “màu đỏ thứ ba”. Bảng màu nền vẫn đặt tên theo sắc độ; nơi áp dụng cần tên theo vai trò.
3. Liên kết vào giao diện. Kiểm tra thuộc tính thực tế của từng phần tử, không chỉ đối chiếu screenshot. Nếu nút vẫn chứa mã màu nhập tay, nó chưa lấy giá trị từ lựa chọn chung.
4. Thử đổi một giá trị trong bản thử. Quan sát phần nào đổi và phần nào giữ nguyên. Nút có cập nhật không? Link có đổi ngoài ý muốn không? Chữ còn đọc rõ trên nền mới không? Kiểm xong thì đổi lại giá trị cũ.
5. Đổi trong thư viện chưa có nghĩa sản phẩm đã đổi
Thay đổi phải đi tới đúng nơi người dùng nhìn thấy, và mỗi chặng cần được kiểm.
Giống như sửa file gốc của một tấm poster: bản đã in vẫn là bản cũ cho tới khi được in lại. Trong quy trình có cả Figma và code, hãy lần theo từng chặng: nguồn token đã đổi, file token đã được xuất lại, ứng dụng đã dùng bản mới, giao diện đã hiển thị đúng.

Kiểm từng chặng theo pipeline thực tế của nhóm. Sơ đồ này không giả định Figma và code tự đồng bộ.
🔁 DTCG và Style Dictionary - định dạng chung và công cụ xuất.
DTCG chỉ mô tả định dạng để các công cụ trao đổi token. Các công cụ như Style Dictionary đọc file token rồi xuất ra cho từng nền tảng (CSS, iOS, Android…) và tương thích với đặc tả DTCG. Có file token chưa có nghĩa là Figma và code đã tự đồng bộ; nối các bước này vẫn là quy trình của nhóm.
Tương tự, tên text-primary không tự bảo đảm chữ dễ đọc trên mọi nền. Mình vẫn cần kiểm tra trong trạng thái, theme và kích thước đang dùng. Giá trị chung giúp thay đổi có tổ chức; chất lượng của lựa chọn vẫn là trách nhiệm thiết kế.
Kết luận
Quay lại ba nút ở đầu bài. Trước khi hỏi “màu đã giống nhau chưa?”, hãy hỏi thêm ba câu:
- Chỗ này đang lấy màu từ đâu?
- Khi nguồn đổi, chỗ này có đổi theo không?
- Có chỗ nào không nên đổi theo mà vẫn đang dùng chung?
Trả lời được cả ba là biết hệ thống token của mình có đang thực sự hoạt động hay không.
Tài liệu tham khảo
- W3C Design Tokens Community Group: Design Tokens Format Module 2025.10
- W3C Design Tokens Community Group: Thank you, Jina and Val
- Nathan Curtis, EightShapes: Naming Tokens in Design Systems
- Google Material Design 3: Design tokens
- Adobe Spectrum: Design tokens
- IBM Carbon Design System: Themes
- Figma Help Center: Overview of variables, collections and modes
- Style Dictionary: Export your design tokens to any platform