Banking interfaces have to be calm and quick in the same session.
A customer checks a balance in three seconds and then makes a transfer they are slightly nervous about. Optimise only for speed and the nervous moment feels reckless; optimise only for reassurance and the routine moment feels slow.
There was a second problem underneath the first. Several teams were shipping in parallel, so the real deliverable was never going to be a set of screens — anything I designed once would be re-interpreted five times.
The deliverable was a system, not a redesign
If the bank's teams shared a vocabulary for states, spacing and behaviour, consistency would stop being something enforced in review and start being the default.
I looked at what people actually do in a session, not what the app offers.
Usage concentrates far more tightly than feature lists suggest. A small number of journeys accounted for the overwhelming majority of what customers came to do.
The rest of the app was competing for space with those journeys without being used.
Sessions are short and repetitive
Most visits were a single check or a single action. Anything that added a step to those paths was paying a cost on nearly every session in the product.
Confidence comes from orientation
Anxiety in the transfer flow came less from the money and more from not being certain what would happen next or how to get back.
Structure followed the org chart
The information architecture mirrored how the bank is organised internally, which is not how customers describe what they want to do.
Reassuring and fast are not opposites. They are both consequences of always knowing where you are.
Once that was clear, the two goals stopped competing. Orientation — clear state, predictable navigation, visible consequences — makes the routine journey quicker and the nervous one calmer at the same time.
It also gave the design system something to encode. The components carry the orientation rules, so every team gets them for free.
Two tracks: the journeys that matter, and the system that protects them.
The product track rebuilt the handful of paths that carry the product. The systems track turned those decisions into tokens, components and documented states so the next feature did not restart the argument about how a button behaves.
The core four, rebuilt
Balance, transfer, cards and payments designed to be unmistakably fast.
Each of these lost steps rather than gaining features. Defaults were set from actual behaviour, and confirmation was reserved for the moments that genuinely warrant a pause.
The transfer flow in particular shows its consequences before the commit rather than after, which is where the anxiety was concentrated.
A design system with states, not just components
The hard part of a component is what it does when things go wrong.
Every component was documented with its loading, empty, error and disabled behaviour, because those are the states that get invented inconsistently when they are left undefined.
Tokens covered colour, type, spacing and elevation, so a team could build a new screen that looked like the product without asking anyone.
Handover as part of the design
Design QA with the development partner, not a file thrown over a wall.
I worked through the build with the dev partner and reviewed the real thing in the browser and on device, which is where the gap between a design file and a shipped product actually lives.
The system outlived the engagement.
The core journeys were rebuilt around real usage rather than internal structure, and the design system gave the bank's teams a shared vocabulary they kept using after the consultancy ended.
That was the point. A redesign is a moment; a system is what keeps the product coherent through everything that gets built next.