Phủ bao nhiêu nền tảng cho design system của Anh Chị

Câu hỏi này thường xuất hiện khi Anh Chị bắt đầu xây dựng design system (hệ thống thiết kế) và nhận ra rằng sản phẩm mình không chỉ có website. Câu trả lời không nằm ở kỹ thuật, nó nằm ở chỗ khách của Anh Chị đang dùng sản phẩm ở đâu và kênh nào đang thật sự tạo ra doanh thu.

Token và component: hai câu chuyện khác nhau

Trước khi quyết định, Anh Chị cần phân biệt rõ hai tầng trong design system:

• Token là các giá trị thiết kế nền tảng: màu sắc, khoảng cách, cỡ chữ, bóng đổ. Token không thuộc về nền tảng nào, nó là ngôn ngữ chung.
• Component là các khối giao diện hoàn chỉnh như nút bấm, thanh điều hướng, form nhập liệu. Component được xây dựng bằng công nghệ cụ thể và gắn với nền tảng cụ thể.

Việc phủ đa nền tảng ở tầng token là hoàn toàn khả thi. Một bộ token trung lập theo chuẩn DTCG có thể xuất ra CSS cho web, biến màu cho iOS, đơn vị dp và sp (đơn vị độ dài chuẩn trên Android) cho Android qua công cụ dựng như Style Dictionary mà không cần chép tay từng giá trị. Component thì không như vậy: mỗi nền tảng là một khối công việc riêng, xây theo đúng công nghệ mà nền tảng đó dùng.

Một nguồn token, nhiều đầu ra nền tảng qua bước dựng biến đổi, giữ nhất quán mà không chép tay từng nơi.

Style Dictionary, Amazon Web Services

Khi nào nên mở rộng sang iOS và Android

Sinh Vũ khuyên Anh Chị phủ cả iOS và Android khi thỏa mãn đồng thời các điều kiện sau:

• Phần lớn khách hàng thật sự dùng ứng dụng gốc, không phải truy cập qua trình duyệt di động.
• Ứng dụng là kênh doanh thu chính, không phải kênh phụ bổ trợ cho website.
• Đội kỹ thuật có đủ người để xây và bảo trì cả ba bộ component (web, iOS, Android) song song về lâu dài.

Lưu ý thêm: iOS và Android có ngôn ngữ nền riêng. Apple có HIG (Human Interface Guidelines, hướng dẫn giao diện của Apple), Android có Material Design. Đây là quy ước mà người dùng từng nền tảng đã quen, không nên bê nguyên giao diện web vào ứng dụng gốc mà bỏ qua các quy ước này.

Khi nào nên chỉ phủ web trước

Trong phần lớn trường hợp Sinh Vũ gặp, sản phẩm số chính vẫn là web hoặc web-app (ứng dụng chạy trên trình duyệt). Ứng dụng di động hoặc chưa có, hoặc có nhưng chưa phải kênh chính. Lúc đó việc phủ ngay cả iOS và Android là đầu tư vào chỗ chưa cần, trong khi nơi cần thì chưa được làm tốt.

Hướng hợp lý hơn: xây token chuẩn và trung lập ngay từ đầu, component web làm trước và làm đúng, component cho nền tảng khác dựng dần khi nhu cầu thật xuất hiện. Làm token tốt từ đầu tốn không nhiều hơn làm token thiếu suy nghĩ, nhưng tiết kiệm rất nhiều công sau này khi mở rộng.

Lỗi hay gặp khi quyết định phạm vi

• Kỳ vọng component web tái dùng nguyên si trên ứng dụng gốc iOS hoặc Android: điều này không xảy ra, đây là hai thứ khác nhau về công nghệ lẫn hành vi.
• Phủ nhiều nền tảng khi đội kỹ thuật chưa đủ người để nuôi lâu dài: kết quả là nền tảng ít dùng bị bỏ xó, token lệch dần, component không ai cập nhật.
• Bỏ bước biến đổi tự động, chép giá trị token bằng tay sang từng nền tảng: đây là nguồn gốc của sự lệch nhau giữa các nền tảng theo thời gian.
• Quyết định phủ đa nền tảng vì nghe chuyên nghiệp, không phải vì có nhu cầu thật từ người dùng và từ đội kỹ thuật.

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

Khi tư vấn và báo giá, Sinh Vũ phân ranh giới rõ ràng: token theo chuẩn DTCG trung lập có thể phủ được nhiều nền tảng, đây là việc nên làm đúng ngay từ đầu dù Anh Chị hiện chỉ có web. Component thì được xây theo đúng công nghệ Anh Chị thật sự dùng, không hứa một bộ chạy khắp nơi. Gói có component đa nền tảng lớn hơn gói một stack vì đó là khối công việc thật, không phải số nhân cơ học.

Câu hỏi Sinh Vũ thường hỏi khách trước khi chốt phạm vi: trong sáu tháng tới, sản phẩm nào sẽ được nhiều người dùng nhất, và đội kỹ thuật có bao nhiêu người dành thời gian thường xuyên cho design system? Câu trả lời đó quyết định phạm vi nền tảng hợp lý hơn bất kỳ lý do kỹ thuật nào.