What makes an onboarding flow fail

Onboarding fails at the moment it asks the user for something it doesn't need yet.

That sounds obvious, but it's the source of most of the drop-off patterns I've seen in onboarding flows. The product needs an email address, so it asks for an email address. Then a password. Then a job title for "personalization." Then a profile photo. Then a company size. Each step feels reasonable to the person who designed it. Collectively, they tell the user that this product's needs come before theirs.

The promise isn't what you think it is

When someone signs up for a product, they've made a provisional decision. They're willing to give the product a few minutes to prove it's worth more time. Onboarding is how the product either delivers on that implicit promise or squanders it.

Most onboarding is designed to capture data and set up the product. That's a company goal, not a user goal. The user's goal is to understand whether the product does what they think it does, and to get some version of that value quickly. Any step in onboarding that doesn't serve that goal is friction.

The friction might be justified. Some setup is genuinely necessary. But it should be the minimum necessary, done in the right order. That order is almost always: let the user see something valuable first, then ask for what you need.

Why step-based flows go wrong

Step-based onboarding (screens 1, 2, 3 with a progress indicator) is so common it's become the default pattern for complex setups. It works reasonably well when the steps are short and the content is clearly related to the user's goal. It breaks down when the number of steps exceeds what can be done in a single sitting, when earlier steps require information the user doesn't have on hand, or when the user can't tell why any given step matters.

The progress indicator creates a specific problem: it makes the flow feel like a form. "You are 40% done" implies there's a 60% burden remaining. That's the opposite of what you want the user thinking on screen two.

The alternative isn't to remove the progress indicator. It's to design flows short enough that a progress indicator is reassuring rather than discouraging. If your onboarding has eight steps, the problem isn't the progress indicator. The problem is eight steps.

The "complete your profile" trap

A common approach is to do minimal setup at signup, then prompt users to "complete their profile" later. In theory, this defers friction. In practice, it defers the moment the user understands what the product actually does.

If the product genuinely requires configuration to function (a project management tool where you need to create a project before you can do anything, for instance), the onboarding can't defer that step. But it should defer everything else. Account preferences, notification settings, billing details, integrations: these can wait until the user has seen enough to want to stay.

The signal that a step should be deferred is whether the product can deliver some core value without it. If yes, defer it. If no, it belongs in onboarding, but it still needs to be explained rather than just requested.

What the modal says about the rest of the product

Products that launch a modal immediately after signup are making a structural argument: the first thing we need to do is interrupt you. Sometimes that's right. Often it's a holdover from an earlier version of the product that no one has questioned since.

Modals in onboarding are appropriate for things that genuinely can't wait: permission requests the OS requires before the product can function, critical warnings the user needs before they take any action, account security steps with meaningful consequences. They're not appropriate for upsells, tutorial offers, or newsletter subscriptions on screen one.

The test is simple. If the user would be frustrated to see this modal after having used the product for a month, they'll be frustrated to see it the first time they log in.

Empty states that abandon new users

Onboarding often ends when the account is created. Then the user lands on a dashboard, a projects list, or a home screen, and the product forgets they're new.

What happens next is one of the highest-drop-off moments in most products. The user is looking at an empty state. Maybe there's a button. Maybe there's a placeholder image. There's almost certainly not an explanation of what to actually do or why it will be worth doing.

New users and existing users experience the same screens differently. A dashboard that's meaningful to someone with six months of data is opaque to someone with none. Designing the post-onboarding experience as though all users have equivalent context is how products lose users after they've already done the work of acquiring them.

The fix isn't a product tour. Product tours get dismissed immediately. The fix is designing the empty states themselves to be instructive: specific about what should be here, clear about how to put something here, and honest about why it matters.

Asking for the wrong things at the wrong time

Notification permission is the clearest example of timing failure. Native apps routinely ask for push notification permission on first launch, before the user has seen anything that would make them want notifications. The opt-in rate for this approach is low. The opt-in rate for waiting until after the user has seen a concrete reason to stay informed is significantly higher.

This pattern shows up with other permissions too: location, contacts, camera. The user is almost always more willing to grant access after they've experienced the value that requires it, not before. Onboarding that asks for permissions upfront is asking the user to trust a product they haven't experienced yet. That's a hard ask.

The right time to request a permission is the moment the user would naturally encounter the feature that needs it. Not before. Requesting it before that moment collapses the distinction between "this feature needs access" and "this product wants data."

---

The onboarding flows I've seen work best are the ones built by people who timed themselves going through the flow as a new user and got uncomfortable. Something specific usually breaks that self-consciousness: a step that feels obviously unnecessary, a screen that's hard to understand, a moment where the mental model requires information you don't have. That discomfort is the most useful input the design process will get.