Sáng tối và đa thương hiệu: tính từ đầu hay bổ sung sau?

Câu hỏi này xuất hiện thường xuyên khi một dự án design system (hệ thống thiết kế) còn non trẻ: chúng ta có nên dựng cả giao diện sáng tối và hỗ trợ nhiều thương hiệu ngay từ đầu, hay cứ làm cho xong bản chính rồi tính sau? Sinh Vũ trả lời thẳng: không cần dựng đủ ngay, nhưng cấu trúc phải chừa đường từ giai đoạn một. Sự khác biệt nằm ở tầng token ngữ nghĩa.

Ba tầng token: nền tảng không thể bỏ

Một design system có cấu trúc token vững cần ít nhất ba tầng rõ ràng.

• Token gốc (primitive token): lưu toàn bộ giá trị thô, ví dụ màu xanh lam cụ thể, cỡ chữ 14px, khoảng cách 8px. Tầng này không mang ý nghĩa ngữ cảnh.
• Token ngữ nghĩa (semantic token): đặt tên theo vai trò, ví dụ "màu nền chính", "màu chữ phụ", "đường viền cảnh báo". Tầng này trỏ đến token gốc, và là nơi chủ đề, thương hiệu được điều khiển.
• Token component: mỗi component chỉ đọc token ngữ nghĩa, không bao giờ đọc thẳng token gốc.

Khi cấu trúc này đứng vững, đổi chủ đề đồng nghĩa với thay ánh xạ ở tầng ngữ nghĩa. Component không cần biết có bao nhiêu chủ đề đang tồn tại.

Đặt mọi giá trị ở tầng token gốc, điều khiển chủ đề và thương hiệu ở tầng ngữ nghĩa, component lõi không đổi.

Material Design 3; Nathan Curtis, EightShapes

Chế độ tối không phải đảo màu

Hiểu sai này dẫn đến nhiều hệ thống có chế độ tối trông kỳ lạ, chữ khó đọc, màu thương hiệu bị lệch sắc. Chế độ tối đúng nghĩa là một bộ token ngữ nghĩa riêng, trong đó mỗi vai trò màu được trỏ sang một giá trị token gốc khác, phù hợp với nền tối.

Ví dụ: "màu nền chính" ở chế độ sáng trỏ về giá trị trắng nhạt, ở chế độ tối trỏ về giá trị xám đậm, không phải giá trị nghịch đảo toán học của màu trắng nhạt. Đây là lý do cần tầng ngữ nghĩa ngay từ đầu, kể cả khi chưa có kế hoạch làm chế độ tối trong sáu tháng tới.

Với các ngành có yêu cầu tương phản cao như tài chính hoặc y tế, nên kiểm tra tương phản đọc được ở cả hai chế độ từ giai đoạn thiết kế nền tảng, không để đến lúc ra mắt tính năng mới phát hiện.

Đa thương hiệu: một bộ component, nhiều bộ token

Lỗi tốn kém nhất Sinh Vũ gặp ở các hệ thống xây vội là nhân đôi component cho mỗi thương hiệu. Một thương hiệu con ra đời, nhóm sao chép toàn bộ thư viện component và chỉnh màu. Từ đó trở đi, mọi cập nhật phải làm hai lần, rồi ba lần.

Cách đúng: giữ một bộ component lõi dùng chung, mỗi thương hiệu có bộ token ngữ nghĩa riêng trỏ về token gốc của thương hiệu đó. Khi component hiển thị, nó chỉ hỏi "màu nền chính là gì?", còn câu trả lời phụ thuộc vào bộ token ngữ nghĩa nào đang được nạp.

Khi nào có thể để sau

Sinh Vũ không nói mọi thứ phải làm đủ ngay ngày một. Có những phần hoàn toàn có thể để lại cho giai đoạn sau mà không ảnh hưởng cấu trúc.

• Chưa cần dựng toàn bộ màn hình giao diện tối nếu sản phẩm chưa ra mắt tính năng đó.
• Chưa cần điền đủ bộ token ngữ nghĩa cho thương hiệu thứ hai nếu thương hiệu đó chưa có kế hoạch cụ thể.
• Chưa cần viết tài liệu chi tiết cho từng chế độ ngay lúc này.

Điều không thể để sau: quyết định đặt tầng ngữ nghĩa vào cấu trúc hay không. Đây là quyết định một chiều, và chọn sai ở bước này sẽ kéo chi phí sửa lên rất cao về sau.

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

Sinh Vũ mặc định bàn giao bộ token ba lớp hỗ trợ cả chế độ sáng và tối ngay ở Giai đoạn 1, đúng nguyên tắc chừa đường ở cấu trúc trước. Với khách đa thương hiệu dùng chung mã nguồn, tầng ngữ nghĩa là chỗ để tách thương hiệu mà không phá component lõi.

Nếu Anh / Chị hiện tại chắc chắn chỉ có một thương hiệu và một chế độ trong toàn bộ vòng đời sản phẩm, thì đây là trường hợp hiếm có thể cân nhắc cấu trúc đơn giản hơn. Nhưng trong thực tế, đa số doanh nghiệp đang phát triển đều sẽ cần ít nhất một trong hai: chế độ tối hoặc thương hiệu con. Chừa đường từ đầu là quyết định an toàn hơn.