Tiếp theo đây là phần 2 của 15 điểm UI/UX cho mảng banking mà mình rút ra được

Nếu bạn chưa đọc phần 1 thì tìm đọc tại đây nhé: https://hoangphan.blog/15-diem-ui-ux-cho-mang-banking-hay-va-can-luu-y-phan-1/

9. Đăng nhập và xác thực bằng sinh trắc học

Sinh trắc học ở đây bao gồm: Vân tay, khuôn mặt, mống mắt, tĩnh mạch, …. hiện nay thì thường thấy ở các App là xác thực bằng vân tay và khuôn mặt.

Những ai hay quên mật khẩu hoặc ít nhớ mật khẩu thì đăng nhập và xác thực giao dịch (giá trị nhỏ) bằng sinh trắc học vô cùng hữu hiệu, giúp đỡ phải nghĩ mật khẩu của ứng dụng là gì, bấm nhiều ký tự, mất nhiều thời gian – từ đó sử dụng sinh trắc học thì nhanh, tiện lợi, bảo mật hơn, và mang đến một trải nghiệm công nghệ cho người dùng cực tốt.

Một cái tiện nữa là khi bạn đang ở 1 quầy giao dịch đông người, thực hiện giao dịch bằng faceID hay vân tay trên thiết bị, giúp cho việc thanh toán nhanh hơn, và những người xung quanh sẽ không thể nào dòm ngó được mật khẩu hay mã PIN của bạn, xưa kia mình chơi game nhập mật khẩu cũng bị dòm ngó và bay hết đồ trong game luôn :D, ước gì lúc đó game có đăng nhập bằng vân tay/faceID trên máy tính. :)))

Nhưng việc dùng sinh trắc học cũng là một điểm trừ khi nó làm bạn gần như quên luôn mật khẩu, khi cần dùng đến mật khẩu thì phải lục tìm lại. Chị sếp trực tiếp của mình chọn cách đăng nhập bằng mật khẩu luôn thay vì dùng vân tay :v để tránh quên mật khẩu =)).

Còn đối với mình thì mình sài 1password để lưu MK, và mình cứ sài sinh trắc học để đăng nhập ứng dụng cho lẹ, đỡ phải ấn ấn cho lâu.

Note: Phía trên mình có ghi bảo mật hơn, ý này mình có đọc nhiều bài nghiên cứu của các chuyên gia bảo mật nói rằng xác thực bằng sinh trắc học bảo mật hơn.

Những người tham gia khảo sát đều bình chọn sinh trắc học là một trong những hình thức xác thực an toàn nhất, với 97% cho rằng nhận diện vân tay là một phương thức bảo mật cao, theo sau là công nghệ nhận diện mống mắt với 94%, và nhận diện khuôn mặt với 92%. Những hình thức này được đánh giá an toàn hơn các phương thức như xác thực bằng mã PIN với 87% và mật khẩu với 84%.

Và cũng dĩ nhiên khi một BA đưa tính năng đăng nhập và xác thực giao dịch bằng sinh trắc học, cần lưu ý về các trường hợp thêm một vân tay mới, xóa bớt vân tay, hay xóa toàn bộ vân tay – từ đó xử lý các trường hợp sao cho phù hợp để đảm bảo bảo mật cho ứng dụng. Ví dụ trường hợp thêm một vân tay mới ở thiết bị, thì ứng dụng khi được mở lên sau khi cài mới một vân tay cần có thông báo để KH biết và có phương án xử lý như tắt đăng nhập, xác thực bằng vân tay hoàn toàn hay là vẫn đồng ý sử dụng vân tay, từ đó chặn được rủi ro bảo mật sớm.

10. Đánh giá app

Hiện nay khi mình làm App mình thấy có nhiều chỗ đánh giá ứng dụng, nhưng mình thường chú ý tới đánh giá trên AppStore/CHPlay và đánh giá trên App và thu kết quả đánh giá về DB dự án dùng phân tích/đánh giá để cải thiện ứng dụng.

