SaaS B2B đa sản phẩm cần hệ thiết kế số tới mức nào

Với SaaS B2B đa sản phẩm, câu hỏi đúng không phải "có nên làm design system không" mà là "làm lúc nào và làm bao nhiêu". Làm quá sớm thì lãng phí vì phải viết lại. Làm quá trễ thì nợ kỹ thuật giao diện tích lũy âm thầm, đến lúc phát hiện thì chi phí sửa đã lớn hơn chi phí làm từ đầu.

Hai ngưỡng quyết định

Sinh Vũ dùng hai ngưỡng để xác định thời điểm:

• Ngưỡng đội: Khi đội kỹ thuật vượt 4 đến 5 kỹ sư, chi phí phối hợp tăng nhanh. Kỹ sư mới mất nhiều tuần để hiểu các pattern giao diện không được ghi chép. Lúc này, design system không còn là công cụ thiết kế mà là cơ chế phối hợp tổ chức, đúng như Conway's Law mô tả từ năm 1968: cấu trúc phần mềm phản chiếu cấu trúc giao tiếp của đội xây nó.
• Ngưỡng sản phẩm: Khi đã có khách hàng trả tiền và giao diện cần giữ ổn định qua các lần cập nhật. Nielsen Norman Group nhấn mạnh tính nhất quán là nguyên tắc cốt lõi về khả năng sử dụng (usability): người dùng kỳ vọng các thành phần tương tự hoạt động giống nhau xuyên suốt sản phẩm. Phá vỡ kỳ vọng đó có chi phí thực: khách hàng enterprise phàn nàn, đội hỗ trợ mất thêm giờ giải thích.

Chưa chạm cả hai ngưỡng thì chưa cần đầu tư bài bản. Chạm một trong hai thì bắt đầu chuẩn bị nền, chạm cả hai thì làm ngay.

Yếu tố đặc thù SaaS B2B cần cân nhắc thêm

• Số module và vòng lặp release: Càng nhiều module, chi phí không nhất quán tích lũy càng nhanh. Nhịp release nhanh cần component tái sử dụng được, nếu không mỗi tính năng mới lại kéo theo một bộ giao diện riêng.
• Dashboard và data visualization (biểu đồ dữ liệu): SaaS B2B thường có màn hình báo cáo phức tạp. Đây là nơi component lặp lại nhiều nhất và cũng là nơi thiếu nhất quán dễ thấy nhất.
• Yêu cầu white-label hoặc theming: Nếu khách hàng enterprise yêu cầu giao diện mang màu sắc thương hiệu của họ, bắt buộc phải có design token (lớp trừu tượng hóa giá trị thiết kế như màu, khoảng cách, bo góc) tách rời khỏi component. Không có token thì mỗi khách là một lần sửa thủ công, dễ lỗi và không thể nhân rộng.

Lỗi thường gặp khi xây design system cho SaaS

• Xây quá sớm khi giao diện chưa ổn định: Token và component phải viết lại khi sản phẩm pivot. Lãng phí cả thời gian lẫn ngân sách.
• Thiếu người ownership rõ ràng: Không có kỹ sư hoặc designer chịu trách nhiệm chính thì system bị bỏ xó sau vài tháng. Component mới không được đưa vào thư viện, tài liệu không được cập nhật.
• Thiết lập token sai cấp độ: Design token có ba cấp: global (giá trị gốc như màu hex), alias (tên ngữ nghĩa như màu nền chính), và component-level (màu nền nút). Bỏ qua cấp alias khiến việc theming sau này phải sửa từng component một.
• Scope quá lớn ngay từ đầu: Một thư viện 200 component khi sản phẩm thực tế chỉ dùng 40 sẽ kéo dài thời gian xây, tạo tài liệu không ai đọc và component không ai dùng.
• Không có Storybook hoặc tài liệu: Kỹ sư mới không biết component nào đã có, dẫn đến viết lại song song, phá vỡ mục đích của thư viện.
• Design-code drift: Figma và code bị lệch khi không có quy trình đồng bộ token. Kỹ sư implement theo code cũ, designer thiết kế theo Figma mới, hai bên không gặp nhau.

Cấu trúc phần mềm phản chiếu cấu trúc giao tiếp của tổ chức xây dựng nó.

Melvin Conway, 1968

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

Sinh Vũ khuyên SaaS B2B bắt đầu từ gói 40 đến 80 component cốt lõi, không nhiều hơn. Liệt kê các màn hình thực tế, đếm pattern lặp lại ít nhất 5 lần, đó là danh sách ưu tiên.

Về kỹ thuật: dùng chuẩn DTCG (Design Tokens Community Group) của W3C từ đầu để không bị phụ thuộc vào một bộ công cụ duy nhất. Phương pháp Atomic Design của Brad Frost giúp tổ chức component theo cấp bậc rõ ràng từ atom nhỏ nhất đến template hoàn chỉnh, giúp đội mới onboard nhanh hơn và giảm trùng lặp.

Sau khi giao hệ thiết kế, đội kỹ thuật của Anh / Chị cần ít nhất một kỹ sư quen với Storybook để tự mở rộng thư viện về sau. Nếu không có người đó, hệ thiết kế sẽ đông cứng ở phiên bản ban đầu và mất giá trị nhanh. Sinh Vũ không bao gồm dịch vụ bảo trì dài hạn trong gói mặc định: nếu Anh / Chị cần, cần thương thảo retainer riêng.

Điểm Sinh Vũ muốn nhấn mạnh: design system không phải dự án làm một lần rồi thôi. Nó là sản phẩm nội bộ, cần được đối xử như một sản phẩm thực thụ với owner, backlog và lịch cập nhật.