Khi nào doanh nghiệp thực sự cần hệ thiết kế số

Hệ thiết kế số không phải thứ Anh/Chị cần chỉ vì đối thủ đang làm, hoặc vì nghe hay. Đây là hạ tầng kỹ thuật, giống như hệ thống CI/CD (quy trình tự động hóa kiểm thử và triển khai phần mềm) hay cơ sở dữ liệu tập trung. Đầu tư đúng thời điểm thì tiết kiệm hàng trăm giờ công. Đầu tư sai thì tạo ra một thư viện không ai ngó tới, lỗi thời sau sáu đến mười hai tháng.

Design system là gì, hiểu cho đúng

Hệ thiết kế số là tập hợp gồm ba tầng: các thành phần giao diện có thể tái dùng (component library), bộ quy tắc giá trị thiết kế như màu sắc, khoảng cách, kiểu chữ được lưu dưới dạng biến (design token, theo chuẩn W3C Design Token Community Group), và tài liệu hướng dẫn cách sử dụng. Cả ba tầng này phải hoạt động đồng bộ giữa file thiết kế và mã nguồn thực tế.

Điều này khác hoàn toàn với brand guideline (bộ hướng dẫn thương hiệu). Brand guideline phục vụ người làm truyền thông, quy định logo, màu, font ở định dạng tĩnh. Design system phục vụ đội kỹ thuật, quy định cách thành phần giao diện hoạt động và được lập trình. Nhầm hai khái niệm này là lỗi Sinh Vũ gặp thường xuyên nhất ở giai đoạn tư vấn.

Ba điều kiện để đầu tư có lý

Nielsen Norman Group mô tả design system như một sản phẩm phục vụ sản phẩm. Nghĩa là nó cần owner (người chịu trách nhiệm), roadmap (lộ trình phát triển) và người dùng nội bộ thực sự, giống như bất kỳ sản phẩm nào khác. Từ đó, ba câu hỏi để Anh/Chị tự kiểm tra:

• Đủ quy mô chưa? Ngưỡng thực tế: ít nhất hai designer và ba đến năm frontend developer cùng làm việc trên một codebase. Dưới ngưỡng đó, hệ thống chưa được tái dùng đủ nhiều lần để hoàn vốn.
• Đủ phức tạp chưa? Ít nhất hai sản phẩm số chạy song song, ví dụ web app và mobile app, hoặc portal khách hàng và portal nội bộ. Một sản phẩm đơn lẻ chưa đủ bề mặt để tái dùng.
• Có người duy trì không? Phải có ít nhất một người có thẩm quyền và thời gian để bảo trì hệ thống liên tục. Không có người này, hệ thống sẽ lỗi thời nhanh hơn Anh/Chị nghĩ.

Khi nào nên làm, khi nào chưa nên

Atomic Design cung cấp ngôn ngữ chung giữa designer và developer: atoms (nguyên tử, thành phần nhỏ nhất như button, input), molecules (phân tử, nhóm thành phần cùng chức năng), organisms (cơ thể, khối giao diện hoàn chỉnh), templates và pages. Khung tư duy này giúp đội ngũ nói chuyện cùng một ngôn ngữ thay vì mỗi người tự diễn giải.

Brad Frost, Atomic Design (2013)

Lỗi thường gặp khi triển khai

• Chỉ có Figma library, không có mã nguồn tương ứng: Designer dùng được, nhưng developer vẫn tự code theo cách riêng. Kết quả là hai hệ thống chạy song song, mâu thuẫn nhau ngay từ đầu.
• Xây đủ component nhưng không có ai maintain: Thư viện lỗi thời nhanh chóng khi sản phẩm ra tính năng mới mà không cập nhật hệ thống. Đây là nguyên nhân phổ biến nhất khiến design system bị bỏ rơi.
• Xây quá sớm khi UX chưa ổn định: Nếu luồng người dùng vẫn đang thay đổi hàng tuần, mọi component xây ra hôm nay đều có nguy cơ phải làm lại.
• Nhầm design system với bộ nhận diện thương hiệu: Hai thứ phục vụ đối tượng khác nhau, không thể thay thế nhau, và đầu tư vào cái này không đồng nghĩa với có cái kia.

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

Sinh Vũ xác định ba nhóm khách hàng phù hợp nhất để đầu tư vào design system: SaaS B2B (phần mềm dịch vụ bán cho doanh nghiệp) sau vòng gọi vốn Series A trở đi, tập đoàn vận hành nhiều sản phẩm số song song, và doanh nghiệp fintech có yêu cầu tuân thủ WCAG hoặc audit nội bộ về giao diện.

Ngược lại, ba trường hợp Sinh Vũ khuyến nghị chưa đầu tư: website thuần giới thiệu không có tính năng tương tác phức tạp, đội kỹ thuật dưới ba người, và sản phẩm chưa có người dùng thực. Đây không phải vấn đề năng lực, mà là vấn đề hoàn vốn. Đầu tư đúng chỗ, đúng lúc mới tạo ra giá trị thực.