Cẩm nang · Nối vào công nghệ và sản phẩm số

Nhiều nền tảng, một lõi nhận diện

Khi sản phẩm số chạy trên web, iOS và Android cùng lúc, câu hỏi không phải là 'trông giống nhau không' mà là 'lõi thương hiệu có còn nhận ra được không'.

Chốt nhanh

Cách bền nhất là lập một nguồn chung cho các yếu tố lõi: màu, chữ, giãn cách, rồi để mỗi nền tảng lấy về thay vì sửa tay từng nơi. Yếu tố lõi phải giống nhau xuyên nền tảng để người dùng nhận ra thương hiệu, còn điều hướng và thao tác thì nên tôn trọng thói quen riêng của từng hệ điều hành. Không có nguồn chung, các nền tảng sẽ trôi khỏi nhau theo thời gian dù không ai cố ý làm vậy.

Khi sản phẩm số mở rộng ra nhiều nền tảng, một vấn đề thầm lặng bắt đầu xảy ra: web dùng một bộ màu, iOS dùng bộ khác, Android lại khác nữa, không phải vì ai cố tình mà vì mỗi đội sửa tay ở chỗ của mình rồi không ai thông báo cho nhau. Sau một thời gian, khách hàng nhìn vào ba nền tảng và cảm giác đang đối diện với ba thương hiệu khác nhau.

Yếu tố nào phải giống hệt, yếu tố nào được khác

Đây là câu hỏi đầu tiên cần trả lời trước khi bàn đến công cụ hay quy trình. Không phải mọi thứ đều cần đồng nhất tuyệt đối và ép đồng nhất sai chỗ sẽ phá trải nghiệm người dùng.

  • Phải giữ nguyên xuyên nền tảng: màu thương hiệu, hệ chữ (typeface và thang cỡ chữ), logo và tỉ lệ vùng trống xung quanh logo. Đây là những thứ người dùng nhìn vào và nhận ra ngay đây là thương hiệu của Anh / Chị.
  • Nên theo thói quen nền tảng: điều hướng, vị trí các nút thao tác, cách hiển thị thông báo. Người dùng iOS quen thanh tab (tab bar) phía dưới màn hình. Người dùng Android quen cách bố trí khác. Ép hai nền tảng trông giống hệt sẽ làm cả hai cảm giác lạ.

Nhận diện thương hiệu là lớp lõi bên trong. Trải nghiệm nền tảng là lớp ngoài. Hai lớp này không xung đột nếu phân rõ từ đầu.

Nguồn chung: tại sao cần và trông như thế nào

Cách bền nhất để giữ đồng bộ là lập một nguồn chung cho các yếu tố lõi, rồi để từng nền tảng lấy về, thay vì mỗi nền tảng tự lưu bản riêng.

Trong thực hành thiết kế sản phẩm số, khái niệm này được gọi là token thiết kế (design token): mỗi giá trị màu, cỡ chữ, giãn cách được đặt tên và lưu ở một nơi duy nhất. Đội kỹ thuật nối token đó vào mã nguồn của web, iOS, Android. Khi cần đổi màu chính, chỉ đổi ở nguồn chung, toàn bộ nền tảng cập nhật theo.

Cập nhật một token tự áp qua mọi nền tảng. Không có nguồn chung, các nền tảng trôi khỏi nhau theo thời gian.

Tổng hợp từ iTitans, UXPin

Về phía thiết kế, nguồn chung đó là hệ màu đủ mã cho mọi môi trường, luật hệ chữ giữ nhịp đọc, và thư viện thành phần đã đồng bộ. Đây là phần Sinh Vũ dựng và giao. Việc nối token vào mã từng nền tảng là phần đội kỹ thuật của khách vận hành, không phải trách nhiệm thiết kế.

Khi nào đầu tư đồng bộ chặt, khi nào chưa cần

Đồng bộ bằng token đầy đủ phù hợp khi: sản phẩm đã ổn định, chạy thật trên ít nhất hai nền tảng, có đội kỹ thuật duy trì pipeline (luồng kết nối tự động từ nguồn chung tới mã sản phẩm). Đây là đầu tư có giá trị rõ ràng vì mỗi lần đổi thương hiệu chỉ cần làm một lần.