Cách đây một tháng, mình cũng ngồi cà phê với bạn chí cốt của mình làm product về book bác sĩ online, team phát triển của bạn đã họp nhiều lần và đánh giá rằng việc sử dụng đánh giá trên App trực tiếp sẽ giúp cho việc thu thập thông tin đánh giá nhanh và user real đánh giá ứng dụng thật. Ngoài ra nếu App có không được tốt quá thì rating trên AppStore/CHPlay cũng không bị quá thấp, vì KH đã đánh giá trên App – team sẽ khắc phục nhanh.

Nhưng cũng đừng lạm dụng việc đánh giá trên App quá, trước đây khi mình làm với 1 Bank, họ cũng đề xuất thêm rất nhiều chỗ để đánh giá App, nhưng mình chưa kịp phân tích xong chỗ nào cần đặt đánh giá/chỗ nào không cần thì đã nghỉ công ty mất tiu :D, chứ không giờ có thêm 1 mớ kinh nghiệm chia sẻ về phần này ở đây rồi (đùa thôi).

Dưới đây là một ví dụ mình thấy trên cộng đồng UI/UX Designers có chia sẻ về việc biểu mẫu đánh giá xuất hiện chưa đúng chỗ, mọi người xem tham khảo để tránh những trường hợp tương tự nhé, bài đăng lên thả haha quá trời luôn (hơn 60% thả haha)

11. Nhắc nhở thanh toán hóa đơn/đơn hàng

Về tính năng này thì mới xuất hiện vài năm gần đầy thôi, khi mà các ứng dụng về thanh toán xuất hiện hàng loạt, nhưng giờ tính năng cũng nằm khắp các ứng dụng từ momo, zalopay, viettelpay, vnpay, app ngân hàng.

Thường thì các hóa đơn điện, nước, internet, phí chung cư, thanh toán thẻ tín dụng … là lặp lại tại một ngày nào đó hằng tháng, nhưng khách hàng lại hay quên bén đi ngày đóng, do đó việc thêm tính năng nhắc nhở sẽ giúp cho khách hàng không quên thanh toán hóa đơn, cũng như giúp KH truy cập App nhiều hơn, dùng app của doanh nghiệp bạn để thanh toán – từ đó có lợi nhuận thêm cho doanh nghiệp – một yếu tố hàng đầu trong việc kinh doanh.

Việc nhắc nhở có thể thực hiện bằng cách hiển thị nổi bật, nhắc nhở trong tin nhắn, push notification, gửi tin nhắn về sđt cho KH,… hoặc kết hợp vài phương án lại, miễn sao thực hiện đúng mục đích và chi phí thấp nhất.

 

12. Hiển thị loại bàn phím phù hợp

Trong thời điểm làm việc với các App của ngân hàng, đây là một trong những điểm làm mình lâu lâu phải đọc lại tài liệu và chỉnh sửa nó.

Ban đầu thì chỉ cho nhập số, nhưng sau đó thay đổi yêu cầu cho nhập chữ, đôi lúc thì chỉ cho nhập chữ tiếng Việt không dấu, rồi bỏ dấu đi, nên khi thay đổi yêu cầu từ phía Bank, đầu nghiệp vụ và Dev, tester cũng phải cập nhật theo.

Nhưng đó là khi yêu cầu rõ ràng, và chủ động từ phía Bank. Đôi lúc đầu Bank chưa chủ động về việc nói ra chỗ đó cho phép nhập loại ký tự gì, thì đầu BA cũng cần có chút kinh nghiệm để hỏi rõ chi tiết, chi tiết nên kỹ đến mức là cho phép nhập ký tự đặt biệt thì cho phép những ký tự đặt biệt nào, có những trường hợp chỉ cho nhập vài loại ký tự đặt biệt thôi, từ đó hiển thị bàn phím phù hợp và kèm theo chặn trên đầu Client (App) để KH không nhập được. Nhất là trong trường hợp dữ liệu đẩy về CoreBanking – dữ liệu ký tự cần chuẩn hóa sao cho phù hợp với Core để không gây ra lỗi.

