Case study · Mobile banking · via BCG
Redesigning the mobile app of a leading Indian private bank — and what a year inside that engagement taught me about earning the right to disagree.
Built by another firm before us, it did what a banking app legally needs to do. But navigation was awkward, information went missing right when you needed it, and none of the flows matched the muscle memory people had already built on Google Pay and Paytm. The reviews complained about broken links. The real problem was quieter than that: nothing about the app made you feel in control of your own money.
The bank knew it too. They didn't arrive with a metrics deck or a problem statement — they arrived with a hunch that their app wasn't good enough, and a test to see whether we could do better.
The test was the add-money flow: a high-frequency journey customers touched every day. Get it right, and the door opens. Get it wrong, and the engagement ends politely.
I started from what already works. I'd used Google Pay and Paytm for years — same as every customer this bank was losing attention to. So instead of inventing a new interaction model, I borrowed the mental models people already trusted and rebuilt the flow on top of them. Familiarity isn't lazy in financial UX. It's the point. People moving money are anxious enough without having to learn your clever new pattern.
The client had asks of their own: preset amounts instead of manual entry, a few interaction tweaks — and one I disagreed with. They wanted their savings interest rate promoted hard, right inside the transfer flow.
You don't run ads in the middle of someone's money transfer.
I couldn't kill the promotion — that battle wasn't winnable. But I talked them down from making it the loudest thing on the screen. We shipped it present but restrained. A small win, and the first time the client took my reasoning over their instinct.
We delivered. The single test flow became fourteen journeys — onboarding, payments, savings, credit cards, mutual funds, spend tracking — picked by the client on usage and business priority, with our team of five owning the design end to end.
Money in, money out, not much else. We built exactly what they asked for — every spec, every preference honoured.
It died in review. And not with the client: inside BCG. Their own team looked at the mandated version and rejected it before it went anywhere. The thing about being told precisely what to design is that when it flops, the failure isn't yours to defend.
That rejection bought us room. The second version — the Personal Fund Manager — was what the feature should have been from the start: tag your spends, group them, see the month at a glance, actually understand where your money goes. Less balance ticker, more spending mirror.
Sometimes you win the argument by building the mandated version well — and letting it fail honestly.
You won't always get to make the case up front. Have the better answer ready for the moment the door opens.
Five designers, fourteen parallel flows, and the slow realisation that we'd built ten slightly different versions of the same button. Reviews kept stalling on questions we'd already answered. New designers kept reinventing components that already existed. So we stopped and systematised: locked the component library, wrote down the patterns, defined the language.
The expected payoff happened — faster builds, faster reviews. The unexpected one mattered more. This client had an endless appetite for "something different." The system became our guardrail: a principled way to say no to novelty for its own sake, and a faster way to say yes when different was genuinely justified. It managed the relationship as much as it managed the files.
We designed, validated with the client and BCG, and handed off — the post-launch numbers never came back to us. That's consulting. What I can show is the thing that's harder to fake: the engagement kept growing.
For work that started as an audition, the expansion was the metric.
Influence is earned slowly and spent carefully. I came into this engagement thinking my job was executing briefs well. I left understanding that the more valuable skill is earning the right to shape the brief — through delivery, through picking battles, and occasionally through letting a bad idea fail at its own pace.
A design system isn't housekeeping. Built at the right moment, it's leverage — for the team's speed, and for the client's appetite. That reframing, from deliverable to strategic tool, is something I now look for in every project.