Luật và thư viện chung nhẹ hơn phù hợp khi: đội nhỏ, ít nền tảng, hoặc sản phẩm còn đang thay đổi nhiều. Lúc này, một tài liệu quy chuẩn rõ ràng và quy trình kiểm tra định kỳ đã đủ để kiểm soát lệch lạc.

Đầu tư đồng bộ chặt khi sản phẩm chưa ổn định là lãng phí, vì mỗi lần thay đổi cấu trúc sản phẩm lại phải làm lại cả pipeline. Mức đầu tư đồng bộ cần đo theo quy mô đội và độ ổn định của sản phẩm, không phải theo số nền tảng đơn thuần.

Lỗi thường gặp khi quản lý nhiều nền tảng

  • Sửa tay từng nền tảng rồi quên báo nhau: web đổi màu nút, Android không biết, hai tháng sau Anh / Chị nhìn vào mới phát hiện lệch. Đây là lỗi phổ biến nhất và hoàn toàn tránh được nếu có nguồn chung.
  • Ép iOS và Android trông giống hệt: kết quả là ứng dụng cảm giác lạ trên cả hai nền tảng vì không theo thói quen của người dùng nào.
  • Không có chủ sở hữu rõ ràng cho file chuẩn: mỗi người giữ một bản, không ai biết bản nào là thật. Khi cần kiểm tra chuẩn màu, mất thời gian truy lại từ đầu.
  • Đầu tư pipeline token khi sản phẩm còn thay đổi liên tục: tốn công theo kịp và thường bị bỏ giữa chừng.

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

Sinh Vũ tiếp cận bài toán này bằng cách phân rõ hai lớp: lớp lõi thương hiệu do Sinh Vũ dựng và giao, lớp kết nối kỹ thuật do đội của khách vận hành.

Phần Sinh Vũ giữ trách nhiệm: một hệ màu có đủ mã cho mọi môi trường hiển thị, luật hệ chữ giữ nhịp đọc xuyên nền tảng, thư viện thành phần đã được đồng bộ và tài liệu hóa đủ để đội kỹ thuật nối vào. Phần đội kỹ thuật khách: nối các giá trị đó vào mã nguồn của từng nền tảng và duy trì kết nối đó theo thời gian.

Sinh Vũ không tư vấn ép đồng nhất tuyệt đối vì đó không phải mục tiêu đúng. Mục tiêu là người dùng nhìn vào bất kỳ nền tảng nào cũng nhận ra ngay đây là thương hiệu của Anh / Chị, dù cách bố trí màn hình có khác nhau.

Nguồn tham khảo

iTitans: Design tokens cross-platform mobile UI. UXPin: Cross-device consistency. Kinh nghiệm thực hành Sinh Vũ Studio.

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

Token thiết kế là gì và tại sao cần dùng cho nhiều nền tảng?

Token thiết kế (design token) là tên gọi cho một giá trị được đặt tên, ví dụ: 'màu chính' thay vì ghi thẳng mã màu #1A2B3C vào từng chỗ. Khi thay đổi giá trị của token đó ở một nơi, toàn bộ sản phẩm trên mọi nền tảng cập nhật theo. Đây là cách tránh tình trạng web dùng một tông màu, iOS dùng tông khác vì ai đó sửa tay rồi quên báo.

iOS và Android có nhất thiết phải trông giống hệt nhau không?

Không nhất thiết và cũng không nên ép như vậy. Người dùng iOS quen thanh điều hướng phía dưới màn hình, người dùng Android quen với cách bố trí khác. Ép hai nền tảng trông giống hệt sẽ làm ứng dụng cảm giác lạ và khó dùng trên cả hai. Điều cần giữ nhất quán là màu, hệ chữ và logo, còn bố cục điều hướng nên theo thói quen từng nền tảng.

← Về Quy chuẩn nhận diện
{INJ}