Bao nhiêu sản phẩm số hoặc người dùng thì đáng đầu tư design system

Chốt nhanh

Không có ngưỡng số người dùng nào tất yếu khởi động nhu cầu design system (hệ thống thiết kế dùng chung). Tiêu chí quyết định là số lần component (thành phần giao diện) được tái sử dụng, tốc độ ra tính năng mới, và chi phí phối hợp nội bộ, những thứ phụ thuộc vào chiều rộng sản phẩm và quy mô đội ngũ hơn là lượng traffic. Nếu Anh Chị đang chạy song song từ hai sản phẩm số trở lên dưới cùng một thương hiệu, hoặc một sản phẩm có trên 40 màn hình độc lập với đội từ năm người kỹ thuật trở lên, đó là lúc nên cân nhắc nghiêm túc.

Nhiều chủ doanh nghiệp hỏi Sinh Vũ câu này theo hướng: "Tôi cần bao nhiêu người dùng thì mới nên làm design system?" Câu hỏi đó đặt sai trục đo. Số người dùng cuối nói lên mức độ phổ biến của sản phẩm, không nói lên độ phức tạp của hệ thống giao diện bên trong. Một ứng dụng tiêu dùng có một triệu người dùng nhưng chỉ năm màn hình có thể không cần design system trong vài năm tới. Một phần mềm B2B (dành cho doanh nghiệp) chỉ có 500 khách hàng nhưng tám module lớn, ba loại portal khác nhau, và đội ngũ mười lăm người có thể cần ngay hôm nay.

Tiêu chí thực sự quyết định

Design system sinh lợi từ tính kinh tế nhờ quy mô (economies of scale): một component xây một lần, dùng cho nhiều màn hình. Chi phí xây cố định, lợi ích tăng theo số lần tái sử dụng. Vì vậy ngưỡng hoàn vốn phụ thuộc vào chiều rộng sản phẩm, không phải lượng traffic.

Sinh Vũ dùng sáu câu hỏi để đánh giá mức độ sẵn sàng:

Đang chạy bao nhiêu sản phẩm số song song dưới cùng một thương hiệu (web app, mobile app, portal nội bộ)?
Một sản phẩm có bao nhiêu màn hình hoặc luồng (flow) độc lập?
Tốc độ ra tính năng mới mỗi sprint hiện tại là bao nhiêu?
Có bao nhiêu designer và developer đang làm việc cùng lúc trên cùng một codebase?
Mỗi sprint mất bao nhiêu giờ để hỏi lại và làm lại các quyết định thiết kế cũ?
Roadmap 18 tháng có thêm sản phẩm mới hoặc nền tảng mới không?

Khi nào nên đầu tư, khi nào chưa

Nên xem xét nghiêm túc nếu Anh Chị có từ hai sản phẩm số trở lên chạy song song và chia sẻ thương hiệu, hoặc một sản phẩm có trên 40 đến 60 màn hình độc lập với đội từ năm người kỹ thuật trở lên, hoặc sản phẩm có yêu cầu tuân thủ WCAG (tiêu chuẩn tiếp cận giao diện) và cần kiểm toán UI định kỳ.

Chưa nên nếu chỉ có một sản phẩm đơn lẻ với dưới năm người làm kỹ thuật, hoặc sản phẩm còn trong giai đoạn MVP (phiên bản tối giản để kiểm chứng thị trường) và màn hình thay đổi hàng tuần. Chi phí duy trì design system lúc này sẽ vượt lợi ích.

Lỗi thường gặp khi đánh giá

Lỗi phổ biến nhất là dùng số người dùng cuối làm tiêu chí duy nhất. Một triệu người dùng cũng có thể không cần design system nếu sản phẩm chỉ có năm màn hình và đội ngũ không tăng trưởng.

Lỗi thứ hai là bỏ qua chi phí ẩn. Mỗi sprint mất bao nhiêu giờ để trả lời lại câu hỏi thiết kế đã từng giải quyết, để căn chỉnh lại màu sắc, để giải thích cho developer cách dùng đúng component? Những giờ này không xuất hiện trong ngân sách, nhưng tích lũy thành khoản lớn theo thời gian.

Lỗi thứ ba là đánh giá bằng trực giác thay vì đo lường. Cách thực tế nhất để biết đã đến lúc chưa là đếm số lần cùng một component bị tạo lại trong ba sprint gần nhất. Nếu nút chính (primary button) xuất hiện dưới năm tên biến khác nhau trong codebase, chi phí ẩn đã đủ lớn.

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

Trong thực hành tư vấn, Sinh Vũ không dùng ngưỡng người dùng để phân loại khách hàng phù hợp. Thay vào đó, Sinh Vũ nhìn vào loại hình doanh nghiệp và cấu trúc sản phẩm: SaaS B2B (phần mềm dịch vụ dành cho doanh nghiệp) sau vòng gọi vốn Series A, tập đoàn đa sản phẩm, hoặc fintech (công nghệ tài chính) có yêu cầu tuân thủ cao là những trường hợp design system hoàn vốn rõ ràng nhất, không phải vì họ có nhiều người dùng, mà vì chiều rộng sản phẩm và quy mô đội ngũ của họ làm cho bài toán tái sử dụng trở nên kinh tế.

Design system chỉ hợp lý khi công việc nó giải quyết, tức là nhất quán và tốc độ, xuất hiện trong vòng lặp làm việc hàng ngày, không phải chỉ trên lộ trình chiến lược.
Ứng dụng từ khung Jobs To Be Done, Clayton Christensen

Nathan Curtis từ EightShapes đo sức khỏe design system qua hai chiều: bao nhiêu đội dùng nó (consumption model) và bao nhiêu đội đóng góp lại (contribution model). Nếu chỉ một đội dùng và không ai đóng góp, design system chưa có đủ lý do tồn tại độc lập mà nên được tích hợp thẳng vào quy trình của đội đó. Đây là lý do quy mô đội ngũ và số sản phẩm quan trọng hơn số người dùng cuối.

Nguồn tham khảo

Nathan Curtis, EightShapes: Design System ROI và contribution/consumption model. Clayton Christensen: Jobs To Be Done framework. Sinh Vũ Studio service data A3, phần Suitable for.

Câu hỏi thường gặp

Startup của tôi có 200.000 người dùng, vậy đã đủ để làm design system chưa?

Số người dùng không phải tiêu chí. Câu hỏi cần hỏi là sản phẩm có bao nhiêu màn hình độc lập và đội ngũ có bao nhiêu người đang làm song song. Nếu chỉ có một sản phẩm với dưới mười màn hình và đội dưới năm người, đầu tư vào design system lúc này thường chưa hoàn vốn.

Sản phẩm B2B của tôi chỉ có 500 khách hàng doanh nghiệp, có cần design system không?

Có thể cần, nếu sản phẩm đó có nhiều module lớn hoặc Anh Chị đang xây thêm portal nội bộ, app mobile, hoặc tích hợp trắng nhãn (white-label) cho từng khách hàng. Chiều rộng sản phẩm và yêu cầu nhất quán giao diện mới là thước đo, không phải đầu khách hàng.

Làm thế nào để biết đã đến lúc cần design system mà không cần thuê tư vấn?

Cách thực tế nhất là đếm số lần component bị tạo lại trong ba sprint gần nhất. Nếu cùng một nút, cùng một thẻ thông tin, hay cùng một biểu mẫu xuất hiện trong codebase với nhiều phiên bản khác nhau mà không có lý do, chi phí ẩn đã đủ lớn để bắt đầu thảo luận nghiêm túc.