Token hay Component: nên bắt đầu từ đâu trước
Câu trả lời ảnh hưởng đến toàn bộ chi phí bảo trì sau này, không phải chỉ tuần đầu tiên.
Bắt đầu từ nền tảng token, tức là bộ màu, kiểu chữ và khoảng cách được đặt tên và tổ chức thành lớp, trước khi dựng bất kỳ component nào. Nếu Anh/Chị dựng component khi chưa có token, mỗi component sẽ nhúng giá trị cứng bên trong, và khi cần đổi màu thương hiệu hoặc hỗ trợ giao diện tối, đội kỹ thuật phải sửa tay hàng trăm chỗ. Token làm gốc một lần, cả hệ cập nhật theo một lần.
- nhiều sản phẩm số, cần sáng tối hoặc đa thương hiệu
- muốn hệ sống lâu và mở rộng được
- một sản phẩm nhỏ cần ra mắt nhanh (vẫn đặt token làm gốc)
- chờ token hoàn hảo mới bắt đầu, đóng băng cả dự án
Token màu, chữ, khoảng cách là nền móng. Component là tầng xây trên nền đó. Đảo thứ tự này lại, Anh/Chị sẽ tốn gấp đôi công sức mỗi lần thương hiệu thay đổi, và về sau muốn hỗ trợ giao diện tối hoặc thêm thương hiệu thứ hai sẽ gần như phải làm lại từ đầu.
Token là nguồn chuẩn duy nhất
Brad Frost mô tả token là hạt "subatomic" (dưới nguyên tử) của giao diện: chưa dùng được một mình, nhưng là thành phần gốc mà mọi thứ bên trên phải kế thừa. Khi đội thiết kế và đội kỹ thuật cùng tham chiếu một token thay vì mỗi người tự nhớ một mã màu, toàn bộ sản phẩm số giữ được sự đồng nhất mà không cần kiểm tra thủ công từng màn hình.
Nếu Anh/Chị đổi một token màu chủ ở gốc, toàn bộ website, ứng dụng và mọi component cập nhật theo ngay lập tức. Không cần họp, không cần gửi file màu mới cho từng người.
Tổ chức token theo ba lớp
Một bộ token phẳng, chỉ liệt kê màu, chưa đủ để vận hành lâu dài. Sinh Vũ tổ chức token theo ba lớp có thứ bậc:
- Lớp gốc (primitive): toàn bộ giá trị thực của màu sắc, cỡ chữ, khoảng cách, ví dụ blue-500 = #1A56DB. Lớp này không gắn với ngữ cảnh nào.
- Lớp ngữ nghĩa (semantic): đặt tên theo mục đích dùng, ví dụ color-brand-primary tham chiếu tới blue-500. Khi đổi thương hiệu hay chuyển sang giao diện tối, chỉ cần sửa ở lớp này.
- Lớp gắn component (component-specific): token riêng cho từng component khi cần, tham chiếu lại lớp ngữ nghĩa. Lớp này không chứa giá trị cứng.
Kiến trúc ba lớp này cho phép đổi màu ở gốc và thay đổi lan xuống có kiểm soát, không lan sang những chỗ không mong muốn.
Khi nào bắt đầu từ token, khi nào được làm song song
Bắt đầu từ token trước: Khi doanh nghiệp có nhiều sản phẩm số, cần hỗ trợ giao diện tối hoặc nhiều thương hiệu, muốn hệ thống sống được qua nhiều năm và mở rộng sang iOS hoặc Android. Đây là trường hợp phổ biến nhất và cũng là trường hợp mà nợ kỹ thuật tích lũy nhanh nhất nếu bỏ qua bước này.
Làm song song được khi: Chỉ có một sản phẩm nhỏ, nhận diện thương hiệu đã được chốt hoàn toàn, và cần ra mắt trong thời gian ngắn. Dù vậy, điều kiện bắt buộc là ngay từ đầu mọi component phải tham chiếu token, tuyệt đối không nhúng giá trị màu hay cỡ chữ cứng vào bên trong component.
Lỗi phổ biến cần tránh
- Nhét giá trị cứng vào component: Đây là lỗi nghiêm trọng nhất. Khi cần đổi màu thương hiệu hoặc hỗ trợ giao diện tối, đội kỹ thuật phải tìm và sửa tay từng component một.
- Làm token nhưng chỉ một lớp phẳng: Bộ token thiếu lớp ngữ nghĩa khiến việc hỗ trợ sáng tối và đa thương hiệu về sau gần như bế tắc, vì không có chỗ để "bẻ" giá trị theo ngữ cảnh.
- Chờ token hoàn hảo mới bắt đầu: Token không cần hoàn thiện 100% trước khi dựng component đầu tiên. Bắt đầu với bộ token đủ dùng, xây song song có kiểm soát, rồi bổ sung dần.
Góc nhìn của Sinh Vũ
Trong quy trình A3 tại Sinh Vũ, giai đoạn đầu luôn là rà soát nhận diện hiện tại và chuyển đổi toàn bộ sang bộ DTCG JSON (định dạng chuẩn do Design Tokens Community Group thuộc W3C đề xuất, giúp một bộ token dùng được trên nhiều công cụ và nền tảng) theo ba lớp, kèm báo cáo điểm lệch chuẩn giữa thiết kế và sản phẩm thực. Chỉ sau khi bộ token này được chốt, đội mới chuyển sang giai đoạn dựng component.
Lý do không phải vì quy trình cứng nhắc, mà vì đây là cách duy nhất đảm bảo nhận diện không loãng dần khi vào sản phẩm số. Nếu component đi trước, mỗi người sẽ tự quyết định màu nào dùng, cỡ chữ nào phù hợp, và sau sáu tháng hệ giao diện sẽ có hàng chục biến thể nhỏ không ai kiểm soát được.
Token là nguồn chuẩn duy nhất. Component chỉ được tham chiếu token, không được tự định nghĩa giá trị.
Nguyên tắc vận hành Design System, Sinh Vũ Studio
Checklist quyết định
Chủ đề: Nên bắt đầu từ token hay từ component trong design system. 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
Brad Frost, Atomic Design và bài viết Design Tokens + Atomic Design. Design Tokens Community Group, W3C DTCG JSON specification. Nathan Curtis, EightShapes. Kinh nghiệm thực hành dự án A3 tại Sinh Vũ Studio.
Câu hỏi thường gặp
Token là gì, khác component ở chỗ nào?
Token là một cặp tên và giá trị, ví dụ color-brand-primary = #1A56DB. Token không hiển thị được một mình, nó là nguyên liệu gốc mà component kế thừa. Component là phần tử giao diện hoàn chỉnh như nút bấm, thẻ thông tin, thanh điều hướng. Làm token trước giống như pha màu ra đĩa trước khi vẽ, không phải vừa vẽ vừa pha từng nét.
Nếu sản phẩm nhỏ và cần ra hàng nhanh, có thể bỏ qua token không?
Không nên bỏ qua, nhưng có thể làm song song với một nhóm component nhỏ đầu tiên. Điều bắt buộc là ngay từ đầu component phải tham chiếu token, không được nhét giá trị màu hay cỡ chữ cứng vào bên trong. Nếu bỏ qua hoàn toàn, nợ kỹ thuật tích lũy nhanh và chi phí chuẩn hóa lại sau này cao hơn làm đúng từ đầu rất nhiều.