Giữ nhất quán khi sản phẩm lớn lên
Không phải thiếu chuẩn, mà là không ai giữ chuẩn đó, sản phẩm mới trôi dần.
Khi sản phẩm lớn lên, mối nguy lớn nhất không phải thiếu tài sản thiết kế mà là để chúng trôi dần khỏi ý định ban đầu qua từng chi tiết nhỏ tích lũy. Cách giữ nhất quán bền là quản trị hệ thiết kế như một sản phẩm sống: có người sở hữu, có tiêu chí duyệt thay đổi, có nơi tái dùng chung thay vì mỗi nhóm tự chế. Sinh Vũ xây hệ kèm hướng dẫn vận hành để đội khách tự giữ nhất quán mà không phụ thuộc vào một cá nhân cụ thể.
Sản phẩm càng lớn, hệ thiết kế càng dễ trôi. Không phải vì đội thiếu cẩn thận, mà vì mỗi quyết định nhỏ lọt lưới, cộng dồn qua nhiều nhóm và nhiều tháng, rồi một ngày nhìn lại thấy sản phẩm đang chạy đã lệch khá xa so với bộ nhận diện ban đầu. Sinh Vũ gọi đây là design drift (trôi thiết kế), và đây là bài toán quản trị, không đơn thuần là bài toán kỹ thuật.
Tại sao nhất quán vỡ dần
Nhất quán không vỡ trong một ngày. Nó vỡ từng mảnh nhỏ: một màu hơi sai vì không ai so chuẩn, một khoảng cách chữ tự ý điều chỉnh vì file cũ không mở được, một thành phần giao diện tự chế vì không biết đã có sẵn trong hệ. Mỗi cái riêng lẻ đều trông không đáng kể. Nhưng nhân lên qua ba nhóm, sáu tháng, hai nền tảng, kết quả là sản phẩm thật đang chạy và bộ chuẩn trên giấy không còn trỏ vào cùng một thứ.
Lỗi gốc thường là một trong ba: không ai được giao sở hữu hệ, hệ được coi là tài liệu đã xong thay vì sản phẩm cần cập nhật, hoặc mọi người đóng góp thành phần mới mà không có tiêu chí nào để lọc.
Quản trị hệ như sản phẩm sống
Hike One đúc kết ngắn gọn: hệ thiết kế cần backlog (danh sách việc tồn đọng), lộ trình và vòng phản hồi đều đặn, không phải là một file đóng gói rồi để đó. Khi thiếu ba thứ này, hệ sẽ tự già đi trong khi sản phẩm tiếp tục chạy tiếp.
Quản trị hệ thiết kế như quản trị một sản phẩm: cần người sở hữu, lộ trình, và vòng phản hồi đều đặn.
Hike One, Making a Design System Work at Scale
Trong thực tế, điều này có nghĩa là:
- Có một người hoặc một nhóm nhỏ được giao trách nhiệm rõ ràng: ai duyệt thành phần mới vào lõi chung, ai đánh dấu chỗ không nhất quán cần sửa.
- Có tiêu chí để quyết định thứ gì được đưa vào lõi chung, thứ gì để lại là mẫu riêng của từng nhóm.
- Có nhịp rà soát định kỳ, không chờ đến khi vấn đề lộ ra mới xử lý.
Chọn mô hình phù hợp quy mô
Mô hình một người sở hữu (solitary): phù hợp với đội nhỏ, startup hoặc sản phẩm ít người cùng đụng vào hệ. Nhanh và gọn, nhưng dễ trở thành điểm nghẽn khi đội lớn hơn.
Mô hình liên bang (federated): phù hợp khi có nhiều nhóm sản phẩm. Mỗi nhóm cử một người đại diện đóng góp, nhưng mọi đóng góp đều chiếu theo một lõi chung. Tốc độ được giữ, nhất quán có người canh.
Không có mô hình nào đúng tuyệt đối. Điểm cần quyết định là: đội Anh / Chị đang ở đâu trong hành trình đó, và mô hình hiện tại còn phù hợp với quy mô hiện tại không.
Phân tầng: cái gì cần siết, cái gì được thở
Một sai lầm phổ biến là siết đều tất cả hoặc buông lỏng tất cả. Cả hai đều gây hại: siết đều thì đội không dám động vào hệ, buông lỏng thì thương hiệu vỡ từ lớp nền.
Sinh Vũ phân tầng theo mức ảnh hưởng:
- Mức thương hiệu (màu chủ đạo, kiểu chữ, logo, giọng điệu): duyệt nghiêm nhất, thay đổi phải qua người có thẩm quyền rõ ràng.
- Mức thành phần giao diện chung (nút bấm, bảng, biểu mẫu): có tiêu chí vào lõi, đóng góp cần duyệt nhưng không cần leo thang lên cấp thương hiệu.
- Mức mẫu đặc thù từng nhóm: linh hoạt hơn, nhóm tự quyết miễn dùng đúng nền tảng chung bên dưới.
Xác định rõ ai được đề xuất thành phần mới, tiêu chí để thành phần đó vào lõi chung so với ở lại thư viện riêng của nhóm.
Figma, Design System Scaling
Góc nhìn của Sinh Vũ
Sinh Vũ xây hệ thiết kế trên nền nhận diện thương hiệu đã được xác lập, và bàn giao kèm hướng dẫn vận hành cụ thể để đội khách tự cập nhật. Mục tiêu là đội không phụ thuộc vào một người hay vào Sinh Vũ để giữ nhất quán.
Điều này quan trọng hơn hẳn ở giai đoạn sản phẩm vượt quy mô một website đơn lẻ và trở thành nền tảng nhiều nhóm cùng vận hành. Lúc đó, thứ quyết định nhất quán không còn là chất lượng file thiết kế, mà là ai đang giữ hệ đó và giữ theo nguyên tắc gì. Với những dự án ở quy mô này, phần quản trị cần bàn kỹ theo thực tế cụ thể của từng khách, không có công thức chung áp được cho tất cả.
Nguồn tham khảo
Figma Resource Library, Design System Scaling; Hike One, Making a Design System Work at Scale; Nielsen Norman Group, Your Design System Needs an Enforcer. Kinh nghiệm thực hành Sinh Vũ Studio.
Câu hỏi thường gặp
Khi nào cần bắt đầu lo chuyện quản trị hệ thiết kế?
Dấu hiệu rõ nhất là khi có từ hai nhóm trở lên cùng đụng vào hệ, hoặc sản phẩm mở rộng sang nền tảng mới như từ web sang ứng dụng di động. Lúc đó nếu không có người sở hữu và quy trình duyệt, từng nhóm sẽ tự chế thành phần riêng và nhất quán vỡ dần theo thời gian.
Một người có thể vừa thiết kế vừa giữ hệ không?
Được, nếu đội còn nhỏ và ít người cùng đụng vào. Nhưng khi đội lớn hơn, một người vừa làm vừa giữ hệ sẽ trở thành điểm nghẽn, vì mọi thay đổi đều chờ một mình họ duyệt. Lúc đó cần chuyển sang mô hình có tiêu chí rõ để nhiều người cùng đóng góp có kiểm soát.
Cần siết chặt toàn bộ hay chỉ một phần của hệ?
Không cần siết đều. Phần thuộc mức thương hiệu như màu chủ đạo, kiểu chữ, logo và giọng điệu cần duyệt nghiêm nhất vì sai ở đây ảnh hưởng toàn bộ hệ. Mẫu giao diện đặc thù của từng nhóm sản phẩm có thể linh hoạt hơn, miễn vẫn dùng đúng nền tảng chung.