Mở đầu — vì sao bài này quan trọng
Suốt 55 bài trước, bạn đã học từng viên gạch: hierarchy, typography, color system, auto layout, component, design token, dev handoff. Nhưng học rời rạc từng kỹ thuật rất khác với việc ghép chúng lại để giải một bài toán thật, có ràng buộc thật, có sếp và có deadline.
Bài 56 là bài "chạy thử toàn tuyến". Chúng ta sẽ đóng vai một UI Designer được giao redesign app mobile của một ngân hàng, và đi qua nguyên chu trình: từ lúc đọc dữ liệu than phiền của người dùng, cho tới lúc bàn giao file Figma cho đội kỹ thuật. Đây chính là dạng bài mà nhà tuyển dụng bắt bạn kể trong buổi phỏng vấn, và cũng là dạng case study làm nên hoặc phá hỏng một portfolio.
Vì sao lại chọn ngân hàng? Vì banking app là "bài thi khó" nhất của ngành. Nó có ràng buộc pháp lý, có yếu tố tiền bạc (sai một ly là mất tiền thật), có người dùng đủ mọi lứa tuổi từ sinh viên tới các bác về hưu, và có áp lực bảo mật đè lên trải nghiệm. Nếu bạn redesign được banking app một cách tử tế, bạn xử được gần như mọi sản phẩm khác. Hãy xem đây là bản đồ tư duy để bạn tự tin bước vào dự án thật đầu tiên.
Khái niệm cốt lõi
Một case study redesign nghiêm túc không phải là "app cũ xấu, tôi làm cho đẹp hơn". Nhà tuyển dụng và đồng nghiệp giỏi sẽ nhìn thẳng vào cách bạn tư duy, chứ không chỉ nhìn ảnh đẹp. Có bốn trụ cột.
1. Vấn đề đặt trước giải pháp (Problem framing)
Trước khi mở Figma, bạn phải trả lời được: "Chúng ta đang giải quyết nỗi đau nào, của ai, đo bằng con số gì?" Trong tình huống của bài — ngân hàng VN top 10, app đang bị 2.5 sao, hơn 50% phàn nàn xoay quanh sự rối rắm (UX confusion) ở ba luồng chính là chuyển tiền (transfer), thanh toán hóa đơn (bill pay) và tiết kiệm (saving) — thì "làm đẹp" không phải mục tiêu. Mục tiêu là giảm confusion, giảm số bước, giảm lỗi thao tác trong ba luồng đó.
2. Ràng buộc là bạn, không phải thù (Constraints)
Banking có ràng buộc đặc thù: xác thực OTP, giới hạn hạn mức, quy định của Ngân hàng Nhà nước, hệ thống core banking cũ không thể đổi trong một sớm một chiều. Người mới hay coi ràng buộc là kẻ thù. Người giỏi coi ràng buộc là khung để sáng tạo có kỷ luật. Bạn không thể bỏ bước OTP, nhưng bạn có thể làm cho nó bớt đau.
3. Đo được trước và sau (Metrics)
Một redesign không có số đo giống như bốc thuốc không bắt mạch. Bạn cần định nghĩa "trước" (baseline) và "sau" (target). Ví dụ: tỷ lệ hoàn tất chuyển tiền (transfer completion rate), thời gian trung bình để hoàn tất một giao dịch, tỷ lệ bỏ giữa chừng (drop-off), số ticket than phiền mỗi tuần, và điểm rating trên store.
4. Kể chuyện có cấu trúc (Narrative)
Case study cuối cùng phải kể được: Bối cảnh → Vấn đề → Nghiên cứu → Giải pháp → Kết quả → Bài học. Đây là bộ khung vàng. Thiếu phần "Kết quả" và "Bài học", case study của bạn chỉ là một tập ảnh screen.
Ba luồng, ba bài toán khác nhau
Đừng gộp chung ba luồng. Mỗi cái có bản chất riêng:
- Transfer (chuyển tiền): bài toán về tốc độ và sự an tâm. Người dùng lo nhất là "gửi nhầm người" và "gửi nhầm số tiền". Confusion thường đến từ việc nhập số tài khoản dài, chọn ngân hàng thụ hưởng, và màn xác nhận mập mờ.
- Bill pay (thanh toán hóa đơn): bài toán về sự lặp lại và ghi nhớ. Người ta trả tiền điện, nước, internet hằng tháng. Confusion đến từ việc phải tìm lại nhà cung cấp, nhập lại mã khách hàng mỗi lần.
- Saving (tiết kiệm): bài toán về niềm tin và sự minh bạch. Người dùng sợ "khóa tiền" và không hiểu lãi suất, kỳ hạn, điều kiện rút trước hạn. Confusion đến từ thuật ngữ tài chính khó hiểu và các lựa chọn kỳ hạn rối mắt.
Tình huống thực tế
Ví dụ 1 — Luồng chuyển tiền của "VietBank" (ngân hàng giả định top 10)
Đội của một bạn designer tên Linh nhận baseline như sau: luồng chuyển tiền cũ có 7 bước, transfer completion rate chỉ 68%, và phân tích session cho thấy người dùng dừng lâu nhất ở màn "chọn ngân hàng thụ hưởng" (một dropdown 40+ ngân hàng xếp theo bảng chữ cái, không có tìm kiếm) và màn "xác nhận" (chỉ hiện số tài khoản, không hiện tên người nhận đủ lớn).
Linh làm ba can thiệp. Một, thêm ô tìm kiếm và ghim 5 ngân hàng dùng gần đây lên đầu danh sách. Hai, sau khi nhập số tài khoản, hệ thống trả về tên người thụ hưởng và Linh cho hiển thị tên đó ở cỡ chữ lớn nhất màn hình xác nhận, vì "gửi đúng người" là nỗi lo số một. Ba, gộp bước "nhập nội dung" và "nhập số tiền" vào một màn.
Kết quả sau 6 tuần A/B test: luồng giảm còn 5 bước, completion rate lên 84%, và số ticket "chuyển nhầm" giảm rõ rệt.
Bài học: Đừng tối ưu cái dễ đo (thời gian) mà bỏ quên cái người dùng thực sự lo (gửi đúng người). Confirmation screen là nơi giảm lỗi tốt nhất — hãy phóng to đúng thông tin quan trọng, không phải mọi thông tin.
Ví dụ 2 — Grab và bài học "tự động điền" cho bill pay
Hãy nhìn sang một ví dụ có thật trong khu vực. Trên ví điện tử của Grab (GrabPay) và các ví như MoMo, ZaloPay ở Việt Nam, luồng thanh toán hóa đơn điện nước gần như đã bỏ hẳn việc nhập mã khách hàng thủ công cho lần thứ hai trở đi. Sau lần đầu, hệ thống ghi nhớ nhà cung cấp và mã khách hàng, biến việc trả tiền điện tháng sau thành hai chạm: chọn hóa đơn đã lưu, xác nhận.
Áp dụng vào case VietBank: bạn designer phát hiện 73% giao dịch bill pay là các hóa đơn lặp lại hằng tháng của cùng một người. Vậy thì thiết kế cũ bắt họ nhập lại mã khách hàng mỗi lần là một tội "lười thiết kế". Giải pháp: một khu "Hóa đơn của tôi" ở đầu luồng, tự động gợi ý các hóa đơn tới kỳ, kèm nhắc "Điện tháng 6 — đến hạn 15/06". Kèm theo là tùy chọn thanh toán tự động (auto-debit) cho ai muốn.
Bài học: Với các tác vụ lặp lại, thiết kế tốt là thiết kế biết ghi nhớ. Hãy hỏi "người dùng đã cho mình thông tin này lần trước chưa?" trước khi bắt họ nhập lại.
Ví dụ 3 — TNEX/Timo và sự minh bạch trong luồng tiết kiệm
Các ngân hàng số như Timo tại Việt Nam đã tạo khác biệt ở luồng mở tài khoản tiết kiệm bằng cách "dịch" ngôn ngữ tài chính sang ngôn ngữ đời thường. Thay vì bắt người dùng đọc bảng lãi suất khô khan theo kỳ hạn, họ cho nhập số tiền và hiển thị ngay: "Gửi 10 triệu, kỳ hạn 6 tháng, bạn nhận thêm khoảng 250.000đ tiền lãi". Con số cụ thể xóa tan sự mơ hồ.
Trong case VietBank, luồng saving cũ hiển thị một ma trận lãi suất theo 8 kỳ hạn khác nhau khiến người dùng tê liệt vì quá nhiều lựa chọn (choice paralysis). Giải pháp là đảo ngược: hỏi người dùng "Bạn muốn gửi bao nhiêu và khi nào cần dùng?", rồi hệ thống gợi ý kỳ hạn phù hợp kèm số lãi dự kiến bằng tiền đồng cụ thể, và nói rõ điều kiện rút trước hạn ngay tại đó thay vì giấu trong điều khoản.
Bài học: Trong sản phẩm tài chính, minh bạch là tính năng, không phải nghĩa vụ pháp lý miễn cưỡng. Chuyển từ "hiển thị dữ liệu" sang "trả lời câu hỏi của người dùng" là bước nhảy về chất lượng UX.
Hướng dẫn từng bước
Đây là quy trình bạn có thể lặp lại cho bất kỳ dự án redesign nào, minh họa bằng case VietBank.
Bước 1 — Thu thập và định lượng vấn đề. Gom review trên App Store/Google Play, ticket chăm sóc khách hàng, và số liệu analytics. Nhóm than phiền thành chủ đề. Với case này, ba luồng transfer/bill pay/saving nổi lên rõ ràng, chiếm hơn 50% phàn nàn. Viết ra baseline cho từng luồng (completion rate, số bước, drop-off).
Bước 2 — Vẽ lại luồng hiện tại (current flow audit). Chụp từng màn của app cũ, ghép thành một sơ đồ luồng. Đánh dấu đỏ mỗi điểm gây ma sát: bước thừa, thuật ngữ khó, thông tin thiếu, thao tác dễ sai. Đây là "bản đồ vết thương".
Bước 3 — Xác định giả thuyết và mục tiêu. Với mỗi luồng, viết một câu: "Chúng tôi tin rằng [thay đổi] sẽ giúp [nhóm người dùng] đạt [mục tiêu], đo bằng [chỉ số]." Ví dụ: "Thêm tìm kiếm ngân hàng thụ hưởng sẽ giúp người chuyển tiền chọn nhanh hơn, đo bằng thời gian ở màn chọn ngân hàng."
Bước 4 — Phác thảo lo-fi và luồng mới. Dùng wireframe đơn giản để thử vài phương án luồng trước khi đụng tới màu và font. Ở giai đoạn này bạn tối ưu số bước và thứ tự thông tin, chưa tối ưu thẩm mỹ.
Bước 5 — Dựng hi-fi bằng design system. Giờ mới vào Figma nghiêm túc. Áp dụng mọi thứ đã học: auto layout cho các màn co giãn, component cho input và button, design token cho màu và spacing, typography scale cho phân cấp. Vì là banking, ưu tiên contrast đạt chuẩn accessibility và cỡ chạm (touch target) đủ lớn cho người lớn tuổi.
Bước 6 — Prototype và test rẻ. Bấm prototype các luồng chính, đưa cho 5–8 người thử (bao gồm cả người không rành công nghệ). Quan sát chỗ họ ngập ngừng. Sửa. Test lại.
Bước 7 — Chuẩn bị handoff. Dùng Dev Mode, thêm annotation cho các trạng thái (empty, loading, error của mỗi luồng), export asset, viết rõ điều kiện hiển thị. Một redesign banking phải mô tả kỹ trạng thái lỗi: OTP sai, hạn mức vượt, mất mạng giữa giao dịch.
Bước 8 — Đóng gói case study. Kể lại theo khung Bối cảnh → Vấn đề → Nghiên cứu → Giải pháp → Kết quả → Bài học. Đặt ảnh trước/sau cạnh nhau, kèm con số. Nêu cả những đánh đổi bạn đã cân nhắc.
Lỗi thường gặp & mẹo
Lỗi 1 — Redesign vì "thấy xấu" chứ không vì dữ liệu. Rất nhiều portfolio junior mở đầu bằng "Tôi thấy app này chưa đẹp nên làm lại". Người phỏng vấn sẽ hỏi ngay: "Bạn dựa vào đâu?" Luôn neo redesign vào vấn đề đo được.
Lỗi 2 — Chỉ khoe màn đẹp, giấu quá trình. Sáu screen bóng bẩy không kể được câu chuyện. Hãy cho thấy cả bản wireframe nháp, cả phương án bị loại và lý do. Quá trình mới là thứ chứng minh năng lực.
Lỗi 3 — Bỏ quên trạng thái phụ. Junior hay chỉ vẽ "happy path". Banking sống bằng edge case: giao dịch thất bại, số dư không đủ, phiên hết hạn, OTP quá thời gian. Không vẽ những màn này là handoff nửa vời.
Lỗi 4 — Đổi mới quá tay, phá thói quen người dùng. Với ngân hàng, người dùng quen đường đi cũ. Nếu bạn xáo trộn toàn bộ vị trí nút quen thuộc, bạn tạo ra confusion mới dù đẹp hơn. Redesign banking nên tiến hóa có kiểm soát, không cách mạng đột ngột.
Mẹo 1 — Luôn có bảng "trước / sau" bằng số. Một dòng "completion rate 68% → 84%" có sức thuyết phục hơn mười tính từ.
Mẹo 2 — Trung thực với kết quả. Nếu dự án là bài tập cá nhân chưa launch, hãy nói rõ đó là kết quả kỳ vọng dựa trên usability test, đừng bịa số liệu production. Sự trung thực làm case study đáng tin hơn.
Mẹo 3 — Nêu đánh đổi. "Tôi chọn gộp hai bước để nhanh hơn, đổi lại màn hình dày thông tin hơn; tôi cân bằng bằng cách dùng khoảng trắng và phân cấp." Câu này cho thấy bạn tư duy như một người ra quyết định.
Bài tập thực hành
- Chọn một app tài chính đang dùng (ví dụ app ngân hàng bạn có, hoặc MoMo/ZaloPay). Chọn đúng một luồng — chuyển tiền, thanh toán hóa đơn, hoặc gửi tiết kiệm.
- Audit luồng hiện tại. Chụp từng màn, ghép thành sơ đồ, đánh dấu đỏ mọi điểm ma sát. Viết ra baseline giả định của bạn (số bước, chỗ dễ nhầm).
- Viết giả thuyết. Một câu duy nhất theo mẫu ở Bước 3, kèm chỉ số bạn muốn cải thiện.
- Thiết kế luồng mới trong Figma. Dùng auto layout, component, và token. Bắt buộc vẽ đủ 4 trạng thái cho ít nhất một màn: mặc định, loading, thành công, và lỗi.
- Test rẻ. Đưa prototype cho 3 người quen (ưu tiên một người không rành công nghệ) thử. Ghi lại chỗ họ ngập ngừng.
- Đóng gói mini case study một trang theo khung sáu phần, có ảnh trước/sau và ít nhất một đánh đổi bạn đã cân nhắc.
Tóm tắt
Redesign một banking app là bài kiểm tra tổng hợp mọi kỹ năng UI: bạn phải bắt đầu từ vấn đề đo được, không từ cảm giác "thấy xấu"; coi ràng buộc pháp lý và bảo mật là khung sáng tạo chứ không phải rào cản; và tách ba luồng transfer, bill pay, saving thành ba bài toán bản chất khác nhau — tốc độ và an tâm, ghi nhớ và lặp lại, minh bạch và niềm tin.
Quy trình tám bước — từ định lượng vấn đề, audit luồng cũ, viết giả thuyết, phác thảo lo-fi, dựng hi-fi bằng design system, prototype test rẻ, chuẩn bị handoff, tới đóng gói case study — là bản đồ bạn lặp lại được cho mọi dự án. Ba ví dụ VietBank, GrabPay/MoMo, và Timo cho thấy cùng một nguyên tắc: thiết kế tốt là thiết kế trả lời đúng câu hỏi thật của người dùng, và chứng minh bằng con số trước–sau. Hãy làm bài tập, biến nó thành một case study tử tế, và bạn đã có sẵn miếng ghép mạnh nhất cho portfolio của mình.