US | Onboarding | 2026-09-06

Onboarding Flows That Keep New Users Past the First Session

Someone downloaded your app. You have about a minute before they decide whether to keep it. Here is what the first screens need to do, what they should not ask, and how to measure whether it is working.

The hardest part of launching an app is not getting the download. It is what happens in the ninety seconds after the icon appears on someone's home screen. Industry retention numbers vary by category, but the pattern is consistent: a large share of people who install an app never open it a second time, and the first session is where that decision gets made. For a small-business app, a booking tool, a loyalty program, a customer portal, that first session is the whole investment paying off or not.

Onboarding is the name for those first screens, and it is one of the most under-designed parts of most apps we see. This guide covers what onboarding is actually for, the patterns that work for the kind of apps small businesses commission, the requests that cause people to quit, and how to know whether yours is working after launch.

Onboarding has one job

The purpose of onboarding is to get a new user to the moment where the app is obviously useful to them, as fast as possible, with as little friction as possible. It is not to explain every feature. It is not to collect a complete profile. It is not to show a carousel of illustrated benefits that the user already read on the store listing.

For a booking app, the useful moment is seeing available times and picking one. For a loyalty app, it is seeing a reward they can actually earn. For a customer portal, it is seeing their own account or order. Everything in onboarding should be measured by whether it moves the user toward that moment or delays it.

A good exercise before any screens are designed: write one sentence that describes what the user should have done by the end of the first session. If you cannot write it, the app is not ready to be onboarded into, and that is a scoping problem rather than a design one. Our guide on scoping an MVP covers how to find that sentence.

Ask for as little as possible, as late as possible

The most common failure is the wall of requests. Create an account. Verify your email. Allow notifications. Allow location. Enter your name, phone, address, birthday. Pick your preferences. Then, finally, the app. Every one of those steps loses people, and most of them are not needed to reach the useful moment.

The principle is deferral. Ask for each thing at the point where it is needed and where the reason is obvious.

• Account creation: let people browse first. Ask them to sign up when they try to book, save, or pay, when the value of having an account is clear.
• Notifications: never on the first screen. Ask after they have booked something and have a reason to want a reminder. Our guide on push notifications that people do not mute goes into the timing.
• Location: only when they tap something that needs it, like "find the nearest location." Explain why in your own words before the system prompt appears.
• Profile details: collect what the first action needs and nothing more. A booking needs a name and a way to contact them. It does not need a birthday.

On iOS in particular, a permission prompt that the user denies is hard to recover from; they have to go to Settings to change it. Asking at the wrong moment does not just lose the permission, it loses it semi-permanently.

The patterns that work for business apps

Consumer apps with large teams can afford elaborate onboarding experiments. Small-business apps benefit from a few reliable patterns.

Value first, account second. Open directly into the useful screen with real content: today's availability, the current menu, the active promotion. Let people see what the app does before asking anything of them.

One question at a time. If you must collect something, one field per screen with a clear reason converts far better than a long form. It feels faster even when it is not.

Progress that ends. If there are three steps, show three steps and let people see the end. Open-ended onboarding with no visible finish is where people quit.

Skip everywhere. Every optional step needs a visible skip. Users who skip and come back later are far more valuable than users who leave.

Guest paths. For booking, ordering, and quote apps, a guest checkout that collects only the contact details needed for that one transaction, with an optional account at the end, routinely outperforms mandatory signup.

What to do with returning users

Onboarding is not only for the first session. Someone who installed the app, used it once, and came back a month later has forgotten how it works and may have a stale login. Design for that: remember what they did, put them back where the value is, and do not re-run the first-time carousel. If their session expired, make re-authentication one tap, ideally with the platform's sign-in options rather than a typed password.

The same applies after a major update. If the app has changed meaningfully, a single screen that says what is new and where to find it is fine. Five screens are not.

Measure it, or you are guessing

Onboarding is one of the few places in an app where the metrics are simple and the improvements are large. You need three numbers, all of which come from the analytics you set up before launch.

• Completion rate: of the people who opened the app for the first time, how many reached the useful moment. If this is low, find the screen where people drop and fix that screen.
• Time to value: how long the first session took to reach that moment. Shorter is almost always better.
• Day-one and day-seven return: how many first-session users came back the next day, and a week later. This is the number that tells you whether the onboarding actually worked, as opposed to merely being completed.

Track each onboarding screen as its own event so you can see the funnel. A funnel that loses half its users on the notification prompt tells you exactly what to change. A single "onboarding completed" event tells you nothing about why.

What to cut

A short list of things that show up in onboarding designs and almost never earn their place in a small-business app.

• Multi-screen welcome carousels that restate the store listing.
• Mandatory email verification before the first useful action.
• Preference surveys the app does not immediately use.
• Tutorials that walk through every tab. If a tab needs a tutorial, redesign the tab.
• A notifications prompt on launch.
• Social sign-in as the only option. Offer it, but also offer email, and on iOS offer Sign in with Apple if you offer any third-party sign-in at all.

How this fits into a build

When we scope an app, onboarding is designed alongside the core flow rather than added at the end, because the question "what does the first session need to accomplish" is the same question as "what is this app for." A white-label booking or loyalty app comes with an onboarding pattern already tested against real users, and a custom build gets the same treatment with the specifics of your business worked in.

Either way, the standard to hold is simple: a new user should be able to do the one thing your app exists for, in their first session, without being asked for anything they do not understand the reason for. Hit that, and the retention numbers take care of a lot of the marketing. If you want to talk through the first session of an app you are planning, get in touch. More launch and product guides are on the blog.