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 không phải "có nên xây hệ thiết kế số không" mà là "xây đến mức nào và xây lúc nào". Bài toán kinh tế ở đây rất rõ: một component tốn nhiều công để dựng đúng, nhưng khi được tái sử dụng ở hàng chục nơi trong tổ chức đa sản phẩm, chi phí đó được chia đều. Mức đầu tư hợp lý không phụ thuộc tham vọng mà phụ thuộc số đội đang cùng đụng vào giao diện.

Ba mức đầu tư theo bài toán

Sinh Vũ chia mức đầu tư thành ba bậc, tương ứng với giai đoạn và quy mô thực tế:

• Mức 1: Nền tảng token. Dành cho một đến hai sản phẩm, đội dưới năm người, còn đang tìm sự phù hợp sản phẩm-thị trường (product-market fit, tức giai đoạn chưa xác định được sản phẩm đúng nhu cầu thị trường). Chuẩn hóa màu sắc, kiểu chữ, khoảng cách thành các biến token theo chuẩn DTCG (Design Tokens Community Group, chuẩn chung của ngành). Thêm mười đến hai mươi component dùng nhiều nhất. Đủ để thống nhất giao diện mà không bị hệ trói buộc khi sản phẩm còn đổi hướng thường xuyên.
• Mức 2: Hệ thống đầy đủ. Dành cho đội thiết kế và kỹ thuật cùng làm trên nhiều sản phẩm song song, khi cùng một component đang bị code lại ở nhiều nơi. Thư viện bốn mươi đến tám mươi component lõi, tài liệu Storybook, nối một đổi một với Figma. Đây là mức đáng đầu tư nhất với SaaS B2B trưởng thành.
• Mức 3: Hệ có quản trị. Dành cho tổ chức nhiều đội nội bộ và đối tác cùng dùng. Bổ sung quy trình RFC (Request for Comment, tức quy trình đề xuất thay đổi có phản hồi cộng đồng), chỉ số đo độ áp dụng, và mô hình đội liên bang (federated) để mỗi sản phẩm vừa dùng vừa đóng góp ngược vào hệ.

Các yếu tố quyết định mức

Trước khi chọn mức, Anh Chị cần trả lời thành thật mấy câu hỏi này:

• Hiện tại có bao nhiêu sản phẩm và bao nhiêu đội cùng đụng giao diện?
• Cùng một component, như bảng dữ liệu hoặc form lọc, đang bị code riêng ở bao nhiêu chỗ?
• Sản phẩm đã có người dùng thật và đang mở rộng, hay vẫn đang thử nghiệm?
• Sau khi dựng hệ, ai là người chủ quản để duy trì và tiếp nhận yêu cầu thay đổi?
• Đội đang chạy song song bao nhiêu khung công nghệ (framework), ví dụ React, Vue?

Với SaaS B2B, giao diện thường dày đặc: bảng, form, biểu đồ, bộ lọc lồng nhau. Sự thiếu nhất quán giữa các module không chỉ là vấn đề thẩm mỹ mà ảnh hưởng trực tiếp đến tốc độ học của người dùng doanh nghiệp, vốn phải thao tác lặp đi lặp lại hàng ngày.

Lỗi thường gặp

• Dựng hệ đầy đủ khi mới một sản phẩm và đội dưới ba người. Kết quả thường là hệ bị bỏ xó sau vài tháng vì không ai có thời gian duy trì.
• Thiết kế token và component trong Figma nhưng không nối với code sản xuất thật. Đội kỹ thuật vẫn code lại từ đầu vì không tin tưởng tài liệu.
• Không cử người chủ quản. Hệ đứng yên trong khi sản phẩm tiến, sau vài quý đội bắt đầu bỏ qua hệ và tạo nhánh riêng.
• Chạy theo số lượng component thay vì độ phủ các tình huống giao diện thật. Một hệ có hai trăm component nhưng thiếu trạng thái lỗi của form hay skeleton loading của bảng thì vẫn chưa đủ dùng.

Cách tiếp cận theo component trả cổ tức ngay cả với sản phẩm nhỏ nhất. Mấu chốt là nghĩ về tái sử dụng từ đầu, chứ chưa cần độ đánh bóng cấp doanh nghiệp.

Brad Frost, Design Systems Q&A

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

Với các dự án SaaS B2B, Sinh Vũ bắt đầu bằng rà soát giao diện hiện có, tìm các component đang bị lặp và chuẩn hóa thành token theo chuẩn DTCG. Bước này thường phát hiện ra rằng đội đang duy trì ba đến năm biến thể của cùng một màu nút bấm mà không ai biết cái nào đúng.

Sau đó mới dựng component lõi, ưu tiên những thứ xuất hiện nhiều nhất trong sản phẩm thật chứ không theo danh sách component của hệ thiết kế nổi tiếng. Với SaaS B2B, bảng dữ liệu phức tạp, form nhiều bước, và trạng thái rỗng thường quan trọng hơn nhiều so với carousel hay avatar.

Một điều Sinh Vũ nói thẳng: nếu đội kỹ thuật dưới ba người hoặc sản phẩm chưa có người dùng thật, tập trung MVP trước, hệ thiết kế sau. Đầu tư vào hệ lúc sản phẩm chưa tìm được product-market fit là đặt cược sai thứ tự.

Mô hình đội quản hệ nên dịch chuyển dần từ đội tập trung sang liên bang khi số sản phẩm tăng, để mỗi sản phẩm vừa dùng vừa đóng góp ngược.

Nathan Curtis, Team Models for Scaling a Design System (EightShapes)