Token hay component: cái nào trước

Nhiều đội sản phẩm chọn làm component trước vì muốn thấy kết quả ngay. Nút bấm hiện ra, màn hình chạy được. Trông có vẻ hiệu quả. Nhưng đây là lỗi thiết kế hệ thống cơ bản, và Sinh Vũ gặp lại tình huống này thường xuyên khi được mời vào chỉnh sửa một design system đang rối. Chi phí sửa lại sau bao giờ cũng lớn hơn chi phí làm đúng từ đầu.

Token là gì và tại sao phải có trước

Token (mã giá trị thiết kế) là lớp ngôn ngữ chung giữa thiết kế và kỹ thuật. Một token không phải là màu sắc hay font chữ, mà là tên được đặt cho một giá trị với một vai trò cụ thể. Ví dụ: color-primary trỏ đến màu chủ đạo của thương hiệu, bất kể màu đó là xanh hay cam hay đen.

Component chỉ là biểu hiện của token, không tự chứa giá trị thị giác. Nếu component tự chứa giá trị (hardcode trực tiếp mã màu #1A73E8 vào nút bấm), thì khi thương hiệu thay màu, đội kỹ thuật phải tìm và sửa từng dòng code một. Đây là lý do W3C Design Tokens Community Group (DTCG) thiết lập chuẩn token trước khi bất kỳ component nào được xây.

Ba lớp token và thứ tự cần nắm

Nathan Curtis (EightShapes) và cộng đồng design systems phân cấp token thành ba lớp. Anh / Chị cần hiểu để biết mình đang ở lớp nào:

• Primitive tokens (token gốc): giá trị thô, ví dụ blue-500: #1A73E8. Đây là bảng màu đầy đủ, chưa mang vai trò.
• Semantic tokens (token ngữ nghĩa): gán vai trò cho giá trị gốc, ví dụ color-primary: blue-500. Lớp này là nơi quyết định màu nào làm màu chính, màu nào làm màu cảnh báo.
• Component tokens (token riêng từng component): chỉ áp dụng trong phạm vi component cụ thể, ví dụ button-background: color-primary.

Lớp semantic là lớp hay bị bỏ qua nhất. Khi bỏ qua nó, thương hiệu thay đổi một màu là phải sửa hàng trăm component thay vì sửa một dòng trong semantic token.

Atom phải tồn tại trước molecule và trước organism. Token là atom của hệ thiết kế.

Brad Frost, Atomic Design (2016)

Khi nào làm token trước, khi nào được phép linh hoạt

Lỗi thường gặp khi bắt đầu sai thứ tự

• Đặt tên token theo giá trị thay vì vai trò: Đặt tên token là blue thay vì color-primary. Khi thương hiệu đổi sang màu cam, tên blue trở nên sai ngữ nghĩa hoàn toàn mà không thể đổi tên dễ dàng.
• Bỏ qua lớp semantic token: Chỉ có primitive và component, không có lớp ngữ nghĩa ở giữa. Kết quả là mọi thay đổi thương hiệu đều phải sửa từng component.
• Figma và code dùng token khác nhau: Thiết kế dùng tên token một kiểu, code dùng tên khác. Không có nguồn duy nhất (single source of truth) chung. Mọi cập nhật phải làm hai lần và dễ bị lệch.
• Tạo quá nhiều token ngay từ đầu: Chưa biết component nào sẽ xuất hiện đã định nghĩa hàng trăm token. Gây nhầm lẫn và phình hệ không kiểm soát được.

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

Thứ tự Sinh Vũ áp dụng cho mỗi dự án design system: kiểm kê thương hiệu hiện có, đặt primitive tokens từ bảng màu và hệ chữ, thiết kế semantic tokens cùng đội sản phẩm của khách để đảm bảo ngôn ngữ vai trò được đồng thuận, sau đó mới vẽ component đầu tiên trong Figma.

Token được export ra file JSON và dùng Style Dictionary (công cụ chuyển đổi token của Amazon) để sinh ra biến CSS, Sass, hoặc Swift tự động cho từng nền tảng. Một nguồn duy nhất, nhiều đầu ra. Đây là lý do Anh / Chị không cần sửa tay ở nhiều nơi mỗi khi thương hiệu điều chỉnh.

Token không cần hoàn hảo ngay từ đầu. Nhưng cần đủ ổn định ở lớp semantic trước khi component đầu tiên được xây. Đó là điều kiện tối thiểu không thể bỏ qua.