Việc kỹ từng ký tự và hiển thị bàn phím phù hợp sẽ giúp giải quyết được nhiều trường hợp lỗi bất ngờ và giúp trải nghiệm người dùng tốt hơn rất nhiều.

Một ví dụ cụ thể hơn đó là thanh toán hóa đơn – đóng học phí cho trường ABCXYZ.

Nếu BA thăm dò được rằng trường ABCXYZ thanh toán thông qua mã số sinh viên – và mã này chỉ có 10 ký tự số, thì bàn phím hiển thị loại bàn phím số, và cho nhập tối đa 10 ký tự, Client (đầu App) kiểm tra không cho phép paste ký tự chữ vào ô đó hoặc thậm chí là chặn paste vào trường mã số sinh viên luôn cũng được. Khi nhấn tiếp tục để kiểm tra thông tin sinh viên thì Client kiểm tra sẵn trường đã đủ 10 ý tự số chưa, nếu chưa đủ thì báo lỗi để SV nhập lại, còn đủ rồi thì mới truyền cho Server kiểm tra và gọi vào các đầu Core xử lý.

Sẵn tiện ở mục này, mình có 1 điểm hay cần chia sẻ luôn, thứ tự của các trường dữ liệu nhập vào – chọn từ danh sách cũng nên được phân tích để sắp xếp cho phù hợp, và tại đầu Client và Server kiểm tra thông tin hợp lệ cũng nên được xem xét để đầu Dev biết thứ tự kiểm tra phù hợp và thông báo cũng theo thứ tự lỗi luôn. Điều này giúp cho Dev develop dễ hơn, tester viết testcase cũng theo thứ tự và biết lỗi nào trước lỗi nào sau, một phần giúp cho 2 đầu App (iOS/Android) đồng bộ về báo lỗi – nhiều TH KH bị 2, 3 lỗi, nhưng thử ở các OS khác nhau lại hiển thị lỗi khác nhau hoặc thứ tự lỗi bị đổi cũng làm KH hoang mang – đội Dev ngồi tìm lỗi cũng mệt nhọc hơn sau này.

13. Tự động chọn loại chuyển tiền liên ngân hàng

Gần đây mình sử dụng một số ứng dụng thì thấy đã triển khai việc chuyển tiền thường và chuyển tiền qua Napas về chung 1 tụ.

Trước đây mình mới vào công ty, đa số ngân hàng đều phân ra chuyển tiền thường (có người tác động lên thì lệnh mới thực hiện được – thường là vài phút – vài tiếng hoặc 2 ngày nếu là cuối tuần thì lệnh mới được các bạn GDV thực thi) và chuyển tiền qua Napas/nhanh (thông qua hệ thống Napas, tiền chuyển đi trong vài chục giây, phút nếu hệ thống chạy trơn tru) – Nhưng KH thì đâu biết thường và Napas khác nhau thế nào đâu. Thậm chí trước khi mình làm mảng BA cho Finance/Banking thì chưa phân biệt được, và dùng còn nhầm, và người yêu mình cũng là một trong những người bị vướng phải khi cần chuyển tiền gấp cho người quen, và phải đợi tận 2 ngày tiền mới tới – nên phải chuyển thêm lần nữa qua Napas để tới liền, rồi đợi hoàn tiền từ người quen sau 2 ngày tiền kia tới.

Nên việc đưa về 1 tụ cho 2 ông chuyển khoản liên ngân hàng này là rất cần thiết, hoặc thậm chí là chuyển trong cùng ngân hàng (3 tụ về 1). Nhiều KH họ chỉ biết là chuyển cho STK nào, chủ tài khoản là ai và ngân hàng nào thôi, chứ họ không quan tâm chuyển qua kênh Napas hay thường, và cũng không phân biệt được chuyển đó là trong cùng ngân hàng hay khác ngân hàng.

