Most banking apps look fantastic when the balance is healthy. Sunlit gradients. Confetti for rounding up. Little fireworks when you tap “paid”. Then the number hits £0 (or worse), and the polish falls off. Tricky language, greyed‑out buttons, pop‑ups with moral undertones. The UI that was keen to celebrate a £3 cashback suddenly becomes shy about fees, holds, and deadlines.
This is where banking app UX actually earns its keep: on bad days, not good ones. If we design the awkward states first, the rest follows. If we design the party and wing the hangover, we teach users to distrust the product when they need it most.
Bad days aren’t edge cases; they’re the product. Design them first.
What £0 really looks like (to a human)
Design for these four forces explicitly, or they’ll design the experience for you.
- Ambiguity: “Why is the payment pending?” “Why did the balance jump?” “Where did the refund go?”
- Time pressure: rent due Friday, salary on Monday; a weekend sits in the middle like a trapdoor.
- Fear of penalty: fees, interest, collections, credit score damage — usually explained after the damage.
- Shame: the quiet dread of opening the app and being told off by a tone‑deaf pop‑up.
Design’s job is not to cheer any of this up. It’s to reduce fear by making outcomes legible, options obvious, and next actions quick.
Dignity at zero (banking app UX in public)
Treat £0 as a state, not a warning. The empty state isn’t a blank. It’s a message from the bank. Make it a professional one:
Say the number plainly.
“Available £0.00 • Pending £42.17.”
No euphemisms, no hide‑and‑seek in three menus.
Name what will happen next (and when).
“Two payments scheduled for Monday. You can pause one.”
Offer one dignified action.
“Prioritise payments” or “See hardship options.”
No scolding.
Ban language that implies failure (“Uh‑oh”, “Oops”, “Looks like you overspent”).
A calm empty state is product reassurance. It tells people they’re still welcome here.
Negative balances without theatre
Overdraft UX is where some teams role‑play as moral philosophers. Don’t. Be exact.
Separate ledger states:
Initiated > Pending > Settled. Show the bounds of the overdraft and what happens if a pending item settles first.
Fees explained at the moment of risk, not after:
“This payment would incur £x today. You can:
– pay now and accept the fee
– schedule for Monday (no fee)
– use your arranged overdraft (remaining £/y).”
Receipts that behave like evidence:
Every fee has a line in the feed with a plain description and a link to the rule, not a FAQ safari.
Clarity isn’t kindness; it’s legality and trust. That’s banking app UX design in grown‑up mode.
Hardship flows: quick, private, reversible
Help is a flow, not a phone number. If your “help” route starts with a phone queue at lunchtime, you don’t have help — you have PR. In‑app hardship should:
- Start from the empty/negative state. No hunt through “More”.
- Offer a short menu of realistic options. Payment pause, interest freeze, temporary limit increase, human review call‑back.
- Capture context once. Amount, due dates, income dates — the things a human will ask.
- Give an instant interim outcome. “You won’t be charged fees for 72 hours while we review.”
- Leave a trace. A dated entry in the feed so the user has proof if policy forgets later.
Privacy matters: neutral language, no “hardship” banner that announces itself on shared screens.
Payment prioritisation (design the queue, not the guilt)
When money is scarce, the UI must explain consequences, not assign blame. When there’s not enough to cover everything, the product should help people decide which thing to pay, and what happens if they don’t. Make it explicit:
- Sort by consequence, not alphabet.
Rent and utilities at the top; discretionary at the bottom. - Explain the trade‑off inline.
“Pause gym (no fee). Pay council tax (avoids £x penalty).” - One‑tap re‑order.
A drag handle or up/down arrows that immediately show the new projected balance and fee exposure. - A “why” link that uses English.
One sentence per item.
No legalese.
You are designing decisions under pressure. Fewer taps, more truth.
Fees shouldn’t be a scavenger hunt
If a tap can trigger a fee, the warning belongs on that tap. Again, if a fee is possible, the screen that triggers it must say so — at the tap that triggers it.
- Before: “Transfer will complete Monday. Paying today costs £x.”
- After: “£x overdraft fee charged (rule link).”
- Never: a polite monthly statement with an asterisked mystery.
And stop burying fee rules in PDFs. Convert the policy to a page that loads fast on 3G and links from the place it matters.
Credit‑build nudges without shame
When a balance is often near zero, suggestions should feel like options, not judgement.
- Offer the smallest helpful step. “Set a £50 buffer alert.” “Report rent to credit file.” “Build a 3‑month history with a £200 secured card.”
- Explain the risk in the same breath. “This may increase your credit utilisation and can lower your score short‑term.”
- Never celebrate debt. Confetti for borrowing is tone‑deaf. A tick for on‑time payments is enough.
Real help is specific and boring. That’s fine.
Notifications are part of the ledger
Push and email aren’t marketing — they’re evidence. Treat them like part of the account history.
- No “you might like” during hardship. Switch to essential signals only.
- Every alert reconciles with the feed. Tap → takes you to the exact transaction state.
- ETA ranges, not fake clocks. “Expected Monday 09:00–12:00” is less pretty than a spinner, and far more useful.
In mobile banking app UX UI, certainty beats theatre.
The metrics that actually matter
- Time to certainty: from payment → “settled/failed” with an explanation.
- Fee visibility rate: % of fee‑eligible taps that showed a pre‑tap warning.
- Hardship access time: from zero state → help confirmation.
- Reversal/waiver satisfaction: a human reads these. The comments are the roadmap.
If these numbers go up, your NPS can take care of itself.
Tone guidelines (the shortest style guide you’ll ever need)
- Neutral, not chirpy.
- Specific, not motivational.
- Outcomes, not adjectives.
- Options, not lectures.
If a line would embarrass you to read aloud to someone having a bad month, rewrite it.
Bad days are not edge cases. They are the proof of concept. Real banking app UX plans for empty, negative, and awkward states first; party graphics later. If your roadmap doesn’t have room for this work, your users will make room for another app.
Real banking app UX design is simple: fewer surprises, faster truth, and options that respect people. The rest is decoration.
If you want a second pair of eyes on your empty/negative states, send a couple of screenshots. Happy to point out the sharp edges, politely.