Hệ thiết kế số cho ngân hàng: compliance trước, đẹp sau

Ngân hàng số và ví điện tử đối mặt với hai áp lực cùng lúc: luật pháp yêu cầu giao diện tiếp cận được với mọi người dùng, và kinh doanh yêu cầu một nền tảng phục vụ nhiều nhóm khách khác nhau. Nếu hệ thiết kế được dựng không đúng lớp từ đầu, cả hai áp lực đó đều trở thành nợ kỹ thuật và rủi ro niềm tin.

Tại sao tiếp cận là ràng buộc, không phải tính năng

Chuẩn WCAG (Web Content Accessibility Guidelines, tạm dịch: Hướng dẫn tiếp cận nội dung web) do W3C ban hành đã được nhiều hệ thống luật viện dẫn trực tiếp. Đạo luật Tiếp cận châu Âu (EAA) có hiệu lực từ ngày 28/06/2025 và áp dụng rõ ràng cho dịch vụ tài chính. Nếu sản phẩm phục vụ khách hoặc đối tác tại EU, đây không còn là khuyến nghị thiết kế mà là nghĩa vụ pháp lý.

WCAG 2.2 mức AA đưa ra bốn nguyên tắc nền, gọi tắt là POUR: cảm nhận được (Perceivable), thao tác được (Operable), hiểu được (Understandable), bền vững (Robust). Với ngân hàng số, bốn nguyên tắc này chạm trực tiếp vào các vùng nhạy cảm nhất: xác thực người dùng, điền form chuyển tiền, hiển thị số dư, và cảnh báo lỗi giao dịch. Đây cũng là nơi mất niềm tin nhanh nhất nếu thông tin không rõ hoặc thao tác gặp rào cản.

Sinh Vũ đặt WCAG 2.2 mức AA làm baseline ngay từ tầng token, tức là tương phản màu, cỡ chạm tối thiểu và chỉ báo tiêu điểm (focus indicator, viền hiển thị khi dùng bàn phím điều hướng) được tích hợp vào nguyên liệu thô trước khi component ra đời. Component khi được lắp vào màn hình không cần kiểm tra tiếp cận lại từ đầu.

Đa phân khúc: dùng token ngữ nghĩa, không dựng bản rời

Một ngân hàng thường có ít nhất ba nhóm người dùng với nhu cầu giao diện khác nhau: khách bán lẻ dùng app cá nhân, khách doanh nghiệp dùng cổng quản lý tài khoản và lương, đối tác tích hợp dùng dashboard API. Phản xạ tự nhiên là dựng ba bộ giao diện riêng. Đây là lỗi cấu trúc.

Kiến trúc token ba tầng giải quyết bài toán này gọn hơn nhiều. Tầng một là token gốc (primitive token): các giá trị màu, khoảng cách, chữ ở dạng thuần. Tầng hai là token ngữ nghĩa (semantic token): gán ý nghĩa cho giá trị, ví dụ "màu nền hành động chính" hay "màu cảnh báo lỗi". Tầng ba là token thành phần (component token): gắn vào từng phần tử cụ thể. Khi cần phân khúc bán lẻ có màu nhận diện khác doanh nghiệp, chỉ cần ghi đè tầng ngữ nghĩa, tầng gốc và component logic vẫn dùng chung.

Những chỗ mất niềm tin nhanh nhất

Không phải màu sắc hay font chữ làm khách ngân hàng mất tin. Là trạng thái lỗi. Khi khách nhập sai số tài khoản, ứng dụng báo lỗi mỗi màn một kiểu thì khách không biết mình sai ở đâu và có nên thử lại không. Hệ thiết kế phải chuẩn hóa toàn bộ vòng xác nhận: thông báo lỗi, trạng thái thành công, cảnh báo cần xem xét lại, tất cả phải nhất quán về vị trí, ngôn ngữ và màu sắc.

WCAG 2.2 nhấn đúng vào điểm này: xác thực phải có phương án thay thế (không chỉ màu để phân biệt đúng sai), form phải có chỉ dẫn rõ trước khi lỗi xảy ra, không chỉ sau. Với ngân hàng số, tuân thủ WCAG ở vùng form và xác thực vừa là yêu cầu pháp lý vừa là điều trực tiếp giữ khách ở lại.

Khả năng tiếp cận không phải lớp sơn cuối cùng. Nó là cấu trúc của tòa nhà.

Nguyên tắc thực hành Sinh Vũ, dựa trên WCAG 2.2 và kinh nghiệm triển khai

Ranh giới cần giữ rõ với studio thiết kế

Một điểm dễ gây nhầm: hệ thiết kế số không bao gồm lõi nghiệp vụ ngân hàng. Xử lý giao dịch, quản lý tài khoản, tích hợp core banking, bảo mật tầng API là phần của đội kỹ thuật nội bộ hoặc nhà cung cấp hệ thống ngân hàng. Studio thiết kế làm lớp giao diện, hệ nhận diện số, cấu trúc component và token. Ranh giới này cần được thống nhất trước khi dự án bắt đầu, để không có kỳ vọng lệch ở giữa đường.

Với các mốc tuân thủ pháp lý, phần kiểm toán tiếp cận (accessibility audit) nên có chuyên gia pháp lý hoặc chuyên gia tiếp cận xác nhận độc lập. Sinh Vũ cung cấp nền tảng đủ điều kiện để vượt kiểm toán, nhưng xác nhận cuối cùng thuộc về người có thẩm quyền pháp lý.

Lỗi thường gặp khi dựng hệ cho ngân hàng

• Coi tiếp cận là việc cuối dự án. Hậu quả: phải làm lại hàng loạt màn hình khi bị rà soát, chi phí cao hơn nhiều so với tích hợp từ đầu.
• Dựng bản giao diện riêng cho từng phân khúc thay vì tách token ngữ nghĩa. Dẫn tới nhân bản component, mỗi lần cập nhật phải chạy nhiều nơi và dễ lệch.
• Trạng thái lỗi và xác thực không chuẩn hóa. Đây là nơi khách mất tin tưởng nhanh và trực tiếp nhất.
• Kỳ vọng studio giao diện xử lý luôn tích hợp lõi nghiệp vụ. Phần đó nằm ngoài phạm vi thiết kế số và cần đội kỹ thuật chuyên biệt.