SaaS B2B cần token và thư viện thành phần tới mức nào

Câu hỏi này thường xuất hiện sau khi sản phẩm đã có người dùng thật, đội kỹ thuật bắt đầu lớn, và ai đó nhận ra giao diện đang lệch nhau giữa các màn hình. Lúc đó, một số người muốn dựng ngay một thư viện thành phần (component library: tập hợp các thành phần giao diện dùng chung) đồ sộ. Sinh Vũ thường khuyên ngược lại: dựng đúng thứ đúng lúc, không phải dựng nhiều nhất có thể.

Token trước, thành phần sau

Design token (mã định danh thiết kế: các giá trị như màu sắc, cỡ chữ, khoảng cách được đặt tên và lưu trữ có cấu trúc) là nền móng. Không có nền, thư viện thành phần chỉ là tập hình ảnh được code lại mà thôi.

Điểm mấu chốt nằm ở cách đặt tên. Nếu đặt tên token theo hình thức như blue-500, thì khi thương hiệu đổi màu chủ đạo, Anh/Chị phải đổi tay từng chỗ. Nếu đặt tên theo mục đích như color-primary, color-surface-default, thì chỉ cần thay giá trị ở một chỗ, toàn bộ hệ thống cập nhật theo. Đây gọi là semantic token, tức token ngữ nghĩa. Sinh Vũ luôn dựng lớp này trước khi đặt bút vẽ thành phần đầu tiên.

Đặt tên token theo mục đích, không phải theo hình thức. Đó là thứ khiến hệ thống bảo trì được sau ba năm.

Nguyên tắc thực hành, Sinh Vũ Studio

Khi nào cần thư viện thành phần đầy đủ

Không phải lúc nào cũng cần. Đây là ba ngưỡng thực tế để cân nhắc:

• Từ ba bề mặt (surface: điểm tiếp xúc giao diện như web app, trang marketing, mobile, email) trở lên cần giữ đồng bộ cùng lúc.
• Đội kỹ thuật đang lớn, tức có nhiều designer và kỹ sư làm việc độc lập trên cùng sản phẩm.
• Có nhiều thương hiệu hoặc nhiều bộ giao diện (theme) cần phục vụ, ví dụ sản phẩm white-label hoặc nhiều gói dịch vụ có diện mạo khác nhau.

Dưới các ngưỡng này, chi phí dựng và bảo trì thư viện thường chưa kịp hoàn lại trước khi sản phẩm pivot (thay đổi hướng đi). Giai đoạn đang dò tìm điểm khớp thị trường (product-market fit: thời điểm sản phẩm khớp đúng nhu cầu thị trường) mà dựng thư viện đồ sộ là đầu tư sai nhịp.

Khi nào chọn hướng nào

Lỗi thường gặp khi dựng hệ thống

• Dựng thư viện thành phần đồ sộ quá sớm rồi phải bỏ khi sản phẩm đổi hướng.
• Đặt tên token theo màu sắc thay vì mục đích, khiến việc đổi thương hiệu sau này là phải làm lại từ đầu.
• Nhầm Figma UI kit là design system. UI kit là hình ảnh. Design system là luật dùng kèm lớp token kèm tài liệu. Thiếu hai thứ sau, đội kỹ thuật sẽ dịch tự do và kết quả lệch dần.
• Dựng xong không cắt cử ai sở hữu hệ. Đây là lỗi phổ biến nhất và gây thiệt hại nhiều nhất. Hệ không có người sở hữu sẽ trôi dần khỏi thực tế mã nguồn trong vòng sáu đến mười hai tháng.

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

Trong gói O2, thư viện mẫu và lớp token là một trong năm hạng mục bàn giao, cùng với Cổng tài sản thương hiệu, Sổ tay quản trị, quy trình tự động hóa và vận hành liên tục. Sinh Vũ chọn mức đầu tư theo ba cấp Lite, Full hoặc Enterprise tùy quy mô đội và số bề mặt, không có công thức một cỡ cho tất cả.

Điều Sinh Vũ luôn hỏi trước khi đề xuất quy mô: ai sẽ sở hữu hệ này sau khi Sinh Vũ bàn giao? Nếu câu trả lời là không rõ, thì dù dựng ở mức nào cũng cần giải quyết câu hỏi đó trước. Hệ thống thiết kế không phải sản phẩm giao một lần rồi thôi, đó là hạ tầng sống và cần người vận hành.

Sinh Vũ không cam kết chỉ số hoàn vốn cụ thể vì phần lớn phụ thuộc cách đội khách vận hành hệ sau khi nhận bàn giao. Điều có thể cam kết là: nếu dựng đúng thứ đúng lúc và có người sở hữu rõ ràng, chi phí sản xuất nội dung và thời gian onboard thành viên mới sẽ giảm thấy rõ theo thời gian.