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

Khi tập đoàn có nhiều thương hiệu cùng dùng chung một mã nguồn, câu hỏi không phải là "dùng chung được không" mà là "tách phần riêng bằng cách nào để hai năm sau hệ vẫn còn nhất quán". Nếu không có kiến trúc và quản trị rõ ràng ngay từ đầu, kết quả gần như chắc chắn là mỗi đội tự xử theo cách của mình, và hệ dùng chung trở thành hư cấu trên giấy.

Kiến trúc token ba tầng

Nền tảng của mọi design system (hệ thiết kế) phục vụ nhiều thương hiệu là token (đơn vị biến số thiết kế như màu sắc, khoảng cách, cỡ chữ) được phân thành ba tầng rõ ràng:

• Tầng nguyên thủy (primitive): toàn bộ giá trị thô của tập đoàn, ví dụ tất cả các màu trong bảng màu chính, tất cả bậc khoảng cách. Tầng này không ai dùng trực tiếp.
• Tầng ngữ nghĩa (semantic): gán ý nghĩa cho giá trị thô, ví dụ "màu nút chính", "màu nền cảnh báo". Đây là tầng lõi dùng chung, nhất quán giữa mọi thương hiệu.
• Tầng chủ đề (theme): mỗi thương hiệu có một thư mục riêng, chỉ ghi đè những giá trị ngữ nghĩa cần khác biệt. Thương hiệu A có màu nút chính là xanh biển, thương hiệu B chọn đỏ đô, lõi chung không thay đổi gì cả.

Nguyên tắc đặt tên token cũng cần có tầng vùng tên (namespace) để phân biệt: hệ nào, thương hiệu nào, miền nào. Không làm bước này, sau vài tháng token của thương hiệu này bị thương hiệu kia ghi đè mà không ai hay.

Mô hình đội: tập trung hay liên bang

Trong thực tế, hầu hết tập đoàn nên bắt đầu bằng mô hình tập trung, rồi chuyển dần sang liên bang khi từng thương hiệu đã hiểu hệ và có người có thể đóng góp có trách nhiệm.

Quản trị: phần không thể bỏ qua

Ở quy mô nhiều thương hiệu, design system không còn là vấn đề kỹ thuật thuần túy. Hai thứ tối thiểu cần có:

• Quy trình RFC (Request for Comment, tức đề xuất thay đổi có người duyệt): bất kỳ thay đổi nào ở lõi chung đều phải qua bước này. Ai đề xuất, ai duyệt, hạn bao lâu để các thương hiệu phản hồi. Không có bước này, một đội sửa lõi theo nhu cầu của mình sẽ vô tình phá vỡ trải nghiệm của thương hiệu khác.
• Đo mức áp dụng (adoption): biết được đội nào đang thực sự dùng hệ, đội nào đã âm thầm quay lại làm thủ công. Không đo thì không biết, không biết thì không sửa được.

Một design system không có quản trị là một thư viện component đang chờ phân rã.

Nathan Curtis, EightShapes

Lỗi thường gặp ở tập đoàn

• Fork mỗi thương hiệu một bản hệ riêng: ban đầu có vẻ linh hoạt, nhưng sau vài quý mỗi bản đi một hướng, cập nhật và sửa lỗi phải làm lại nhiều lần.
• Có thư viện component nhưng không có governance: thay đổi tùy tiện, thương hiệu này sửa phá thương hiệu kia mà không có cơ chế cảnh báo.
• Không đặt namespace trong token: phần chung và phần riêng trộn vào nhau, sau này muốn tách không tách được sạch.
• Để nhiều hệ song song tồn tại quá lâu mà không có kế hoạch hợp nhất: chi phí duy trì nhân lên, nhất quán giảm dần.

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

Đây là cấp độ cao nhất mà một design system có thể đạt đến. Cách Sinh Vũ tiếp cận là dựng token theo chuẩn DTCG (Design Token Community Group, định dạng token mở do cộng đồng thiết kế xây dựng) với lõi dùng chung và tầng chủ đề tách riêng cho từng thương hiệu, kèm quy trình RFC để mọi thay đổi đều có người đề xuất và người duyệt rõ ràng.

Về triển khai, Sinh Vũ thường chọn một sản phẩm điểm mẫu để chuyển sang hệ trước, kiểm chứng kiến trúc trong thực tế, rồi mới nhân rộng sang các thương hiệu còn lại. Cách này giúp phát hiện vấn đề sớm thay vì triển khai ồ ạt rồi mới biết thiếu sót.

Một lưu ý thực tế: hệ có thể xây rất tốt, nhưng nếu không có người chủ quản duy trì và tiến hóa theo thời gian, hệ sẽ dần bị bỏ qua. Ở quy mô tập đoàn, đây là bài toán điều phối nội bộ không kém phần quan trọng so với bài toán kỹ thuật. Anh / Chị nên cân nhắc kỹ cơ cấu đội và ngân sách bảo trì trước khi chốt phạm vi dự án.