Dùng nền có sẵn hay làm riêng từ gốc

Trước khi bàn kỹ thuật, cần trả lời một câu hỏi nền: thương hiệu của Anh / Chị cần khác biệt đến mức nào so với những gì người dùng đã thấy ở các sản phẩm khác? Câu trả lời đó quyết định phần lớn hướng đi cho design system (hệ thống thiết kế).

Hai hướng và điểm khác biệt thật sự

Hệ nền mở như Material Design của Google hay Carbon của IBM không phải là bộ giao diện đẹp để sao chép. Đó là hệ thống đã giải sẵn hàng trăm vấn đề nền: điều hướng bàn phím, tiêu chuẩn WCAG (bộ hướng dẫn khả năng tiếp cận cho người khuyết tật), hành vi biểu mẫu trên di động, trạng thái tải dữ liệu. Dựng lại những thứ này từ số không tốn rất nhiều thời gian và dễ thiếu sót.

Làm riêng hoàn toàn từ gốc có lý do chính đáng khi sản phẩm đòi hỏi trải nghiệm thật sự khác biệt mà không một hệ nền nào cung cấp sẵn, hoặc khi thương hiệu tiêu dùng cần bản sắc thị giác sâu đến mức mọi thứ mượn từ ngoài đều trở thành rào cản.

Lớp token là chìa khóa của hướng lai

Token thiết kế (design token) theo chuẩn DTCG của W3C là các đơn vị giá trị nhỏ nhất trong hệ thống: màu sắc, kiểu chữ, khoảng cách, hình dạng góc bo. Khi Anh / Chị can thiệp ở lớp token thay vì đè vào cấu trúc bên trong component, kết quả đạt được cả hai thứ: cấu trúc và hành vi từ hệ nền mở, lớp nhìn thấy thuần nhận diện của riêng mình.

Đây là hướng Sinh Vũ thường đề xuất cho các doanh nghiệp ở giữa, tức không phải sản phẩm nội bộ đơn giản nhưng cũng không cần bản sắc cực đoan đến mức hệ nền cản trở.

Token thiết kế trung lập theo chuẩn DTCG là lớp cho phép tách nhận diện khỏi nền kỹ thuật. Nhờ đó có thể mượn cấu trúc component của một hệ mở mà vẫn giữ màu, chữ, khoảng cách của riêng mình.

Design Tokens Community Group (DTCG), W3C

Các yếu tố quyết định hướng đi

• Mức khác biệt thương hiệu cần đạt: nếu nhận diện chỉ cần màu và font riêng, nền mở kham được. Nếu hình dạng, chuyển động, cách bố cục đều phải hoàn toàn riêng, nền mở sẽ thành gánh nặng hơn là hỗ trợ.
• Chi phí tùy biến thực tế: đè lên nền mở để đạt nhận diện riêng thường tốn nhiều công hơn người ta nghĩ, đặc biệt ở các component phức tạp như data table hay date picker.
• Mức phủ của hệ nền: Carbon mạnh về dữ liệu và bối cảnh doanh nghiệp. Material mạnh về trải nghiệm đa thiết bị. Nếu nhu cầu của Anh / Chị lệch khỏi vùng mạnh đó, hệ nền ít giúp được hơn.
• Năng lực đội duy trì về sau: hệ riêng đòi hỏi đội đủ lực nuôi lâu dài. Hệ nền mở có cộng đồng và tài liệu sẵn để tuyển dụng hoặc đào tạo thêm người.
• Rủi ro khóa vào nền gốc: nếu Google hay IBM thay đổi lớn trong hệ của họ, các phần Anh / Chị đã đè lên có thể xung đột và cần dọn lại.

Lỗi thường gặp cần tránh

• Lấy nền mở rồi đè quá nhiều ở tầng nông, kết quả vừa mất bản sắc vừa khó nâng cấp theo nền gốc khi họ ra bản mới.
• Dựng riêng từ số không rồi dành hàng năm xây lại những thứ nền mở đã giải xong, ví dụ điều hướng bàn phím, tiêu chuẩn tiếp cận, biểu mẫu di động.
• Tạo nhiều nhánh tách (fork) khỏi nền gốc để vá từng trường hợp riêng, đến lúc nền ra bản cập nhật thì không biết nên merge (hợp nhất) hay viết lại từ đầu.

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

Sinh Vũ không thờ một hệ nền cố định. Câu hỏi không phải "Material hay Carbon hay tự làm" mà là "lớp nào mượn được, lớp nào phải làm riêng". Với phần lớn khách, câu trả lời là: mượn kiến trúc và nguyên tắc tiếp cận, làm riêng toàn bộ lớp token và lớp thị giác.

Component được dựng theo đúng công nghệ đội khách đang dùng, có thể là React, Vue hoặc Web Components, không ép khách theo một stack (bộ công nghệ) lạ chỉ vì hệ nền đó yêu cầu. Mục tiêu cuối là Anh / Chị sở hữu một hệ thống đội nội bộ tự nuôi được, không phụ thuộc vào nhà cung cấp bên ngoài để vận hành từng bước nhỏ.