Token thiết kế là gì và vì sao nó quyết định cả hệ thống

Chốt nhanh

Token thiết kế (design token) là tên có ý nghĩa được gắn vào một giá trị giao diện cụ thể, ví dụ color.brand.primary thay vì mã màu thô #1A73E8. Khi token thay đổi, toàn bộ sản phẩm số cập nhật đồng loạt mà không cần tìm và thay từng file. Vì lý do đó, token là lớp nền quyết định cả tốc độ thay đổi lẫn tính nhất quán của hệ thống.

Token thiết kế không phải khái niệm cao siêu dành cho đội kỹ thuật lớn. Đây là cách tổ chức giá trị giao diện sao cho một quyết định thay đổi ở một chỗ lan đúng ra toàn bộ hệ thống, không cần ai chạy đi sửa thủ công. Nếu Anh Chị đang xây sản phẩm số và chưa có token, mỗi lần đổi màu thương hiệu sẽ là một đợt công việc đau đầu.

Token là gì, hiểu đúng từ đầu

Token thiết kế là một cặp: tên có ý nghĩa và giá trị cụ thể. Ví dụ: color.action.primary mang giá trị #1A73E8. Component nút bấm tham chiếu đến tên này, không tham chiếu trực tiếp mã màu. Khi thương hiệu đổi màu chính từ xanh dương sang xanh lá, Anh Chị chỉ cần thay giá trị của color.action.primary một lần, toàn bộ nút bấm trong sản phẩm cập nhật ngay.

Token có thể xuất sang nhiều nền tảng khác nhau: CSS custom properties cho web, Swift cho iOS, Kotlin cho Android, XML cho các môi trường khác. Đây là lý do token quan trọng với sản phẩm đa nền tảng, vì cùng một quyết định thiết kế được duy trì nhất quán trên tất cả các đầu ra mà không cần nhân công sao chép thủ công.

Tại sao token quyết định cả hệ thống

Token giải quyết một vấn đề cốt lõi: tách biệt quyết định thiết kế khỏi nơi quyết định đó được áp dụng. Không có token, giá trị cứng được nhúng trực tiếp vào từng component, từng màn hình. Hệ quả là:

Đổi màu thương hiệu phải tìm và thay hàng trăm chỗ, dễ sót, dễ lệch.
Designer và developer dùng hai bộ giá trị khác nhau vì không có nguồn sự thật chung.
Thêm dark mode hoặc theme thứ hai gần như phải viết lại toàn bộ style.
Onboard thành viên mới mất nhiều thời gian vì không có quy ước rõ ràng.

Token tạo ra ngôn ngữ chung giữa designer và developer. Khi cả Figma và codebase đều tham chiếu cùng một file token, sai lệch giữa bản thiết kế và sản phẩm thực giảm đáng kể. Đây là nguyên tắc nguồn sự thật duy nhất (single source of truth) mà Atlassian, IBM và nhiều tổ chức lớn đang thực hành.

Phân tầng token: global, alias, component

Token không nên là một tầng phẳng. Cấu trúc hiệu quả gồm ít nhất hai lớp, tốt hơn là ba:

Global token: giá trị thô, ví dụ color.blue.600 = #1A73E8. Đây là bảng màu gốc, không component nào tham chiếu trực tiếp vào đây.
Alias token (còn gọi là semantic token): gắn ngữ nghĩa, ví dụ color.action.primary trỏ đến color.blue.600. Component tham chiếu tầng này.
Component token: ghi đè có chủ đích cho một component cụ thể, ví dụ button.background.default trỏ đến color.action.primary.

Tầng alias là mấu chốt. Khi chuyển dark mode, Anh Chị chỉ cần cập nhật tầng alias, dark mode: color.action.primary trỏ sang màu khác, toàn bộ component tự cập nhật. Không cần chạm vào từng component.

Đặt tên token theo ngữ nghĩa và vai trò, không theo giá trị cụ thể. Tên color.text.disabled đúng hơn color.gray.400 vì khi chuyển dark mode tên vẫn đúng còn giá trị thay đổi.
Nathan Curtis, EightShapes

