Ai nên sở hữu và chịu trách nhiệm design system

Chốt nhanh

Design system cần một người hoặc nhóm nhỏ chịu trách nhiệm dứt khoát, không thể là tài sản chung mà không ai chủ trì. Mô hình bền vững nhất với hầu hết tổ chức là Federated: một nhóm nhỏ giữ nền và chuẩn, các đội sản phẩm đóng góp qua quy trình có kiểm soát. Nếu tổ chức chưa đủ headcount, chỉ định một cá nhân làm Design System Lead kiêm nhiệm nhưng phải bảo vệ thời gian của người đó cho công việc này.

Design system không có người chủ trì rõ ràng là design system sẽ chết dần. Không phải chết đột ngột mà chết từ từ: component bị sửa mà không thông báo, token bị ghi đè vì không ai ngăn lại, đội sản phẩm thứ hai tự fork hệ thống riêng vì hệ thống chung phản hồi chậm. Câu hỏi về ownership không phải câu hỏi kỹ thuật, đây là câu hỏi quản trị.

Ba mô hình quản trị phổ biến

Nathan Curtis của EightShapes, một trong những người nghiên cứu kỹ nhất về design system governance (quản trị hệ thống thiết kế), mô tả ba mô hình chính:

Centralized (tập trung): một nhóm hoặc một người kiểm soát toàn bộ. Nhất quán cao, nhưng dễ trở thành nút thắt cổ chai khi đội sản phẩm lớn dần.
Federated (liên bang): một nhóm nhỏ giữ nền và chuẩn, các đội sản phẩm đóng góp component qua quy trình đề xuất có kiểm soát. Đây là mô hình phần lớn tổ chức trưởng thành dùng vì cân bằng được tốc độ và nhất quán.
Anarchy (vô chính phủ): ai cũng tự thêm, không có chuẩn kiểm soát. Nhanh trong ngắn hạn, vỡ chuẩn trong dài hạn. Sinh Vũ không khuyến nghị mô hình này trong bất kỳ tình huống nào nếu Anh/Chị muốn hệ thống sống lâu.

Mỗi tài sản quan trọng cần có một cá nhân hoặc nhóm có thể bị quy trách nhiệm. Design system không có người chủ trì rõ ràng là design system sẽ chết dần.
Nguyên tắc Single Wring-able Neck, IT Project Management literature

Khi nào chọn mô hình nào

Dùng Centralized khi đội dưới 20 người hoặc chỉ có một sản phẩm duy nhất. Một người giữ toàn bộ, cả đội biết người đó là ai và đi qua họ khi cần thay đổi.

Dùng Federated khi có từ ba đội sản phẩm trở lên, mỗi đội có designer và developer riêng. Nhóm core giữ token và component nền, các đội đề xuất component mới qua RFC (Request for Comments, quy trình đề xuất có văn bản) trước khi được thêm vào hệ thống chung.

Dùng cá nhân Lead kiêm nhiệm khi chưa đủ headcount cho nhóm riêng, nhưng phải bảo vệ thời gian của người đó cho design system, không thể để feature work lấn hết.

Phân định RACI cho design system

RACI là khung phân công trách nhiệm gồm bốn vai: Responsible (người làm việc thực tế), Accountable (người chịu trách nhiệm kết quả cuối), Consulted (người được hỏi ý kiến), Informed (người được thông báo khi có thay đổi). Áp dụng vào design system, Anh/Chị cần trả lời bốn câu hỏi này trước khi bắt đầu xây:

Ai là người thực sự ngồi xử lý công việc hàng ngày của hệ thống?
Ai có quyền từ chối component không đạt chuẩn? Đây là điểm quan trọng nhất vì không có quyền từ chối thì không có chuẩn.
Ai cần được hỏi ý kiến khi có thay đổi lớn ảnh hưởng nhiều đội?
Ai cần được thông báo mỗi khi hệ thống cập nhật?

Ownership trên giấy không đủ. VP Design có thể là Accountable, nhưng nếu không có Responsible cụ thể làm việc thực tế hàng ngày thì hệ thống vẫn không có chủ.

Lỗi thường gặp về ownership

Giao cho junior designer kiêm nhiệm mà không có thẩm quyền từ chối: khi không ai sợ bị từ chối, ai cũng bỏ qua chuẩn.
Không có ngân sách duy trì riêng: mỗi lần cần cập nhật phải xin phép manager từng lần, design system bị trì hoãn liên tục.
Senior tự xây một mình rồi nghỉ việc: toàn bộ kiến thức về quyết định thiết kế mất theo người đó.
Không có quy trình đề xuất component mới: các đội sản phẩm tự thêm, chuẩn vỡ dần mà không ai nhận ra.
Ownership trên giấy nhưng không ai làm việc thực tế: tình trạng này phổ biến hơn Anh/Chị nghĩ.

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

Sinh Vũ thiết lập ownership ngay trong giai đoạn kickoff, trước khi bắt đầu xây bất kỳ component nào. Buổi làm việc đầu tiên thường bao gồm phiên làm rõ RACI nội bộ của khách để Sinh Vũ biết ai là đầu mối kỹ thuật, ai là đầu mối thiết kế, và ai có quyền phê duyệt khi token thay đổi. Nếu khách chưa có câu trả lời cho ba câu hỏi đó, đó là việc cần giải quyết trước khi Figma được mở ra.

Lý do đơn giản: Sinh Vũ có thể xây hệ thống tốt nhất có thể, nhưng nếu bàn giao về cho một tổ chức không có người giữ nó, hệ thống đó sẽ trở thành tài liệu lưu trữ trong vòng sáu tháng. Ownership không phải chi tiết vận hành, đó là điều kiện để design system có giá trị lâu dài.

Nguồn tham khảo

Nathan Curtis, EightShapes, Design System Governance (2017-2022). RACI model, Project Management Institute. Single Wring-able Neck principle, IT Project Management literature. Kinh nghiệm thực hành Sinh Vũ Studio.

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

Có thể để VP Design chịu trách nhiệm design system không?

Có thể ghi trên giấy, nhưng nếu không có ai làm việc thực tế hàng ngày thì ownership đó không có nghĩa gì. Vấn đề không phải chức danh mà là ai ngồi xử lý pull request, ai từ chối component không đạt chuẩn, ai viết changelog mỗi khi có thay đổi. Cần phân biệt rõ Accountable (chịu trách nhiệm kết quả) và Responsible (người làm việc thực tế).

Nếu designer lead nghỉ việc, design system có mất theo không?

Rủi ro này có thật và thường gặp hơn Anh/Chị nghĩ. Cách giảm thiểu là viết tài liệu quyết định, duy trì quy trình đề xuất thành văn bản, và không để kiến thức hệ thống nằm trong đầu một người duy nhất. Federated model giúp ích ở điểm này vì nhiều người cùng hiểu hệ thống, không chỉ một người.

Đội nhỏ 5 người có cần phân công ownership design system không?

Có, dù đơn giản hơn. Ở quy mô nhỏ, Centralized là hợp lý: một người giữ và quyết định toàn bộ. Điều quan trọng là cả đội biết người đó là ai và khi cần thay đổi thì đi qua họ, không phải tự ý sửa.