Token thiết kế: nền móng quyết định cả hệ thống

Token thiết kế là một quyết định thiết kế được đặt tên và lưu thành dữ liệu. Ví dụ: thay vì gõ #1A1A2E ở mọi nơi cần màu nền chính, Anh Chị đặt tên nó là color.background.primary và dùng tên đó trong toàn bộ hệ thống. Đây không phải thủ thuật kỹ thuật mà là quyết định kiến trúc: ai kiểm soát token là người kiểm soát toàn bộ diện mạo sản phẩm.

Ba tầng token và lý do phân tầng

Hệ token lành mạnh có đủ ba tầng, mỗi tầng có một lý do thay đổi riêng:

• Token gốc (global hay primitive): Chứa giá trị thô, ví dụ blue-500 = #2563EB. Tầng này không nói gì về mục đích sử dụng, chỉ là kho chứa.
• Token ngữ nghĩa (semantic hay alias): Mang ý định thiết kế, ví dụ color.action.primary trỏ vào blue-500. Đây là tầng quyết định ngữ cảnh dùng: nền cảnh báo, chữ phụ, đường viền tương tác.
• Token theo thành phần (component token): Gán cho từng bộ phận cụ thể, ví dụ button.background.default trỏ vào color.action.primary. Tầng này chỉ cần thiết khi hệ thống thực sự phình to.

Nguyên tắc vận hành: component chỉ đọc token ngữ nghĩa, không đọc thẳng token gốc. Đây là điều kiện để đổi chủ đề sáng tối hay đa thương hiệu mà không phải đi sửa từng component.

Tách ba tầng token để mỗi tầng có một lý do thay đổi riêng. Đổi một tầng không kéo đổ các tầng khác.

Nathan Curtis, Tokens in Design Systems (EightShapes)

Vì sao token quyết định toàn bộ hệ thống

Cách hệ thống thiết kế (design system) hoạt động là: mọi component đều tham chiếu về token, không chứa giá trị cứng bên trong. Điều này có nghĩa:

• Đổi giá trị của một token ở tầng gốc hoặc ngữ nghĩa, toàn bộ giao diện website, ứng dụng, tài liệu đều cập nhật theo ngay lập tức.
• Token là hợp đồng chung giữa người thiết kế và lập trình viên. Cả hai bên gọi cùng một tên, không còn tình trạng bên Figma dùng tên này, bên code dùng tên khác.
• Khi cần mở rộng sang nền tảng mới, iOS, Android hay ứng dụng nhúng vào website đối tác, token xuất sang môi trường đó mà không cần thiết kế lại từ đầu.

Bỏ qua tầng token, hệ chỉ còn là bộ component rời. Đổi màu thương hiệu đồng nghĩa với việc ngồi sửa hàng trăm chỗ bằng tay và vẫn sót.

Khi nào cần đầu tư tầng token, khi nào chưa cần

Quan điểm của Sinh Vũ: dựng token trước khi dựng component, vì token là nền của mọi thứ phía trên. Đảo ngược thứ tự thì về sau phải phá và làm lại.

Lỗi thường gặp khi triển khai token

• Đặt tên token theo màu cụ thể ở tầng ngữ nghĩa: Ví dụ đặt tên color.xanh-500 cho màu nút chính. Khi thương hiệu đổi sang màu cam, cái tên hóa ra sai nghĩa hoàn toàn và gây nhầm lẫn cho cả đội.
• Component đọc thẳng token gốc: Bỏ qua tầng ngữ nghĩa khiến chế độ tối và đa thương hiệu bế tắc về sau, vì không có tầng trung gian để hoán đổi.
• Sinh quá nhiều token không ai dùng: Hệ phình to, tỉ lệ token thực sự được dùng thấp, đội thiết kế không còn nhớ nổi token nào dùng cho gì. Bắt đầu từ nhu cầu thực của giao diện hiện có, chuẩn hóa rồi mới mở rộng.

Đặt tên token theo ý nghĩa sử dụng, không theo giá trị hiện tại, để tên vẫn đúng khi giá trị đổi.

Nathan Curtis, Naming Tokens in Design Systems (EightShapes)

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

Sinh Vũ coi tầng token là nền móng không thể bỏ qua. Trong mỗi dự án xây hệ thống thiết kế, Giai đoạn 1 luôn mở đầu bằng rà soát toàn bộ giao diện số hiện có rồi chuẩn hóa thành ba lớp token trước khi dựng bất kỳ component nào.

Quan điểm vận hành là một nguồn chuẩn duy nhất cho màu, font, khoảng cách: đổi ở gốc thì cả website, ứng dụng và component đổi theo, không sót chỗ nào. Đây không phải tham vọng kỹ thuật, mà là điều kiện tối thiểu để một thương hiệu nhất quán trên nhiều điểm chạm số mà không tiêu hao sức người vào việc đồng bộ bằng tay.