Lỗi thường gặp và cách tránh

Đặt tên theo giá trị: color.blue.500 mất nghĩa ngay khi dark mode đổi màu đó thành trắng. Đặt tên theo vai trò, không theo màu sắc.
Bỏ qua tầng alias: component tham chiếu thẳng vào global token. Hậu quả là khi thêm dark mode phải refactor toàn bộ.
Token chỉ sống trong Figma: nếu không export sang code, designer và developer vẫn vận hành hai hệ thống song song và vẫn lệch nhau.
Không có governance: ai cũng được thêm token mới, không theo quy trình. Hệ thống phình ra với hàng trăm token không ai dùng, tạo gánh nặng bảo trì.

Khi nào cần token đầy đủ, khi nào dùng CSS variable đơn giản là đủ:
Nếu Anh Chị chỉ làm landing page hoặc microsite dùng một lần, CSS variable không cần phân tầng là đủ. Token đầy đủ sinh ra giá trị rõ khi sản phẩm có nhiều màn hình, nhiều đội cùng phát triển, hoặc khi kế hoạch bao gồm đa thương hiệu, dark mode, hoặc xuất sang nhiều nền tảng. Với những dự án đó, bắt đầu không có token thường rẻ hơn ở bước một nhưng đắt hơn rất nhiều ở bước ba trở đi.

Góc nhìn của Sinh Vũ

Trong các dự án xây dựng hệ thống thiết kế, Sinh Vũ dùng định dạng DTCG JSON (Design Token Community Group, định dạng chuẩn mở do cộng đồng thiết kế hệ thống xây dựng) làm nguồn sự thật duy nhất, đồng bộ hai chiều giữa Figma và codebase qua công cụ như Style Dictionary hoặc tương đương. Token được phân ba tầng: global, alias, component.

Bước đầu tiên trong mọi dự án dạng này không phải vẽ component. Đó là audit, tức là rà soát toàn bộ giá trị hiện có của khách, màu sắc, kiểu chữ, khoảng cách, rồi map vào cấu trúc token trước. Bước này tốn thời gian nhưng tránh được tình trạng xây xong phải phá ra làm lại vì nền không vững.

Với team kỹ thuật mới làm quen với token, Sinh Vũ khuyên bắt đầu với token màu và kiểu chữ trước. Không cần hệ token toàn diện ngay từ đầu. Quan trọng hơn là đặt tầng alias đúng từ sớm, vì đó là thứ khó sửa nhất về sau.

Nguồn tham khảo

Salesforce Lightning Design System: Token Taxonomy. Nathan Curtis, EightShapes: bài viết về design token naming. Atlassian Design System: design tokens. Kinh nghiệm thực hành Sinh Vũ trong dịch vụ A3.

Câu hỏi thường gặp

Token thiết kế khác CSS variable như thế nào?

CSS variable là cách lưu token trong môi trường web, còn token thiết kế là khái niệm cấp cao hơn: một giá trị có tên và ngữ nghĩa, có thể xuất sang nhiều nền tảng khác nhau như CSS, Swift, Kotlin, XML. Nói cách khác, CSS variable là một trong nhiều định dạng đầu ra của token, không phải token.

Dự án nhỏ có cần xây token không?

Nếu Anh Chị chỉ làm landing page hoặc microsite dùng một lần, CSS variable đơn giản là đủ. Token đầy đủ sinh ra giá trị rõ ràng khi sản phẩm có nhiều màn hình, nhiều đội cùng phát triển, hoặc khi cần hỗ trợ đa thương hiệu và dark mode. Bắt đầu với token màu và kiểu chữ là bước tối thiểu hợp lý cho hầu hết dự án có kế hoạch mở rộng.

Ai quản lý token trong đội ngũ, designer hay developer?

Token là tài sản chung của cả hai bên. Thực tế hiệu quả nhất là designer sở hữu ngữ nghĩa và quyết định giá trị, developer sở hữu định dạng xuất và tích hợp vào code. Cần có người hoặc nhóm chịu trách nhiệm governance, tức là quy tắc ai được thêm token mới và theo quy trình nào, để tránh hệ thống phình không kiểm soát.