Phần mềm SaaS: khi nào phải nâng lên hệ thiết kế

Quy chuẩn và hệ thiết kế (design system) không phải hai tên cho cùng một thứ. Nhầm lẫn theo hướng nào cũng tốn tiền: làm hệ thiết kế đồ sộ quá sớm thì dựng xong đã lỗi thời, giữ mãi ở quy chuẩn PDF khi đội đã đông thì mỗi người tự dựng một kiểu rồi sản phẩm mất nhất quán. Sinh Vũ viết trang này để Anh/Chị xác định đúng cấp độ cho giai đoạn mình đang ở.

Hai khái niệm khác nhau cần phân biệt trước

Quy chuẩn thương hiệu (brand guidelines) trả lời câu hỏi: sản phẩm của Anh/Chị trông thế nào? Màu chủ đạo, bộ chữ, logo, nguyên tắc ảnh, giọng điệu viết lách. Đây là tầng nhận diện, áp dụng cho mọi điểm chạm từ website đến tài liệu bán hàng.

Hệ thiết kế (design system) trả lời câu hỏi khác: nhiều đội dựng giao diện nhất quán ra sao ở quy mô, qua mọi trang và mọi kích thước màn hình, mà không bắt đầu lại từ đầu mỗi lần? Hệ thiết kế gồm token (giá trị thiết kế dạng biến số, ví dụ màu, khoảng cách, cỡ chữ), thư viện thành phần tái sử dụng, hướng dẫn lập trình và quy trình đồng bộ liên đội.

Mọi sản phẩm phần mềm đều cần quy chuẩn. Không phải mọi đội đều cần hệ thiết kế đầy đủ ngay từ đầu.

Các yếu tố cần cân nhắc trước khi nâng cấp

• Số người cùng chạm vào giao diện. Một đến hai nhà thiết kế thì quy chuẩn kèm thư viện Figma cơ bản là đủ kiểm soát. Khi số này lớn hơn và thêm cả lập trình viên tự dựng thành phần, thư viện đơn lẻ không còn giữ được nhất quán.
• Mức ổn định của giao diện. Sản phẩm chưa tìm được product-market fit (sự khớp giữa sản phẩm và nhu cầu thị trường) thì hệ thiết kế sẽ luôn lệch bản vì giao diện đổi liên tục. Dựng khi giao diện đã bắt đầu chốt, không phải trước.
• Chi phí dựng lại. Khi mỗi đội tự tạo nút bấm, biểu mẫu, thông báo lỗi theo cách riêng, chi phí dựng lại tích luỹ theo từng sprint (chu kỳ phát triển). Thư viện thành phần chung cắt chi phí này.
• Có đội duy trì về sau không. Hệ thiết kế cần người vận hành: cập nhật token khi thương hiệu thay đổi, thêm thành phần mới, đồng bộ giữa file Figma và code. Không có người giữ thì hệ thiết kế sẽ thành tài liệu tĩnh bị bỏ qua.
• Có đối tác hoặc lập trình viên bên thứ ba không. Khi cần mở API (giao diện lập trình ứng dụng) hoặc module cho đối tác tích hợp, một cổng công khai với thành phần đúng chuẩn giúp bên ngoài dựng đúng ngay từ đầu thay vì phải sửa lại.

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

Dựng hệ thiết kế khi giao diện bắt đầu ổn định, không phải trước. Sản phẩm chưa tìm được product-market fit thì hệ thiết kế sẽ luôn lệch bản.

UserQ, Design systems vs brand guidelines

Lỗi thường gặp

• Startup dựng hệ thiết kế đồ sộ quá sớm. Giao diện đổi mỗi tháng thì hệ thiết kế lỗi thời trước khi đội kịp dùng. Kết quả: mất thời gian dựng, mất thêm thời gian bỏ đi.
• Đội đông vẫn chỉ dùng PDF. Mỗi nhà thiết kế tự dịch quy chuẩn theo cách hiểu của mình. Sau vài tháng giao diện trôi khỏi chuẩn, không ai nhận ra vì mỗi phần có vẻ đúng khi nhìn riêng lẻ.
• Coi thư viện token là đã đủ. Token giải quyết giá trị số (màu, khoảng cách), nhưng không thay được phần quy trình: ai quyết thêm thành phần mới, ai duyệt thay đổi, đội kỹ thuật đồng bộ code ra sao. Thiếu quy trình thì thư viện sẽ phân nhánh theo từng đội.

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

Sinh Vũ đã làm việc với công ty phần mềm B2B, giao thư viện Figma hơn tám mươi thành phần để nhiều nhà thiết kế áp nhất quán. Bài học từ đó: cấp độ đúng phụ thuộc vào cách đội khách vận hành thực tế, không phải vào tham vọng dài hạn.

Sinh Vũ chốt cấp theo nguyên tắc này: đội đông và sản phẩm ổn định thì mở lên thư viện đầy đủ với token và thành phần có thể tái sử dụng. Đội nhỏ hoặc còn xoay trục thì làm bản gọn trước, tránh dựng hệ thống mà chính đội chưa sẵn sàng vận hành.

Ranh giới bàn giao cũng rõ: Sinh Vũ dựng luật thương hiệu, thư viện thành phần và bàn giao file nguồn Figma. Vận hành pipeline token (chuỗi chuyển đổi giá trị thiết kế thành code) và tích hợp vào codebase là phần của đội kỹ thuật bên Anh/Chị. Hai phần này cần phối hợp từ đầu, không phải chờ đến lúc bàn giao mới nói chuyện.