Vì sao đội lặng lẽ bỏ thư viện để làm tay

Mỗi lần Sinh Vũ vào kiểm tra (audit) một hệ thiết kế đã chạy được vài tháng, điều thường thấy là hệ bị đội đi vòng qua. Figma (phần mềm thiết kế giao diện) có một bộ component, mã nguồn có một bộ khác, và một số đội 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 và token thiết kế, tức các giá trị màu, cỡ chữ, khoảng cách đã đặt tên sẵn) 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ý: đội có hạn chót và hệ đang đứng chắn giữa đường. Họ không bỏ hệ vì lười hay thiếu tôn trọng công sức xây dự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, hiếm khi do độ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 tập huấn.
• Không có cửa đóng góp. Đội thiếu gì mà không có chỗ báo về, họ sẽ tự đè ngay tại chỗ. Sau vài tháng, mã nguồn và Figma tích luỹ 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 hạn chót 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à còn có thêm nợ kỹ thuật (việc phải sửa lại về sau) 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 tuỳ 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, khi rê chuột (hover), khi được chọn (focus), lỗi, đang tải, rỗng. Làm vậy để đội không có cớ tự làm lại. Vỏ đẹp mà thiếu trạng thái thì chỉ là bản mẫu, chưa phải hệ.

Quy trình RFC (bản đề xuất thay đổi để cả đội góp ý) là cửa để đội đề xuất thay đổi có kiểm soát, thay vì âm thầm đè. Sinh Vũ áp dụng vì thiếu cửa đó thì mọi chỗ thiếu sẽ được vá ngoài hệ, và hệ mất dần sức nặng của một chuẩn chung.

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ó. Lý do là không đủ người bảo trì và không đủ nhu cầu dùng lại để hệ tự chứng minh giá trị. Lúc đó vấn đề nằm ở thời điểm, và ma sát chưa phải điều cần lo.

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