Phần mềm cho doanh nghiệp: cần thư viện tới mức nào

Với SaaS B2B (phần mềm doanh nghiệp bán theo thuê bao) đa sản phẩm, câu hỏi không phải là có nên xây hệ thiết kế số, mà là xây đến mức nào và xây lúc nào. Hệ thiết kế số là bộ thành phần giao diện và quy tắc dùng chung cho mọi sản phẩm. Bài toán chi phí ở đây khá rõ. Một thành phần giao diện (như nút bấm, bảng dữ liệu, ô nhập liệu) tốn nhiều công để dựng đúng. Khi được dùng lại ở 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ý tuỳ vào số đội đang cùng sửa 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 sản phẩm, đội dưới ba người. Giai đoạn này vẫn 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 hoá 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ệ thiết kế 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 gồm bốn mươi đến tám mươi component lõi. Tài liệu ghi bằng Storybook (công cụ ghi tài liệu cho từng component ngay trong mã). Mỗi component trong Figma (phần mềm thiết kế giao diện) có một bản tương ứng trong mã. Đâ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 Comments, tức quy trình đề xuất thay đổi có phản hồi cộng đồng) và chỉ số đo mức độ các đội đang dùng hệ. Thêm mô hình đội liên bang (federated), nghĩa là mỗi sản phẩm vừa dùng hệ 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, biểu mẫu, biểu đồ, bộ lọc lồng nhau. Thiếu nhất quán giữa các module (phân hệ chức năng) không chỉ là vấn đề thẩm mỹ. Nó ảnh hưởng trực tiếp đến tốc độ học của người dùng doanh nghiệp, những người 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 mã đang chạy thật của sản phẩm. Đội kỹ thuật vẫn làm lại từ đầu vì không tin 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 báo lỗi của biểu mẫu, hay khung xám giữ chỗ khi bảng đang tải dữ liệu (skeleton loading), thì vẫn chưa đủ dùng.

Ngay cả sản phẩm nhỏ cũng nên nghĩ tới chuyện dùng lại từ đầu: đặt tên token, tách vài component lõi. Nhưng chưa cần dựng cả hệ hay chăm chút đến mức của doanh nghiệp lớn.

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 hoá 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, biểu mẫu nhiều bước, và trạng thái rỗng (màn hình hiện ra khi chưa có dữ liệu) thường quan trọng hơn nhiều so với băng chuyền ảnh (carousel) hay ảnh đại diện (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 làm MVP (bản sản phẩm tối thiểu đủ để thử với người dùng thật) trước, hệ thiết kế đầy đủ để sau. Đầu tư vào hệ lúc sản phẩm chưa tìm được sự phù hợp với thị trường (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)