The Problem
Two data sources pointed the same way. Product analytics showed where end customers were failing: task abandonment concentrated in two flows, fund transfers and account overview. Eight months of support-ticket verbatims told the same story from the customer's side: the same two flows, plus repeated complaints about web-and-mobile inconsistency. When behavioural data and support data independently surface the same failure points, you stop guessing where the problem is. There are two user groups in play, and the distinction matters. The end customers are consumers using the app to move money and manage accounts, they're who I designed for. But the buyers are the commercial banks, whose operations teams, product managers, and branch staff live with the platform on behalf of their customers. For the banks, end-customer friction isn't an inconvenience, it's what turns into a reason to switch vendors at contract renewal. Fixing the customer experience was how I fixed the bank's reason to leave.
Navigation was fragmented. The mobile product felt bolted on rather than designed, and the inconsistency between web and mobile eroded customer trust session to session — which, for a white-labelled product, is the bank's trust too. Every failed transfer or confusing screen was a customer losing confidence in their bank, not in Qore, which is exactly why it surfaced at renewal.
Leadership accepted the argument. My mandate: scope what was fixable in one product cycle and ship something that moved retention before the next board review. That framing mattered. It meant every decision in the following 16 weeks had to answer the same question: does this reduce churn, or doesn't it?
Constraints
Sixteen weeks. Two years of inconsistent components had left engineering building one-off solutions for recurring patterns, without a production system adapted to Qore's banking needs. A dev team had strong opinions about what was too risky to change. A PM wanted to ship everything. Stakeholders kept adding scope, and user research was two years out of date. The design strategy had to work within those constraints.
My Role
I owned the design strategy, information architecture, and component architecture decisions. I directed two mid-level designers across the dashboard and transaction flows, setting direction, running critiques, and making scope calls when we were behind. Research synthesis and stakeholder readouts were mine. The PM owned the roadmap; I influenced it. The third designer handled mobile adaptation; I reviewed and aligned it but didn't execute it.
Research, What We Found and What We Cut
I had two strong signals and used them against each other. Product analytics told me where users dropped off; the support tickets told me why: the frustration, the confusion, the exact language customers used. I leaned on the eight-month ticket dataset for depth because it was large, longitudinal, and free of recruitment bias, but I used the analytics to confirm the tickets reflected the most common failures, not just the loudest customers. The two cross-checked each other, which is why I trusted the conclusion enough to scope the whole redesign around those two flows.
What the data showed was that customer confusion wasn't spread evenly across the platform. It clustered around two flows, fund transfers and account overview, and around the gap between what mobile and web promised. End customers weren't struggling with the full product. They were failing repeatedly in the same two places, then raising support tickets with their bank or abandoning the task entirely. At contract renewal, that accumulated friction became the bank's conversation with Qore.
The PM wanted to add bill payments and savings goals in the same sprint. I pushed back, not because those weren't valid problems, but because splitting three designers across five flows in 16 weeks was a reliable way to ship nothing well. We held the scope.
Information Architecture
The old navigation was a single long list: every feature surfaced at the same level, with no hierarchy and no primary path. The two flows customers used most, transfers and account overview, had no more prominence than features they touched once a year.
The redesign restructured the IA around those two flows, surfacing them as top-level entry points directly from the Home Screen. Average steps-to-task-completion dropped from 4.2 to 2.6 in testing.
Flat feature list
Every feature had equal weight, while frequent tasks were buried.
Two flows drove abandonment
Analytics and support tickets pointed to transfers and account overview.
Prioritized hierarchy
The highest-frequency flows became top-level entry points, reducing average steps from 4.2 to 2.6.
- 01Highest-frequency tasks moved to the top level after analytics and support data identified the same abandonment points.
- 02A shared hierarchy across web and mobile reduced the trust cost of switching devices.
Key Decisions
Decision 1: Design for a specific user job, not a generic account view
We scoped to personal banking operators for v1, the highest-volume user type and the one with the clearest data signal. The priority for that user was spending visibility and transaction status. That singular focus shaped the entire dashboard hierarchy.
How far the adaptation went
I established Qore's first production design system by adapting a tokenized foundation into banking-specific components, patterns, and standards used across Qore and Pryme. I remapped the foundation to Qore's brand language, then extended it with transaction states, balance components, fraud and payment alert hierarchies, and goal-tracking modules.
Decision 3: Mobile breakpoints before desktop layouts
We defined mobile constraints before designing the desktop experience, a deliberate inversion of how the team had always worked. It meant some desktop features had to be descoped because they had no viable mobile pattern. That created friction with product. I held the line because designing desktop-first and adapting down was exactly how the previous product had ended up with a mobile experience that felt like an afterthought. Mobile usage increased 42% post-launch.
Sign In, the First Screen Every Bank Is Judged On
Because the platform is white-labelled, sign in is the first surface a bank's customers meet and the first place the bank's own credibility is on the line. It also carries a structural requirement no consumer banking app has: a customer belongs to a specific institution, so the flow has to establish which bank they are signing into before it can authenticate them at all.
I resolved that with an institution code field placed above the credentials rather than behind a bank picker, so the tenant is set in the same pass as the login without adding a screen. Account officers, who sign in against a different permission set, get a separate entry point below the primary action instead of a role toggle that every customer would have to read past. The left panel is a brandable slot: banks swap the imagery and mark, and the form column stays fixed so the layout stays predictable across deployments.
- 01Balance, recent activity, and transaction status form the primary hierarchy around the most common customer jobs.
- 02Banking-specific states reuse the shared system while preserving each institution's brand layer.
Results
Measured at 90 days post-launch against the prior 90-day period.
The results sit at two levels. Task completion in the highest-abandonment flows improved 37%, with the fund transfer flow tested against the prior design. That is the measure I attribute most directly to the experience work. The redesigned experience was one part of a broader product turnaround during which annual client churn moved from 17% to 14% and monthly active users increased 67%. Renewals and engagement also depend on pricing, account management, service levels, and product delivery, so I do not attribute those business results to design alone.
The churn and task completion numbers are the ones that mattered. Customers could find what they needed faster, and the dashboard surfaced what people actually needed to see. Those experience improvements addressed one of the major sources of customer friction during the broader retention turnaround.
Reflection
The most important decision wasn't a screen. It was narrowing the intervention. A full rebuild would have consumed more than a year while postponing improvements customers already needed. By identifying the workflows responsible for the most friction, we could improve the product sooner while creating a system that made future work faster.
The project reinforced a principle I now bring to complex platforms: the most ambitious solution is not always the largest one. Good product design often means finding the smallest structural change capable of producing meaningful leverage.
