Cần bao nhiêu component là đủ

Anh/Chị đang xây design system (hệ thống thiết kế) và tự hỏi nên có bao nhiêu component (thành phần giao diện tái sử dụng) mới là đủ. Câu hỏi này không có đáp án tuyệt đối, nhưng có nguyên tắc rõ ràng: đủ để xây được phần lớn màn hình thực tế của sản phẩm mà không cần thiết kế lại từ đầu. Quá ít thì đội mất tính nhất quán. Quá nhiều thì chi phí bảo trì vượt giá trị thực sự nhận được.

Tại sao số nhiều chưa chắc tốt

Nhiều người xây design system theo cách liệt kê component từ thư viện nước ngoài hoặc học theo Material Design, Ant Design rồi cố sao chép quy mô. Đây là sai lầm phổ biến nhất Sinh Vũ gặp khi làm việc với khách.

Material Design hay Ant Design phục vụ hàng nghìn sản phẩm khác nhau, nên buộc phải phủ rộng. Sản phẩm của Anh/Chị chỉ cần phục vụ một bộ màn hình xác định. Mỗi component trong thư viện là một cam kết: phải viết test, phải có tài liệu, phải cập nhật khi token (đơn vị thiết kế như màu sắc, kích thước) thay đổi. Đội nhỏ không thể bảo trì 200 component mà vẫn giữ chất lượng.

Khi thư viện phình quá mức, đội kỹ thuật bắt đầu bỏ qua và tự vẽ lại. Lúc đó design system tuy nhìn ấn tượng về số lượng nhưng thực tế đã mất tác dụng.

Các yếu tố quyết định phạm vi

• Loại sản phẩm: SaaS B2B nhiều biểu mẫu và bảng dữ liệu cần bộ component khác với ứng dụng nội dung thiên về trình bày văn bản và thẻ thông tin.
• Số màn hình thực tế: hãy đếm các màn hình trong sản phẩm và xác định pattern (mẫu giao diện) nào xuất hiện ít nhất 2 đến 3 lần mới đáng xây thành component.
• Năng lực bảo trì: đội nhỏ 1 đến 2 người không thể bảo trì thư viện lớn. Phạm vi phải khớp với nguồn lực thực tế, không phải tham vọng lý thuyết.
• Tần suất sử dụng: component dùng một lần không cần vào thư viện. Làm trực tiếp trong file thiết kế là đủ và nhanh hơn.

Khi nào chọn quy mô nào

Lỗi thường gặp

• Xây component theo cảm tính hoặc sao chép danh sách từ thư viện nước ngoài mà không kiểm kê sản phẩm thực tế trước.
• Chia component quá nhỏ, gọi là micro-component, khiến đội kỹ thuật phải lắp ghép quá nhiều mảnh chỉ để tạo ra một giao diện đơn giản.
• Nhầm lẫn giữa component (tái sử dụng nhiều lần) và template (cấu trúc một lần), rồi nhét cả hai vào thư viện component.
• Không có chính sách loại bỏ (deprecation policy): component cũ tích tụ theo thời gian, không ai dám xóa vì không biết còn ai đang dùng.

Thường 20 đến 30 component lõi đã bao phủ được phần lớn giao diện. Phần còn lại là đuôi dài, xuất hiện thưa thớt và chỉ nên xây khi sản phẩm thực sự cần.

Nguyên tắc Pareto 80/20, ứng dụng trong thực hành design systems

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

Sinh Vũ bắt đầu mọi dự án design system bằng bước kiểm kê: liệt kê toàn bộ màn hình của sản phẩm, đếm tần suất xuất hiện của từng pattern giao diện, chỉ đưa vào thư viện những gì xuất hiện ít nhất 3 lần. Bước này mất vài buổi làm việc nhưng tiết kiệm nhiều tháng bảo trì về sau.

Gói cơ bản của Sinh Vũ bắt đầu từ 40 component vì sau bước kiểm kê đó, con số này thường đủ cho SaaS nhỏ đến vừa. Quan trọng hơn con số là cơ chế quản trị: ai được đề xuất component mới, ai review, ai phê duyệt. Governance (quản trị thư viện) tốt thì thư viện 40 component còn có giá trị lâu dài hơn thư viện 200 component không ai kiểm soát.

Dấu hiệu để dừng lại và đánh giá lại phạm vi: khi tỷ lệ component trong thư viện nhưng không xuất hiện trong sản phẩm vượt 30 phần trăm, đó là lúc cần thu gọn chứ không phải mở rộng thêm.