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ẻ: 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? Câu trả lời thẳng: không cần dựng đủ ngay, nhưng cấu trúc phải chừa đường từ đầu. 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 đọ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 thường 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

Không phải mọi thứ đều 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.

Nếu Anh / Chị 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, đâ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 đa số doanh nghiệp đang phát triển sẽ cần ít nhất một trong hai: chế độ tối hoặc thương hiệu con, nên chừa đường từ đầu thường là quyết định an toàn hơn.

Bài viết là thông tin tham khảo. Phạm vi, giá và cam kết cụ thể của Sinh Vũ ghi trong hồ sơ đề xuất và hợp đồng đã ký.