Tổ chức design system cho tập đoàn đa thương hiệu

Bài toán design system (hệ thiết kế) cho tập đoàn đa thương hiệu là bài toán phức tạp nhất trong lĩnh vực này, không phải vì kỹ thuật khó, mà vì nó đòi hỏi quyết định kiến trúc đúng ngay từ đầu. Sai cấu trúc thì sửa rất tốn công, và càng để lâu càng khó sửa vì càng nhiều đội phụ thuộc vào nó.

Kiến trúc nhiều lớp là gì và tại sao bắt buộc

Multi-brand design system architecture (kiến trúc hệ thiết kế đa thương hiệu) tách hệ thống thành hai tầng riêng biệt. Tầng thứ nhất là foundation layer (lớp nền): chứa component logic, cấu trúc giao diện, chuẩn truy cập (accessibility), và các token kỹ thuật trung lập không mang màu sắc hay phông chữ của bất kỳ thương hiệu nào. Tầng thứ hai là brand layer (lớp thương hiệu): mỗi thương hiệu có một lớp riêng, chứa token màu, chữ, khoảng cách, và icon đặc trưng của thương hiệu đó, kế thừa và override (ghi đè) lên lớp nền.

Atlassian, IBM Carbon, Adobe Spectrum đều theo kiến trúc này với mức độ tinh chỉnh khác nhau. Điểm chung là lớp nền không biết mình sẽ trông như thế nào: nó chỉ biết mình hoạt động đúng. Diện mạo là quyết định của lớp thương hiệu phía trên.

Token hierarchy (chuỗi token) cần bao nhiêu cấp bậc

Theo W3C Design Tokens Community Group (DTCG), chuỗi kế thừa token nên có ít nhất bốn cấp để đủ linh hoạt cho đa thương hiệu:

• Primitive token (token nguyên thủy): giá trị thô, ví dụ màu xanh cụ thể theo mã hex, cỡ chữ 16px. Không thương hiệu nào dùng trực tiếp.
• Foundation semantic token (token ngữ nghĩa nền): gắn nghĩa kỹ thuật, ví dụ "màu nền chính", "cỡ chữ thân bài". Trung lập, chưa có màu thương hiệu.
• Brand semantic token (token ngữ nghĩa thương hiệu): từng thương hiệu gán giá trị cụ thể vào token ngữ nghĩa nền. Thương hiệu A gán màu xanh dương, thương hiệu B gán màu cam.
• Component token (token component): component tham chiếu brand semantic token, không gán giá trị cứng.

Khi onboard thương hiệu mới, đội chỉ cần điền giá trị vào brand semantic token là toàn bộ component tự áp đúng màu và chữ. Không cần chạm vào code component. Đây là lợi thế lớn nhất của chuỗi token đủ cấp bậc.

Quan hệ thương hiệu quyết định mức độ visual overlap

David Aaker trong Brand Portfolio Strategy (2004) phân biệt ba kiểu quan hệ thương hiệu trong tập đoàn: master brand (thương hiệu mẹ xuất hiện rõ), endorsed brand (thương hiệu mẹ bảo lãnh nhưng thứ yếu), và independent brand (thương hiệu hoàn toàn độc lập). Kiểu quan hệ này quyết định bao nhiêu visual overlap được phép.

Biết mình đang xây endorsed hay independent brand sẽ quyết định độ sâu của brand layer và chi phí duy trì tương ứng.

Governance (quản trị): phần hay bị bỏ qua nhất

Theo Nathan Curtis từ EightShapes, không có governance rõ ràng thì multi-brand system sẽ phân kỳ trong vòng một đến hai năm. Cần xác định rõ ba điều trước khi ra mắt hệ thống:

• Ai có quyền thêm hoặc sửa component ở foundation layer, và quy trình phê duyệt là gì.
• Thương hiệu thành viên được extend (mở rộng) đến đâu ở brand layer của mình mà không cần xin phép.
• Khi foundation layer update, brand layer nào phải update theo và theo lịch nào.

Design systems are products, not projects. They require ongoing investment, clear ownership, and a roadmap. Without that, they decay.

Nathan Curtis, EightShapes

Lỗi kiến trúc thường gặp

• Foundation layer bị nhiễm: một thương hiệu lớn trong tập đoàn yêu cầu thêm component đặc thù của mình vào lớp nền. Dần dần lớp nền mang bản sắc của thương hiệu đó, thương hiệu còn lại phải override liên tục hoặc bỏ cuộc và fork riêng.
• Token không đủ cấp: thương hiệu mới gia nhập không thể override chỉ visual, phải fork cả codebase và từ đó duy trì song song hai phiên bản.
• Figma library lộn xộn: designer của thương hiệu A nhìn thấy và nhầm dùng component đã áp màu của thương hiệu B. Cần tách library theo lớp, không gộp chung.
• Không có quy trình onboard: mỗi lần tập đoàn mua thêm thương hiệu mới, đội lại phải làm từ đầu vì không có quy trình chuẩn hóa. Mất lợi thế tốc độ là lý do chính để xây hệ thống này ngay từ đầu.

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

Sinh Vũ xếp dự án này vào nhóm phức tạp cao và yêu cầu nhiều buổi workshop kiến trúc trước khi bắt tay build. Quy trình Sinh Vũ thực hành là: audit thương hiệu hiện tại, vẽ brand relationship map (bản đồ quan hệ thương hiệu) để xác định mức độ visual overlap cho phép, thiết kế token hierarchy (chuỗi cấp bậc token), rồi mới bàn đến implementation. Không nhảy thẳng vào code khi chưa rõ kiến trúc.

Yêu cầu bắt buộc từ phía tập đoàn: cần có ít nhất một senior frontend engineer hiểu token system làm đầu mối kỹ thuật. Sinh Vũ thiết kế hệ thống và tư vấn quyết định kiến trúc, nhưng không thể vận hành bên trong codebase của tập đoàn thay cho đội kỹ thuật nội bộ.