Rebuilding trust in a bank's busiest screens

Overview

This is an unsolicited concept redesign — BRAC Bank was not a client. I chose it deliberately: redesigning a real bank's real app, with real constraints and a real customer base, is a harder and more honest exercise than inventing a fictional fintech. Every decision below had to survive the question "would a regulated bank actually ship this?"

The problem

Mobile banking apps are opened for a tiny set of high-frequency jobs: check a balance, move money, top up a phone, pay a bill. In the existing app, those jobs competed for attention with promotions, secondary products, and navigation that mirrored the bank's org chart instead of the customer's intent.

The cost of that clutter isn't aesthetic. In banking, every extra tap is a moment of doubt, and every ambiguous state — did that transfer go through? — is a small withdrawal from the trust account. Enough of those, and the customer walks into a branch instead. That's expensive for the bank and worse for the customer.

Business context

Bangladesh's banking sector has been digitizing at speed, with mobile-first customers leapfrogging desktop banking entirely. For a bank in that market, the app is the branch for a growing share of customers. The business case for this redesign was framed around three levers: reduce time-to-task for the top jobs, reduce failed or abandoned transactions caused by unclear states, and reduce the support load created by confusion the interface itself generates.

What research showed

I started with a heuristic evaluation of the live app against Nielsen's usability principles, then mapped the findings against informal conversations with people who bank on their phones. [EDIT: replace with your actual research — how many people you spoke to, what methods you used. If it was heuristic-only, say so; that's a legitimate method.]

Three pain patterns dominated:

1. The home screen worked for the bank, not the user. Frequent actions sat below promotional content; users scrolled past marketing to reach their own money.
2. Transfers created anxiety at exactly the wrong moment. Confirmation and success states were visually thin, so people screenshotted everything "just in case" — a workaround that is really a bug report.
3. Inconsistency taxed every screen. Buttons, icons, and list patterns varied across sections, so nothing learned on one screen transferred to the next.

Design principles

I wrote three principles and held every screen against them:

• Task first. The top four jobs are reachable in one tap from home. Everything else earns its place.
• Certainty at every step. Before, during, and after a transaction, the interface answers the question the user is silently asking.
• One system, everywhere. A component used once is a decision; used twice, it's a standard.

Key decisions

A home screen organized by frequency, not hierarchy. Balance on top, the four most-used actions as the first interactive row, recent activity directly beneath. Promotions moved into a dedicated, clearly labelled space — still present for the business, no longer in the customer's path.

A transfer flow built around confidence. Amount entry with clear fee disclosure before confirmation, a distinct review step that reads like a receipt, biometric confirmation, and a success state designed to be screenshotted — because users will do it anyway, so it should look like proof.

A token-based UI system. Type scale, spacing, color roles, and components documented so the redesign is a system, not a set of pretty screens. This is also what makes the concept plausible for a real bank: consistency is what large product teams actually buy.

Accessibility

Contrast checked to WCAG AA across text and interactive states; minimum 44px touch targets; error and success states distinguished by icon and text, never color alone. Financial products serve everyone — including users on low-end devices, in bright sunlight, with tired eyes at the end of a shift. [EDIT: add anything you did around Bangla language support or localization — it's a strong differentiator if true.]

Testing & iteration

[EDIT: this section is drafted assuming lightweight testing. Replace with what actually happened, even if small — "I tested the prototype with 5 people and watched 3 hesitate at the review step, so I…" is more credible than any large claim.] Early feedback on the transfer flow showed hesitation at the review step when the fee appeared for the first time — so fee disclosure moved earlier, into amount entry, where the decision is actually made.

Outcome

As a concept project, the honest outcomes are the quality of the reasoning and its public reception: the case study has drawn over 5,600 views and 350+ appreciations on Behance, with feedback from working designers in the fintech space. More importantly, it produced a repeatable point of view about transactional trust that I've carried into every project since.

What I'd do next

With access to real data, I'd validate the home-screen action set against actual usage analytics, run moderated testing on the transfer flow with first-time users, and pressure-test the design system against the bank's full product surface — loans, cards, statements — where concepts usually break.

Reflection

Redesigning a bank taught me that fintech design is emotional design wearing a suit. The craft isn't making finance beautiful — it's making people feel certain. That reframe now sits underneath everything I make.