Và trong việc chung về 1 tụ như thế này thì đầu Server sẽ detect xem rơi vào trường hợp chuyển tiền nào và từ đó gọi API về CoreBanking thực hiện cho đúng, với trường hợp chuyển tiền liên ngân hàng qua Napas bị lỗi thì App đề xuất KH thực hiện chuyển tiền thường (nếu muốn – và app có thông báo phí, thời gian thực hiện rõ ràng cho KH biết).

ps: Chú ý thêm vấn đề phí chuyển khoản, hạn mức, số lần được chuyển khoản trong ngày/tháng ở đây nhé – khi đi sâu vào vấn đề này thì cần phân tích kỹ hơn để đầu server chạy cho đúng từng trường hợp.

14. Nội dung chuyển tiền mặc định

Nội dung chuyển tiền nên được hiển thị mặc định, đôi lúc KH chỉ chuyển tiền giữa các tài khoản của mình nhưng khác ngân hàng, hay đơn giản là bạn bè cho mượn tiền thanh toán, và chuyển tiền ngay để trả thì nội dung cũng ít cần thiết tại thời điểm lúc đó.

Thay vì KH tốn thời gian nhập nội dung chuyển tiền thì App để mặc định nội dung với tên KH, ví dụ “Nguyen Van A ck” là một phương án vô cùng hợp lý, và KH có thể thay đổi nội dung chuyển tiền cho phù hợp nếu thật sự cần điền nội dung chuyển tiền. Hiển nhiên với các trường hợp Chuyển tiền cần nội dung chi tiết, thì KH luôn được nhắc nhở, hoặc thông tin chuyển tiền thường đã đề cập nội dung chuyển tiền ⇒ VD như chuyển tiền cho PhiEnglish học tiếng Anh (dự án trung tâm tiếng Anh của mình) thì trong email gửi cho KH mình luôn đề cập kỹ đến nội dung chuyển tiền và tô đậm lên cho KH biết.

15. Tìm kiếm ngân hàng thụ hưởng

Khi chọn ngân hàng thụ hưởng, bạn sẽ tìm kiếm ngân hàng đó như thế nào?

VD như ngân hàng VCB thì 1 số KH lại nhớ ký hiệu VCB thôi, có KH thì lại nhớ Vietcombank, hoặc ngân hàng ngoại thương (thường tên đầy đủ ngta lại ít nhớ hơn, nào là ngoại thương, kỹ thương, công thương, thương tín…)

VCB – Vietcombank – Ngân hàng ngoại thương – Ngân hàng thương mại cổ phần Ngoại thương Việt Nam.

Nên việc tìm kiếm tên ngân hàng thụ hưởng cũng cần được thể hiện ở nhiều loại tên khác nhau, hoặc có thể viết gọn (hiển thị trên App), nhưng vẫn cho phép tìm kiếm với đầy đủ thể loại.

Với lại nên sài tiếng Việt có dấu đầy đủ cho KH dễ đọc ở mục hiển thị trên App, thay vì sài tiếng Việt không dấu trả từ CoreBanking ra – làm cho việc đọc tên ngân hàng bị khó đi.

Nên tránh hiển thị thêm các mã ngân hàng trong tên, chỉ làm KH loạn thêm – vì họ chẳng biết mã đó là mã gì mà còn làm họ suy nghĩ có khi nào mình chọn sai ngân hàng không, hay nó là số gì đó ảnh hưởng không phải người nhận đúng chỗ.

Với ví dụ trên, thì khi KH tìm kiếm ngân hàng Vietcombank có thể xảy ra các trường hợp nhập như sau:

• Vietcombank
• VCB
• vietcombank
• ngoai thuong
• ngoại thương

Thì việc hiển thị ra được thông tin ngân hàng đúng là một điều rất tuyệt vời và cải thiện trải nghiệm người dùng rất nhiều. Và tên hiển thị ra có thể chỉ là “VCB – Ngân hàng ngoại thương” (nếu kèm logo được thì tốt) một cách gọn ghẻ trên màn hình mobile, nhưng tìm với nhiều loại keyword bao gồm cả Vietcombank thì vẫn tìm ra được đúng ngân hàng đích.

