Phủ bao nhiêu nền tảng là vừa

Câu hỏi này thường xuất hiện khi Anh / Chị bắt đầu xây dựng hệ thống thiết kế (design system) 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 hệ thống thiết kế:

• 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, mọi nền tảng đều dùng chung được.
• 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

Nên phủ cả iOS và Android khi thoả 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 thực tế, 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 thường không tốn nhiều hơn làm token thiếu suy nghĩ, nhưng tiết kiệm nhiều công sau này khi mở rộng. Hai câu hỏi đáng trả lời 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 hệ thống thiết kế?

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.

Bài viết là thông tin tham khảo. Phạm vi, giá và cam kết cụ thể của Sinh Vũ ghi trong hồ sơ đề xuất và hợp đồng đã ký.