Làm design system: sớm hay chờ sản phẩm ổn định?

Quyết định này không phải về việc design system có giá trị hay không. Design system có giá trị rõ ràng. Câu hỏi đúng là: làm ở thời điểm nào thì công sức bỏ ra không bị đổ đi khi sản phẩm thay đổi hướng. Sinh Vũ sẽ đi thẳng vào logic đó.

Tại sao làm sớm lại rủi ro hơn bạn nghĩ

Design system là một trong những lớp trừu tượng (abstraction) lớn nhất của giao diện. Nguyên tắc YAGNI (You Aren't Gonna Need It, tạm dịch: đừng xây thứ chưa cần) trong Extreme Programming nói rõ: không xây abstraction trước khi có nhu cầu cụ thể xảy ra ít nhất hai lần. Áp dụng vào đây: nếu Anh/Chị chưa thấy cùng một mẫu giao diện lặp lại nhiều lần trong thực tế, chưa biết mình đang chuẩn hóa cái gì.

Lean Startup của Eric Ries cũng khuyến khích trì hoãn đầu tư vào cơ sở hạ tầng cho đến khi học được điều gì đó từ người dùng thực. Xây design system trước khi có bài học đó là đầu tư vào cấu trúc dựa trên giả định, không phải dựa trên thực tế.

Hậu quả thực tế: khi sản phẩm pivot (chuyển hướng), cả hệ thống component phải viết lại. Chi phí refactor lúc đó cao hơn nhiều so với việc chưa có design system ngay từ đầu.

Ngưỡng hợp lý để bắt đầu

Không phải "chờ đến khi xong xuôi", mà là chờ đến khi đủ tín hiệu. Ba tín hiệu Sinh Vũ dùng để đánh giá:

• Sản phẩm đã có người dùng thực và có dấu hiệu giữ chân người dùng (retention dương).
• UX cốt lõi, tức là luồng chính người dùng đi qua mỗi ngày, không có thay đổi cấu trúc lớn trong ít nhất hai đến ba sprint liên tiếp.
• Đội ngũ bắt đầu nhận ra các mẫu lặp lại: cùng một loại nút, cùng một kiểu form, cùng một cách hiển thị trạng thái lỗi ở nhiều màn hình khác nhau.

Ba tín hiệu này có thể đến sớm hoặc muộn tùy sản phẩm. Điều Anh/Chị cần tránh là nhầm "có nhiều tính năng" với "UX đã ổn định". Sản phẩm nhiều màn hình không đồng nghĩa với UX pattern đã chín.

Khi nào nên làm sớm hơn ngưỡng thông thường

Lỗi thường gặp khi quyết định thời điểm

• Làm trong giai đoạn MVP: sản phẩm chưa tìm được hướng đi, mọi component có thể phải viết lại sau vài tháng.
• Chờ quá lâu đến khi nợ kỹ thuật quá lớn: refactor lúc này kéo dài nhiều sprint, gián đoạn việc giao hàng (delivery).
• Không có milestone rõ ràng: không xác định được "ổn định là như thế nào", dẫn đến chờ mãi không bắt đầu.
• Muốn làm toàn bộ ngay từ đầu: 80 đến 120 component là đích xa. Bắt đầu bằng phần nhỏ rồi mở rộng dần hợp lý hơn nhiều.

Chi phí nợ thiết kế tăng theo thời gian. Nếu đã có quá nhiều inconsistency và đang gây ra friction (ma sát) cho người dùng, chờ thêm sẽ đắt hơn là làm ngay.

Ward Cunningham, khái niệm Technical Debt, áp dụng tương tự với Design Debt

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

Với khách hàng đến gặp Sinh Vũ trước khi có người dùng thực, lời khuyên nhất quán là: tập trung vào MVP trước, design system sau. Đây là lời khuyên bảo vệ ngân sách và công sức của Anh/Chị, không phải vì design system không quan trọng.

Khi Anh/Chị đã vượt ngưỡng và sẵn sàng bắt đầu, Sinh Vũ thường đề xuất lộ trình từ nhỏ đến lớn: xây phần token trước, tức là hệ thống màu sắc, kiểu chữ, khoảng cách. Chi phí thấp, dễ điều chỉnh, và ngay lập tức tạo ra sự nhất quán có thể thấy được. Component library đầy đủ đến sau, khi đội ngũ và sản phẩm đã đủ chín để biết cần gì.

Milestone cụ thể Anh/Chị nên tự đặt: "Nếu sau sprint tiếp theo UX luồng chính vẫn không thay đổi cấu trúc, chúng tôi bắt đầu làm token." Có mốc rõ thì không chờ mãi, cũng không làm vội.

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

Sản phẩm đang có người dùng nhưng giao diện vẫn hay thay đổi, có nên làm design system chưa?

Chưa nên. Sự thay đổi thường xuyên là dấu hiệu UX chưa ổn định. Nếu làm ngay, mỗi lần đổi hướng sẽ kéo theo refactor cả hệ thống component. Hãy đợi ít nhất hai đến ba sprint liên tiếp không có thay đổi cấu trúc lớn trước khi đầu tư.

Có thể bắt đầu làm một phần design system thay vì làm toàn bộ không?

Được, và đây thường là lộ trình Sinh Vũ khuyến nghị. Bắt đầu bằng phần token (màu sắc, kiểu chữ, khoảng cách) có chi phí thấp và dễ điều chỉnh sau. Chưa cần xây đủ 80 đến 120 component ngay từ đầu, vì phần lớn component chỉ lộ ra nhu cầu thực khi sản phẩm scale.

Nếu sắp tuyển thêm designer hoặc developer, có nên làm design system trước không?

Đây là một trong những lý do hợp lệ để làm sớm hơn ngưỡng thông thường. Người mới cần tài liệu chuẩn để làm việc nhất quán ngay từ ngày đầu. Tuy nhiên nên ưu tiên làm phần hướng dẫn và token trước, component library sau khi đội đã quen với sản phẩm.