Bổ sung thêm là ds này lên load lúc màn hình khởi tạo để việc tìm kiếm tên là có ngay, thay vì KH phải đợi để load từ corebank hay từ confign lên – mất một thời gian phải chờ đợi.

Kết luận

15 điểm UI/UX được trình bày phía trên là một trong những trải nghiệm riêng của bản thân khi làm việc mảng BA cho Banking, hi vọng bài viết sẽ giúp đỡ bạn đọc hiểu thêm/cách nhìn thêm về 1 khía cạnh làm việc của vị trí Business Analyst cũng có liên quan đến một phần UI/UX.

Giới thiệu profile

Mình có khoảng gần 2 năm làm việc tại VNPay với vị trí Business Analyst (chuyên viên phân tích nghiệp vụ), với khoảng thời gian này mình được tham gia nhiều dự án từ Mobile Banking/Internet Banking, Mảng thẻ ngân hàng/thẻ thanh toán, Thanh toán vé máy bay, Đặt và thanh toán vé xe, vé tàu, topup, billing, payment gate,… Nhưng phần lớn thời gian thì mình tập trung vào các dự án với các Bank – đa số là các Bank nằm trụ sở trong miền Nam, với kinh nghiệm của bản thân – mình rút ra được 15 điểm UI/UX cần lưu ý cũng như mình thấy hay và chia sẻ lại cho mọi người. Mọi người đọc qua nếu thấy điểm nào chưa hợp lý thì góp ý giúp mình nhé.

1. Ứng dụng chơi được nhiều thể loại font-size

Ý tưởng của bài viết này cũng từ ý đầu tiền này, khi cháu mình đang học đại học dùng điện thoại với font-size rất to, mình mới hớ ra là khi mình làm việc cũng gặp một vài khách hàng báo lỗi ứng dụng khi họ sài font-size to, đặc biệt là một số KH lớn tuổi – mắt kém.

Do chỗ lỗi khi xưa đã được fix, nên mình dùng tạm hình trên mạng để bạn hình dung normal size và big size

Khi KH đó thực hiện tải ứng dụng có giao diện mới trên 1 Bank mình làm hồi đó, tại các màn hình giới thiệu giao diện mới này, thì khi ở kích thước font-size bình thường hoặc nhỏ thì ứng dụng vẫn hoạt động bình thường, KH có thể nhấn nút tiếp tục hoặc skip để bỏ qua. Nhưng nếu KH cài đặt font-size lớn (trên thiết bị), thì nút Skip và nút tiếp tục bị ẩn đi, và không thể nào scroll để đi tiếp màn hình tiếp theo.

Dĩ nhiên cách khắc phục tạm thời cho KH sử dụng là chỉnh font-size của thiết bị nhỏ lại theo kích thước bình thường, rồi xem xong phần giới thiệu giao diện mới, rồi vào app sài bình thường, và chỉnh lại kích thước font-size lại như KH vẫn sài. Sau đó thì phía tester/UI/UX đánh giá lại để khắc phục lỗi này bằng cách cho scroll để xem hết nội dung, còn nút skip và tiếp tục có thể để fixed ở phần bottom của màn hình để KH có thể nhấn được.

Nhưng đó cũng là một điểm mà các bạn BA/Tester/UI/UX nên chú ý để ứng dụng làm ra được ok hơn, tránh một số lỗi tương tự, làm mất thời gian build lại app, nâng version app, rồi KH lại tốn thời gian ra quầy hỗ trợ, gọi đủ bên để hỗ trợ việc này.

2. Đồng nhất UI và UX giữa mobile app và internet banking

Ở đây mình sẽ phân ra 2 loại:

• Đồng bộ giao diện giữa Mobile Banking với Internet Banking (sau này 2 cái này các bank chuyển đổi theo hướng Omni Channel nên có nhiều bank đã đồng bộ cả về dữ liệu, hệ thống và giao diện)
• Đồng bộ giao diện giữa 2 app mobile trên Android và iOS (và ứng dụng tên OS Mobile khác)

