Chuẩn token DTCG JSON là gì và vì sao nên theo
Một định dạng token trung lập giúp thiết kế, code và công cụ dựng cùng đọc được một tệp, không bị khóa cứng vào bất kỳ hãng nào.
DTCG JSON là định dạng chuẩn hóa token do nhóm cộng đồng của W3C ban hành, dùng JSON với các thuộc tính gắn dấu đô la như $value và $type để mọi công cụ thiết kế và công cụ dựng cùng đọc được. Nên theo vì đây là ngôn ngữ chung đang hội tụ của ngành, giúp token đi qua nhiều nền tảng mà không bị khóa vào một hãng. Bản ổn định đầu tiên ra năm 2025.10 và nhiều công cụ lớn như Style Dictionary, Tokens Studio, Figma đã hỗ trợ ở các mức khác nhau.
- token cần đi qua nhiều công cụ hoặc nhiều nền tảng
- muốn giữ quyền đổi công cụ về sau
- theo chuẩn ngay từ đầu rẻ hơn chuyển đổi định dạng sau
- chỉ một sản phẩm web nhỏ, một stack, một công cụ (vẫn nên theo)
DTCG JSON là định dạng token trung lập do Design Tokens Community Group, nhóm cộng đồng thuộc W3C (tổ chức chuẩn hóa web toàn cầu), ban hành. Mục đích đơn giản: tạo một ngôn ngữ chung để công cụ thiết kế, công cụ dựng và mã nguồn đều đọc được cùng một tệp token mà không cần dịch qua dịch lại. Bản ổn định đầu tiên có tên 2025.10, và nhiều công cụ phổ biến đã hỗ trợ ở các mức độ khác nhau.
DTCG JSON trông như thế nào
Về mặt kỹ thuật, một tệp DTCG JSON là tệp JSON thuần, không có gì đặc biệt ngoài quy ước đặt tên các thuộc tính. Mỗi token cần hai thuộc tính bắt buộc: $value (giá trị thực) và $type (kiểu, ví dụ color, dimension, fontFamily). Ngoài ra có thể thêm $description để ghi chú mục đích, $extensions để mở rộng theo nhu cầu riêng, và $deprecated để đánh dấu token không còn dùng nữa.
Quan trọng cần hiểu rõ: DTCG chỉ chuẩn hóa định dạng tệp, không quyết thay Anh / Chị cách tổ chức hay đặt tên token. Việc phân tầng token thành primitive, semantic, component là chiến lược riêng mà đội thiết kế và kỹ thuật phải tự xây dựng.
Vì sao đây là lựa chọn đáng theo
Lý do cốt lõi là tính trung lập. Khi token lưu theo định dạng DTCG, Anh / Chị không bị phụ thuộc vào một công cụ duy nhất. Nếu hôm nay dùng Tokens Studio mà ngày mai muốn chuyển sang công cụ khác, tệp token vẫn còn đọc được. Nếu hôm nay chỉ có web mà sau này thêm ứng dụng iOS hoặc Android, tệp cũng vẫn là điểm khởi đầu hợp lệ.
Lý do thứ hai là tính hội tụ của ngành. Style Dictionary, Tokens Studio, Figma và nhiều công cụ khác đang dần chuẩn hóa về DTCG. Đi cùng chiều với ngành hôm nay sẽ tiết kiệm công chuyển đổi về sau, và đội kỹ thuật mới tham gia dự án sẽ đọc được token nhanh hơn vì quy ước đã quen thuộc.
Khi nào cần thiết, khi nào ít cấp thiết hơn
Nên theo DTCG ngay: Token cần đi qua nhiều công cụ (từ thiết kế ra code), nhiều nền tảng (web, iOS, Android), hoặc đội có kế hoạch thay đổi công cụ trong tương lai gần. Đây cũng là lựa chọn tốt khi bắt đầu dự án mới vì chi phí tuân thủ từ đầu gần như bằng không.
Ít cấp thiết hơn: Sản phẩm nhỏ, chỉ web, chỉ một stack, một công cụ duy nhất từ đầu đến cuối. Nhưng ngay cả trường hợp này, Sinh Vũ vẫn khuyên nên theo, vì đây là chuẩn đang hội tụ và chi phí theo ngay từ đầu nhỏ hơn rất nhiều so với chuyển đổi định dạng sau khi đã có hàng trăm token.
Lỗi thường gặp khi áp dụng
- Nhầm DTCG là công cụ dựng: DTCG chỉ là định dạng tệp đầu vào. Để xuất ra CSS variables, UIColor, hay dp và sp cho Android, Anh / Chị vẫn cần một công cụ dựng riêng như Style Dictionary đứng ở giữa.
- Trộn định dạng cũ và định dạng DTCG trong cùng dự án: Điều này tạo ra hai nguồn sự thật, khó bảo trì và dễ gây xung đột khi công cụ đọc tệp.
- Kỳ vọng rằng theo chuẩn là tự có hệ thống tốt: DTCG giải quyết vấn đề định dạng, không giải quyết vấn đề chiến lược. Tổ chức token theo tầng, đặt tên nhất quán, quyết định scope của từng token vẫn là công việc của đội thiết kế và kỹ thuật.
Góc nhìn của Sinh Vũ
Trong các dự án Sinh Vũ thực hiện, bộ token được bàn giao theo chuẩn DTCG JSON ba lớp từ ngay bước đầu. Lý do không phải vì đây là yêu cầu kỹ thuật bắt buộc, mà vì đây là cách bảo vệ khoản đầu tư của khách. Token là tài sản dài hạn, nên nó phải sống được qua nhiều lần đổi công cụ và mở rộng nền tảng mà không cần xây lại từ đầu.
Chọn định dạng token trung lập, độc lập công cụ, để không bị khóa vào một hãng khi muốn đổi về sau.
Design Tokens Community Group, W3C
Theo chuẩn trung lập từ ngày đầu là quyết định kỹ thuật ít tốn kém nhất mà lại bảo vệ được nhiều nhất về dài hạn. Anh / Chị không cần hiểu toàn bộ đặc tả kỹ thuật của DTCG, nhưng cần biết rằng đây là nơi ngành đang đi đến, và đi cùng từ sớm luôn rẻ hơn đi muộn.
Checklist quyết định
Chủ đề: Chuẩn token trung lập DTCG JSON là gì và vì sao nên theo. Cẩm nang Sinh Vũ, sinhvu.com
Bấm chọn từng mục Anh / Chị thấy đúng, rồi bấm in hoặc lưu thành PDF để mang theo.
Nếu Anh / Chị đánh dấu phần lớn ở nhóm dấu hiệu trên, đây là lúc nên trao đổi kỹ hơn. Sinh Vũ có thể cùng Anh / Chị soi lại và đề xuất hướng đi.
Nguồn tham khảo
Design Tokens Community Group, W3C (cao). Bản ổn định đầu tiên DTCG 2025.10 (cao). designtokens.org FAQ (cao). Style Dictionary, hỗ trợ DTCG (cao). Kinh nghiệm thực hành Sinh Vũ Studio.
Câu hỏi thường gặp
DTCG JSON khác gì với cách Figma lưu token hiện tại?
Figma có định dạng token riêng trong Variables và trong plugin. DTCG JSON là định dạng trung lập, không thuộc về Figma hay bất kỳ hãng nào. Nếu chỉ dùng Figma từ đầu đến cuối thì hai định dạng có thể giống nhau về bề mặt, nhưng khi token cần đi ra ngoài Figma, chẳng hạn vào code hay vào iOS, thì định dạng DTCG mới là thứ công cụ dựng như Style Dictionary đọc được một cách đáng tin cậy.
Theo chuẩn DTCG xong thì token tự ra CSS và Swift được không?
Không. DTCG chỉ chuẩn hóa định dạng tệp token, không phải công cụ xuất. Anh / Chị vẫn cần một công cụ dựng như Style Dictionary để đọc tệp DTCG rồi xuất ra CSS variables cho web, màu UIColor cho iOS, hay giá trị sp và dp cho Android. DTCG là ngôn ngữ chung ở đầu vào, còn đầu ra vẫn phải cấu hình theo từng nền tảng.