Chuyên môn · Nền tảng token và đa nền tảng

Sáng tối và đa thương hiệu: tính từ đầu

Câu hỏi tưởng là kỹ thuật nhưng thực ra là câu hỏi về rủi ro kinh doanh.

Chốt nhanh

Nếu Anh/Chị biết chắc cần dark mode hoặc đa thương hiệu trong vòng sáu đến mười hai tháng tới, hãy thiết kế tầng token alias ngay từ đầu. Nếu chưa chắc, vẫn nên xây tầng alias vì chi phí ban đầu chênh lệch không đáng kể so với chi phí refactor sau khi hệ thống đã chạy production. Điều duy nhất cần tránh là dùng token global trực tiếp trong component rồi mới nghĩ đến đa theme.

Đây là câu hỏi mà nhiều chủ doanh nghiệp đặt ra khi đang xây design system lần đầu, và câu trả lời không phụ thuộc vào công nghệ mà phụ thuộc vào mức độ chắc chắn về kế hoạch sản phẩm. Sinh Vũ sẽ trình bày rõ logic để Anh/Chị tự đánh giá tình huống của mình.

Ba tầng token và vì sao thứ tự quan trọng

Trước hết cần hiểu cấu trúc. Một hệ token được xây đúng gồm ba tầng tách biệt:

  • Global token: giá trị thô, ví dụ color-blue-500: #2563eb. Đây là kho màu, không ai dùng trực tiếp trong component.
  • Alias token (còn gọi là semantic token, tức token có ngữ nghĩa): ví dụ color-background-primary ánh xạ đến color-blue-500. Component chỉ được tham chiếu tầng này.
  • Theme token: ghi đè giá trị của alias token theo mode (sáng/tối) hoặc theo thương hiệu. Tầng này làm cho cùng một component hiển thị khác nhau mà không cần sửa code component.

Salesforce, Atlassian, và IBM Carbon đều dùng cấu trúc ba tầng này trong thực tế. Lý do: nếu component bỏ qua tầng alias và tham chiếu thẳng vào global token, thì khi cần đổi theme, bắt buộc phải vào từng component để sửa, không có cách nào khác.

Khi nào bắt buộc tính từ đầu

Có những tình huống mà Sinh Vũ không thương lượng: phải xây tầng alias ngay từ đầu.

  • Anh/Chị biết chắc sẽ cần dark mode trong vòng sáu đến mười hai tháng tới.
  • Sản phẩm phục vụ nhiều thương hiệu hoặc cần white-label (cho khách hàng tập đoàn tùy chỉnh giao diện theo thương hiệu riêng của họ). Với dạng này, đa thương hiệu là yêu cầu kinh doanh, không phải tùy chọn kỹ thuật.
  • Hệ thống chạy trên nhiều nền tảng, bao gồm cả iOS và Android. Hai nền tảng này có quy tắc dark mode ở cấp hệ điều hành, cần xử lý khác web và cần được tích hợp ngay từ khi thiết kế token.

Khi nào có thể linh hoạt

Nếu sản phẩm đang ở giai đoạn MVP (sản phẩm khả dụng tối thiểu, dùng để kiểm định thị trường) và chưa có người dùng thực, Anh/Chị có thể bỏ qua việc thiết kế nội dung của tầng theme, tức là chưa cần làm file dark mode hay file theme thương hiệu B. Nhưng cấu trúc tầng alias vẫn phải có. Đây là điểm mà nhiều team hiểu nhầm: "chưa cần dark mode" không có nghĩa là "chưa cần alias token".

Nếu xây alias từ đầu: Mất thêm một khoản thiết lập nhỏ lúc khởi đầu. Khi cần thêm dark mode hay brand mới, chỉ việc viết thêm file theme, không đụng vào component.

Nếu bỏ alias, dùng global trực tiếp: Khởi đầu nhanh hơn một chút. Khi cần thêm theme, phải refactor (cấu trúc lại) toàn bộ component, rủi ro hồi quy (lỗi xuất hiện ở chức năng đã hoạt động tốt) rất cao trong môi trường production.

Hai chiều độc lập: đừng gộp nhầm

Một lỗi hay gặp là xử lý đa thương hiệu và dark/light mode bằng cùng một cơ chế. Hai thứ này là hai chiều riêng biệt:

  • Chiều thương hiệu: thay đổi màu sắc, kiểu chữ, hình dạng theo từng brand.
  • Chiều mode: thay đổi cách màu hiển thị trong môi trường sáng hoặc tối, giữ nguyên nhận diện thương hiệu.

Nếu gộp hai chiều vào một cơ chế, số lượng tổ hợp token tăng nhanh và việc quản lý trở nên rất phức tạp. Mô hình đúng là mỗi brand có tầng theme riêng cho màu sắc thương hiệu, và mỗi mode (sáng/tối) có tầng theme riêng điều chỉnh cách màu đó hiển thị, cả hai cùng ánh xạ lên tập alias chung.

Dark mode không phải là đảo ngược màu sáng. Mỗi giá trị màu trong dark mode cần được cân chỉnh riêng về tương phản, sắc độ, và cảm giác nhìn.

Nielsen Norman Group: khuyến nghị về dark mode UX

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

Trong mọi dự án A3, Sinh Vũ mặc định xây tầng alias ngay từ đầu, kể cả khi khách chưa có kế hoạch dark mode hay mở rộng brand. Lý do đơn giản: chi phí thiết lập tầng alias ở giai đoạn khởi đầu chỉ chiếm phần nhỏ trong tổng ngân sách, trong khi chi phí refactor sau khi hệ thống đã chạy production cao hơn nhiều lần và kéo theo rủi ro thực.

Nếu khách cần giảm ngân sách, Sinh Vũ ưu tiên giảm số lượng component hơn là bỏ tầng alias. Một hệ thống ít component nhưng cấu trúc token đúng thì dễ mở rộng. Ngược lại thì không.

Nguồn tham khảo

Salesforce Lightning Design System: theming architecture. Nielsen Norman Group: dark mode best practices. Shopify Polaris: multi-brand token system. Kinh nghiệm thực hành Sinh Vũ qua dự án A3.

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

Nếu hiện tại chỉ cần một giao diện sáng duy nhất, có cần xây tầng alias không?

Có. Tầng alias không phụ thuộc vào việc Anh/Chị có bao nhiêu theme. Nó giúp component không bị buộc chặt vào giá trị màu cụ thể, và là điều kiện tiên quyết để thêm dark mode sau này mà không cần refactor toàn bộ. Chi phí xây tầng alias ngay từ đầu là nhỏ so với lợi ích dài hạn.

Dark mode có thể làm bằng cách đảo ngược màu tự động được không?

Không nên. Đảo ngược màu tự động (ví dụ dùng filter: invert trong CSS) cho kết quả tệ về tương phản, sắc độ, và cảm giác nhìn. Dark mode đúng cần được cân chỉnh riêng từng giá trị màu, không phải phép toán đơn giản trên bảng màu sáng. Đây là khuyến nghị của Nielsen Norman Group về UX cho dark mode.

Đa thương hiệu và dark/light mode có thể dùng chung một cơ chế không?

Không nên gộp hai khái niệm này vào một cơ chế. Đa thương hiệu và đa mode là hai chiều độc lập. Nếu gộp, số lượng tổ hợp token sẽ bùng nổ và rất khó quản lý. Mô hình đúng là tách riêng tầng theme cho brand và tầng mode cho sáng/tối, cùng ánh xạ lên tầng alias chung.

← Về Hệ thiết kế số
{INJ}