Hiện nay thì các Bank cũng có xu hướng chuyển sang xây dựng Omni (đồng nhất đa kênh) cho kênh MB và IB xưa kia, đồng nhất 2 kênh này lại cùng về 1 hệ thống, chỉ khác là mặt giao diện giao tiếp với KH phía trên, nên việc giao diện trên nền tảng mobile app và web đã được nhiều Bank phân tích thiết kế sao cho tương đối đồng nhất về UI, và nếu được thì cả phần UX.

Trước đây khi mình sài MB và IB riêng của 1 số Bank, mình tốn công phải nhớ 2 tài khoản khác nhau, với những mã user đăng nhập là mã Cif hoặc 1 mã gì đó do Bank đưa ra. Nay thì đã đỡ hơn nhiều khi các Bank chuyển sang Omni (hoặc xây dựng gần gần kiểu Omni) và chuyển đăng nhập bằng SĐT hoặc một kiểu user do người dùng có thể cài đặt.

Về phần đồng nhất giữa các App trên Android và iOS thì cũng cần được chú trọng, đặc biệt là các luồng xử lý về mặt giao diện.

Mình cũng từng gặp vài trường hợp KH sài trên Android quen rồi, nhưng khi qua trên iOS thì luồng của ứng dụng lại có thay đổi, làm cho KH khi sử dụng chưa quen thì cảm thấy không thoải mái hoặc thậm chí làm sai luồng thao tác. Trường hợp này thì thường xảy ra khi 2 đội Dev iOS và Android là khác nhau (dev native app), mà việc kiểm tra lại luồng không được thực hiện kỹ. Với tính của mình thì mình cũng rất hay soi kỹ việc này nên né tránh được kha khá phàn nàn từ người dùng. Còn với trường hợp dev cross platform thì giao diện là giống nhau rồi, chỉ có vài điểm OS 2 bên không hỗ trợ thì có thể code để thay đổi tí tẹo.

Dĩ nhiên trường hợp Native App cũng vậy, cũng cần xem xét OS 2 bên có hỗ trợ để làm giống nhau không? Hay xem xét việc làm giống nhau mà tốn quá nhiều effort mà không quá ảnh hưởng gì đến việc người dùng sử dụng về UX thì cũng có thể bỏ qua.

3. Ưu tiên tùy chỉnh cá nhân hóa

Theo mình tìm hiểu thì đây là một xu hướng thiết kế mobile trong những năm nay khi ưu tiên việc cá nhân hóa người dùng lên hàng đầu, từ đó người dùng có thể tùy chỉnh vị trí các tính năng ngay trên ứng dụng.

Đặc biệt khi hiện nay trên một app tài chính/ngân hàng có quá nhiều tính năng, và khi KH chỉ sài có vài tính năng thường dùng, việc tùy chỉnh đưa lên đầu app là vô cùng quan trọng, làm cho việc trải nghiệm KH trên ứng dụng hoàn toàn đỉnh hơn rất nhiều.

Hoặc việc KH thay đổi màu giao diện App theo sở thích cá nhân, background bên trong ứng dụng cũng khiến KH thoải mái hơn khi sử dụng ứng dụng.

4. Giao diện theo thời điểm trong ngày/mùa

App của ABBANK thay đổi màu theo buổi sáng và buổi chiều/tối, App của BIDV hình như đổi nền trước đăng nhập theo buổi sáng, buổi trưa, buổi tối, rồi thay đổi câu chào theo từng buổi khác nhau.

Ý này mình đang nghiên cứu =)) ít hôm nữa tìm ra rồi thì mình viết bổ sung. Xưa làm thì có hỏi mấy bạn bên Bank vụ này vì sao có thì nhớ có trả lời mà mình giờ quên rồi. …

Hoặc bạn nào biết thì giúp mình trả lời ở phần comment nha.

5. Lưu ý cài đặt mặc định cho các nút toggle switch

