Hệ thiết kế số cho fintech: khi compliance và brand phải sống chung

Ngân hàng số và ví điện tử đặt ra bài toán khó nhất mà một hệ thiết kế số (design system) phải giải quyết: vừa phải đẹp đúng thương hiệu, vừa phải tuân thủ quy định pháp lý, vừa phải phục vụ nhiều nhóm khách hàng rất khác nhau trên cùng một nền tảng. Ba yêu cầu này không mâu thuẫn nhau về bản chất, nhưng sẽ xung đột ngay lập tức nếu hệ thiết kế không được tổ chức đúng cách ngay từ đầu.

Tại sao phải tách ba lớp riêng biệt

Lỗi kiến trúc phổ biến nhất Sinh Vũ gặp ở sản phẩm tài chính là dùng chung token (đơn vị giá trị thiết kế như màu sắc, cỡ chữ, khoảng cách) cho cả yêu cầu pháp lý lẫn nhận diện thương hiệu. Khi Ngân hàng Nhà nước hoặc cơ quan quản lý yêu cầu thay đổi cách hiển thị thông tin giao dịch, đội kỹ thuật phải lần mò sửa từng component một vì không biết component nào đang mang giá trị pháp lý, component nào mang giá trị thương hiệu.

Giải pháp là kiến trúc token ba cấp theo nguyên tắc của Nathan Curtis và cộng đồng EightShapes:

• Global tokens: giá trị gốc nguyên liệu, ví dụ màu xanh cụ thể theo mã hex, cỡ chữ 14px.
• Semantic tokens (token ngữ nghĩa): gắn ý nghĩa cho giá trị, ví dụ "màu nền cảnh báo giao dịch", "cỡ chữ nhãn bắt buộc hiển thị theo quy định".
• Component tokens: token cụ thể cho từng thành phần giao diện, kế thừa từ semantic tokens.

Với cấu trúc này, khi cơ quan quản lý yêu cầu tăng kích thước chữ trong màn hình xác nhận giao dịch, đội kỹ thuật chỉ cần sửa semantic token tương ứng. Thương hiệu không bị ảnh hưởng. Audit cũng dễ hơn vì có thể truy ngược token nào phụ trách tuân thủ pháp lý.

Yêu cầu accessibility không phải tuỳ chọn

WCAG 2.2 (Web Content Accessibility Guidelines, hướng dẫn khả năng tiếp cận nội dung web) mức AA là tiêu chuẩn tối thiểu Sinh Vũ áp dụng mặc định cho mọi giao diện tài chính. Hai yêu cầu hay bị vi phạm nhất:

• Tương phản màu tối thiểu 4.5:1 cho văn bản thông thường và 3:1 cho văn bản lớn, theo W3C WCAG 2.2 (2023). Nhiều màu brand được chọn vì đẹp nhưng không đạt ngưỡng này.
• Kích thước vùng tương tác (touch target) đủ lớn để người dùng thao tác chính xác, đặc biệt quan trọng trong màn hình nhập số tiền và xác nhận chuyển khoản.

Sai lầm tốn kém nhất là chọn màu brand trước, build xong rồi mới kiểm tra tương phản và phát hiện không đạt. Lúc đó phải sửa lại toàn bộ màu sắc trong hệ thống, ảnh hưởng đến cả tài liệu thương hiệu đã in ấn và đã phát hành.

Phục vụ đa phân khúc mà không loãng thương hiệu

Ví điện tử và ngân hàng số thường phục vụ đồng thời khách hàng phổ thông, khách hàng cao cấp, và doanh nghiệp nhỏ và vừa (SME). Ba nhóm này có kỳ vọng giao diện khác nhau rõ rệt. Giải pháp là theming phân khúc, tức là dùng cùng một tập component nhưng thay đổi semantic tokens để tạo ra diện mạo khác biệt theo phân khúc, trong khi global tokens và cấu trúc component vẫn giữ nguyên.

Luồng giao dịch nhạy cảm cần error prevention rõ ràng

Nielsen Norman Group xếp error prevention (ngăn lỗi xảy ra) và error recovery (giúp phục hồi sau lỗi) là ưu tiên hàng đầu trong giao diện giao dịch tài chính, vì hậu quả của thao tác nhầm rất nghiêm trọng và thường không hoàn tác được ngay lập tức. Điều này dịch ra thành các yêu cầu component cụ thể:

• Màn hình xác nhận giao dịch phải hiển thị đầy đủ thông tin trước khi thực hiện, không rút gọn.
• Luồng chuyển tiền cần ít nhất một bước confirm rõ ràng, tách biệt về mặt thị giác khỏi bước nhập liệu.
• Trạng thái loading, success, error, và timeout phải được thiết kế đầy đủ. Người dùng không được ở trạng thái không biết giao dịch đã thành công hay chưa.
• Component eKYC (xác minh danh tính điện tử), OTP (mật khẩu một lần), và xác thực sinh trắc học cần được chuẩn hóa thành component tái sử dụng được, có trạng thái lỗi rõ ràng.

Trong giao diện giao dịch tài chính, người dùng đánh giá mức độ bảo mật của sản phẩm qua giao diện trước khi họ hiểu bất kỳ điều gì về kỹ thuật bên dưới. Visual cues như biểu tượng khóa, thông báo xác nhận rõ ràng, và màu sắc trạng thái nhất quán là phần của security UX, không chỉ là trang trí.

Thực hành ngành fintech UX, được ghi nhận rộng rãi trong cộng đồng thiết kế sản phẩm tài chính

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

Sinh Vũ thường bắt đầu dự án tài chính với khoảng 80 component vì luồng nghiệp vụ tài chính có nhiều trạng thái hơn SaaS thông thường. Con số này không cố định, sẽ kiểm kê lại theo luồng thực tế của từng dự án. Hai việc Sinh Vũ làm ngay trong tuần đầu là kiểm tra bộ màu brand theo WCAG 2.2 AA và lập sơ đồ phân tầng token trước khi viết bất kỳ dòng component nào.

Phần Sinh Vũ không nhận: logic nghiệp vụ tài chính cốt lõi, core banking system, và backend xử lý giao dịch. Giới hạn này giúp đội kỹ thuật tài chính của khách giữ toàn quyền kiểm soát phần nhạy cảm nhất, còn Sinh Vũ tập trung làm đúng phần giao diện và trải nghiệm người dùng.