Vì sao đội âm thầm bỏ hệ để làm thủ công

Mỗi lần Sinh Vũ vào audit một hệ thiết kế đã chạy được vài tháng, điều thường thấy không phải là hệ bị phá, mà là hệ bị vòng vèo qua: Figma có một bộ component, code có một bộ khác, và một số đội đang dùng cả hai lẫn một bộ tự chế thứ ba. Không ai nổi loạn, mọi người chỉ chọn con đường ít cản trở hơn.

Nguyên nhân gốc là ma sát, không phải ý thức

Khi làm đúng theo hệ (dùng component chuẩn, theo token thiết kế) tốn nhiều bước hơn tự kéo một khung mới và chỉnh tay, người ta sẽ chọn chỉnh tay. Đây là hành vi hợp lý, không phải bất tuân. Đội không bỏ hệ vì lười hay không tôn trọng công sức xây dựng, mà vì họ có deadline và hệ đang đứng chắn giữa đường.

Theo tổng hợp thực hành của Design Systems Collective, tỉ lệ dùng thấp gần như luôn bắt nguồn từ ma sát chứ không phải thiếu nhận thức. Ra lệnh bắt tuân thủ mà không giảm ma sát chỉ làm chống đối chuyển từ công khai sang ngầm.

Bốn nguồn ma sát thường gặp

• Component thiếu trạng thái thật. Hệ chỉ có trạng thái mặc định, không có trạng thái lỗi, trạng thái tải, trạng thái rỗng. Đội gặp tình huống thật thì không dùng được, phải tự làm thêm, rồi lần sau không buồn tra nữa.
• Tài liệu khó tra. Đội không biết component đã có hay chưa, nên tự làm cho chắc. Một trang tìm kiếm tốt tiết kiệm công hơn mười buổi training.
• Không có cửa đóng góp. Đội thiếu gì mà không có chỗ báo về, họ sẽ tự đè (override) tại chỗ. Sau vài tháng, codebase và Figma tích lũy hàng chục bản đè không được ghi nhận, hệ loãng dần mà không ai biết từ lúc nào.
• Cách ra mắt ép từ trên xuống. Hệ được công bố bằng một lệnh chuyển đổi có hạn mà không có giai đoạn hỗ trợ. Đội chuyển trên danh nghĩa nhưng giữ bản làm tay như bản dự phòng, rồi bản dự phòng trở thành bản thật.

Khi nào ưu tiên hướng nào

Lỗi hay gặp khi xử lý tình trạng này

• Đặt deadline bắt chuyển khi hệ chưa sẵn sàng. Kết quả là đội chuyển hình thức, tự đè vẫn tiếp tục, và giờ có thêm nợ kỹ thuật từ việc chuyển nửa vời.
• Không theo dõi bản đè sau khi ra mắt. Nếu không đo được đội đang tự làm ở đâu, không biết component nào cần bổ sung gấp nhất.
• Component quá cứng, không có điểm tùy biến có kiểm soát. Đội cần linh hoạt, nếu hệ không cho, họ tách ra trong Figma và làm lại bằng tay từ đầu. Brad Frost nhấn trong Atomic Design rằng duy trì hệ đòi hỏi vừa đủ cứng để nhất quán, vừa đủ mềm để phủ nhu cầu thật.

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

Khi Sinh Vũ xây component, yêu cầu tối thiểu là đủ trạng thái thật: mặc định, hover, focus, lỗi, tải, rỗng. Không phải để đẹp, mà để đội không có cớ tự làm lại. Vỏ đẹp mà thiếu trạng thái thì chỉ là template, không phải hệ.

Quy trình RFC là cửa để đội đề xuất thay đổi có kiểm soát, thay vì âm thầm đè. Sinh Vũ áp dụng nó không vì thủ tục, mà vì không có cửa đó thì mọi thứ thiếu sẽ được vá ngoài hệ, và hệ mất dần tính thẩm quyền.

Một điều Sinh Vũ nói thẳng với khách: nếu đội kỹ thuật quá nhỏ hoặc sản phẩm chưa có người dùng thật, hệ sẽ bị bỏ xó vì không đủ người bảo trì và không đủ nhu cầu tái sử dụng để hệ tự chứng minh giá trị. Lúc đó không phải vấn đề ma sát mà là vấn đề thời điểm.

Một quy trình quản trị rõ ràng là điều kiện để hệ tồn tại lâu dài. Thiếu nó, mỗi đội tinh chỉnh theo cách riêng, các bản đè chồng lên nhau và hệ vỡ dần mà không có điểm chịu trách nhiệm.

Brad Frost, A Design System Governance Process