Này mình cũng rất lưu tâm khi làm tài liệu nghiệp vụ, khi các nút tongle thể hiện việc YES hay NO cho việc bật một tính năng nào đó lên, nhưng đặt mặc định là gì cho phù hợp?

Việc này thì BA cần lưu ý, đặc biệt là các vấn đề liên quan đến bảo mật cần chú trọng.

Ví dụ trường hợp nút cho phép đăng nhập trên trên Web để thực hiện giao dịch thường bị hạn chế, thì cài đặt không cho phép đăng nhập trên web là mặc định, để mở chức năng đăng nhập thì cần thực hiện mở trên điện thoại, tránh kẻ gian nắm thông tin và thực hiện giao dịch trên ứng dụng web ngoài sự cho phép của chủ sở hữu tài khoản.

6. Hiển thị phôi thẻ lên trên ứng dụng

Hiện nay việc sử dụng thẻ ghi nợ/tín dụng/trả trước không còn quá xa lạ với người dùng, và việc có nhiều thẻ thì cũng tương tự, nên việc hiển thị phôi thẻ trên ứng dụng điện thoại trong mục thẻ cũng giúp cho người dùng dễ phân biệt giữa các thẻ với nhau một cách nhanh chóng. Ngoài ra việc thanh toán thẻ trực tuyến bằng cách 1 chạm sẽ ngày càng phổ biến, nên hiện tại việc hiển thị phôi thẻ y như thật lên trên điện thoại là điều nên làm.

Lưu ý là phôi thẻ thì nên có một phôi mặc định, tránh trường hợp không lấy được thông tin của thẻ hoặc hình ảnh phôi thẻ thì cũng có một phôi mặc định hiển thị.

7. Thông tin thẻ/tài khoản nên được ẩn tránh lộ thông tin

Như ở mục số 6 mình có nêu ra, hiện nhiều Bank đã đưa hình phôi thẻ lên trên ứng dụng, nhưng nếu không cẩn thận thì thông tin của thẻ sẽ dễ bị lộ nếu không chú ý, đặc biệt là thông tin thẻ trên đường truyền đi từ Core/Trung tâm thẻ ra, nên được bảo mật và giải mã phía đầu client để hiển thị.

Như nút hiển thông tin thẻ ở hình phía trên khi nhấn vào sẽ không có dữ liệu hiển thị ngay, mà phải gọi về trung tâm thẻ để lấy dữ liệu lên, và dữ liệu thẻ đã được mã hóa, đến Client được giải mã theo 1 key client nắm giữ.

Và cả việc chụp màn hình ở màn hình này cũng nên bị chặn, đặc biệt với thẻ credit thanh toán trực tuyến thông qua số thẻ, exp date, cvv.

8. Số dư tại màn hình thanh toán/chuyển khoản thành công

Việc bạn thực hiện xong một thanh toán, hay chuyển khoản và chụp màn hình lại gửi cho bạn bè/người cần nhận là bình thường đúng không?

Nhưng có bạn nào muốn họ thấy số dư tài khoản của bạn không nhỉ?

Ban đầu cách đây vài năm thì mình hay thấy chuyển khoản, hay thanh toán thì số dư hiện tại (của tài khoản) có thông tin hiển thị ra, rất bất tiện khi người nhận không nên biết về số dư đó, nên như mình xưa là phải cắt cái màn hình đó ra, chỉ để lại phần thông tin giao dịch gửi cho bạn/bè.

Giờ đây thì đa số các ngân hàng đã hiểu ra chuyện đó và bỏ đi dòng số dư hiện tại đi, kèm theo đó để thêm tính năng chia sẻ để gửi màn hình kết quả cho bạn bè nhanh hơn qua social.

Do bài viết cũng khá dài rồi, nên mình cắt ra làm 2 phần, phần 2 bạn đọc tại đây nhé: https://hoangphan.blog/15-diem-ui-ux-cho-mang-banking-hay-va-can-luu-y-phan-2/

Hi vọng bài viết này sẽ giúp bạn có thêm một số case study thực tế mình đã được thực hiện qua.