Design system: chỉ web hay cần cả iOS và Android?

Chốt nhanh

Token thiết kế (design token) có thể dùng chung giữa web và native mobile, nhưng code component thì không thể, vì mỗi nền tảng có runtime riêng biệt. Nếu Anh Chị chưa có kế hoạch ra native app trong vòng hai năm, hãy tập trung xây tốt cho web trước, tránh dàn trải. Nếu đã có cả web lẫn native, hướng hợp lý nhất là xây token đa nền tảng trước, rồi mới xây component riêng cho từng nền tảng theo thứ tự ưu tiên doanh thu.

Khi bắt đầu xây design system (hệ thống thiết kế), câu hỏi về phạm vi nền tảng thường xuất hiện sớm: làm cho web là đủ, hay cần phủ luôn iOS và Android? Câu trả lời ngắn là: token (đơn vị giá trị thiết kế như màu, khoảng cách, kiểu chữ) có thể dùng chung, nhưng component (thành phần giao diện như nút, form, thanh điều hướng) thì không. Sự phân biệt này quyết định toàn bộ cách Anh Chị nên lên kế hoạch ngân sách và đội ngũ.

Token và component: hai lớp khác nhau

Design token theo chuẩn DTCG (Design Token Community Group, tổ chức chuẩn hóa định dạng token) là một tập giá trị trung gian, ví dụ màu chủ đạo là #1A56DB, khoảng cách cơ sở là 8px. Công cụ như Style Dictionary có thể chuyển đổi (transform) tập token này thành CSS cho web, Swift UIKit cho iOS, và Android XML cho Android từ cùng một nguồn duy nhất. Đây là lớp duy nhất có thể chia sẻ đáng tin cậy giữa các nền tảng.

Component thì khác. Web dùng React hoặc Vue Component, iOS dùng SwiftUI hoặc UIKit, Android dùng Jetpack Compose. Ba runtime (môi trường thực thi) này không tương thích nhau. Nghĩa là nếu Anh Chị muốn có nút bấm nhất quán trên cả ba nền tảng, đội kỹ thuật phải viết lại component đó ba lần bằng ba ngôn ngữ khác nhau, dù cùng dùng chung một bộ token màu và khoảng cách.

Khi nào chỉ cần web

Nếu Anh Chị chưa có kế hoạch ra ứng dụng native trong vòng hai năm, không có lý do kỹ thuật nào buộc phải xây cho iOS và Android ngay bây giờ. Overengineering (xây vượt nhu cầu thực tế) ở giai đoạn này sẽ tiêu tốn thời gian và ngân sách mà không tạo ra giá trị tương ứng.

Scope web bao gồm: thư viện component React hoặc Vue, tài liệu trên Storybook, và bộ token xuất ra CSS hoặc CSS custom properties. Đây là phạm vi vừa đủ để đội thiết kế và kỹ thuật làm việc nhất quán mà không kéo căng nguồn lực.

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

Có web và native nhưng ngân sách giới hạn: xây token đa nền tảng trước, component chỉ làm web. Đội native dùng token từ cùng nguồn để đảm bảo màu sắc và khoảng cách nhất quán, còn component thì họ tự xây theo convention của nền tảng.

Native app là core business (ví dụ ứng dụng ngân hàng, ví điện tử): cần team native riêng với kỹ sư chuyên biệt, không thể ghép vào dự án web. Đây là quyết định về tổ chức đội ngũ, không chỉ là quyết định kỹ thuật.

iOS và Android cũng có quy ước tương tác riêng: Human Interface Guidelines (hướng dẫn thiết kế giao diện của Apple) và Material Design 3 (hệ thống thiết kế của Google). Một hệ thống tốt tôn trọng convention của từng nền tảng, không ép tất cả dùng cùng một mẫu UI như trên web.

Lỗi thường gặp

Ép ứng dụng native dùng đúng UI pattern của web. Kết quả là giao diện trông không quen tay với người dùng iOS hoặc Android, gây cảm giác khó chịu dù về mặt thị giác vẫn nhất quán.
Xây design system cho cả ba nền tảng cùng lúc với đội ngũ nhỏ. Kết quả thường là không nền tảng nào được làm tốt, cả ba đều ở mức tạm.
Không tính đến dark mode ở cấp hệ điều hành. iOS và Android có dark mode tự động theo cài đặt thiết bị, token web thông thường không xử lý được điều này nếu không được thiết kế trước.
Chỉ có Storybook làm tài liệu, trong khi đội native không có nguồn tham chiếu tương đương. Kỹ sư iOS và Android sẽ phải đoán, và kết quả sẽ lệch.

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

Phạm vi mặc định của Sinh Vũ trong dịch vụ A3 là web, với thư viện Figma phủ cả thiết kế màn hình mobile (responsive web, không phải native app). Nếu Anh Chị cần token transform cho iOS và Android, Sinh Vũ có thể xây pipeline chuyển đổi từ bộ token gốc sang định dạng native. Tuy nhiên, component code native nằm ngoài scope chuẩn và cần thảo luận riêng về ngân sách cùng đội kỹ thuật phía Anh Chị.

Token là lớp duy nhất có thể chia sẻ đáng tin cậy giữa web và native. Đừng cố share component logic giữa React web và React Native nếu UX yêu cầu cảm giác native thực sự.
Quan điểm ngành, kinh nghiệm từ các đội design system lớn như Airbnb, Uber

Nguyên tắc thực hành: bắt đầu từ nền tảng có nhiều người dùng nhất hoặc doanh thu cao nhất, ổn định hệ thống ở đó trước, rồi mới mở rộng. Đây không phải là sự thỏa hiệp mà là thứ tự hợp lý.

Nguồn tham khảo

Apple Human Interface Guidelines; Google Material Design 3; Style Dictionary platform transform documentation; quan điểm thực hành từ cộng đồng Design Systems Slack; kinh nghiệm vận hành dự án A3 của Sinh Vũ Studio.

Câu hỏi thường gặp

Token thiết kế dùng chung được thì còn cần làm gì thêm cho native?

Token đảm bảo màu sắc, khoảng cách, và kiểu chữ nhất quán giữa các nền tảng. Tuy nhiên, component (nút, form, navigation) phải viết lại bằng Swift hoặc Jetpack Compose cho native, không thể lấy từ thư viện React hay Vue sang. Ngoài ra, cần tính đến dark mode ở cấp hệ điều hành, vì iOS và Android xử lý dark mode khác với web.

React Native có giải quyết được vấn đề này không?

React Native cho phép dùng chung một phần code component giữa web và mobile, nhưng không hoàn toàn. Những tương tác cần cảm giác native thực sự như gesture, navigation pattern, hoặc animation vẫn cần điều chỉnh riêng cho từng nền tảng. React Native phù hợp khi đội ngũ nhỏ và yêu cầu UX không quá cao về cảm giác native.

Storybook có dùng được cho tài liệu native không?

Storybook chủ yếu phục vụ web. Đội native cần giải pháp tài liệu riêng, ví dụ Zeroheight hoặc trang tài liệu viết tay kết hợp với Figma annotation. Nếu Anh Chị chỉ dùng Storybook mà không có tài liệu native, kỹ sư iOS và Android sẽ không có nguồn tham chiếu đáng tin cậy.