I spent nearly an hour trying to log into a banking app last week. My bank of almost 25 years had redesigned their app and web presence into a “mobile first” experience.

Mind you, I wasn’t a new customer trying to open an account. I was just trying log in to an account I already had. Somewhere between the third verification code that expired and the password reset that required me to confirm my identity through a method I hadn’t set up yet, I started wondering whether I wanted to stay with this bank at all. I rely 100% on their technology tools because I’m thousands of miles away from the nearest branch–their app is my lifeline to paying my bills.

I wasn’t angry about security. I understand why financial apps require verification. What I was experiencing was a security implementation that had clearly been designed by people who never had to use it. Every friction point felt like it had been added by a different team at a different time, with no one accountable for what the whole sequence felt like to an actual human.

That’s the thing about bad onboarding: it doesn’t just lose you a session. It changes how customers think about your product.

First Impressions Compound

The research on this is pretty clear. UserGuiding’s 2025 analysis found that 72% of users abandon apps during onboarding if it requires too many steps, and up to 75% of users abandon a product entirely within the first week when onboarding is poor. Those numbers track with what’s observable in most consumer products—but they understate the harder-to-measure damage, which is the cost to trust.

With a bank specifically, the context is even more loaded. I’m evaluating security and ease of use simultaneously and they’re reading off the same experience. A clunky verification flow doesn’t just frustrate me; it signals something about how the organization thinks about its customers. That signal sticks.

I wrote last year about getting to delight in 15 seconds and the idea that the window for earning a user’s confidence is narrow and shrinking. What the bank experience clarified for me is that speed is only part of the problem. The harder failure mode isn’t slow onboarding. It’s onboarding that nobody owns end-to-end.

I spent time in a previous product building out a financial onboarding experience and the tension between compliance requirements and user experience was real. The compliance team’s job was to be certain the identity verification worked. The product team’s job was to make certain the experience didn’t lose the customer in the process. Those goals aren’t opposed, but they require deliberate design work to hold together. When that work doesn’t happen, you get what I experienced: a verification process that was technically functional and humanly exhausting.

The Product Signal in a Bad Signup

What I was reading in those frustrating minutes wasn’t just a bad UX. It was an organizational signal. Products that require lengthy, fragmented onboarding usually got there through accumulation rather than design, with each team adding their piece without anyone owning the total experience.

That’s a structural problem, not a design problem. No amount of UI polish fixes a signup flow where identity verification, account linking, and security setup each have separate owners with separate roadmaps and no shared accountable metric.

The banks and fintech products that get this right tend to have someone accountable for the end-to-end journey, not just the component pieces. That role exists to ask: “If a new customer had to complete this sequence today, what would they experience?” And then actually complete it and report back.

I’ve never worked somewhere that was good at this without someone explicitly owning it. It doesn’t self-organize.

What Good Onboarding Is Actually Doing

The goal of first-time user experience isn’t just completion. It’s the formation of the mental model a user will carry for the rest of their relationship with your product.

Users who struggle through onboarding don’t just abandon at higher rates–they use products differently afterward. They’re more likely to have reduced expectations, to seek workarounds, to avoid features that seem risky or complex. The first impression isn’t just the moment of acquisition; it shapes the usage pattern that follows.

Products with a clear “quick win” in onboarding retain users at significantly higher rates than those that front-load complexity. That’s well-documented and fairly intuitive. What’s less intuitive is that the quick win needs to be meaningful—something that demonstrates genuine product value, not just successful form completion. Getting through a signup screen isn’t a win. Getting to a useful state is.

The Connection to Product Perception

The banking situation is a specific case of a broader pattern. The apps and products that lose customers at first contact are usually the ones where product experience accountability stops at acquisition. Someone owns the conversion metric—getting the user to sign up. Nobody owns the experience after signup.

Retention metrics help, but they’re lagged and aggregated. What’s missing is human accountability: someone who regularly asks “what did our users experience this week?” with enough specificity to act on it. Not a survey with an NPS score, but someone watching sessions, reading support tickets, completing the flow themselves.

I had an opportunity to reach out to the bank in my example and share feedback. An advantage, I guess, of being a customer longer than a few of them on the team have been alive. Surprisingly, they were receptive to the feedback and lamented that some of it was due to outsourcing the entire security flow to ’experts’ that they simply plugged in. That’s led to some ’new tech/new problems’ and a lingering technical debt issue. I know that feeling and have lived it, so I can empathize, but I still hate to see it.

As a customer, I appreciate that they were open to hearing feedback. As a technical product leader, I wish they had someone on the team whose job was to be the voice of the customer in that moment and advocate for the experience they had. The fact that they didn’t have that role meant that the experience they designed was one that nobody on their team had actually lived through, and it showed.