The First 60 Seconds: What I Changed in the Onboarding Screens

You spend months writing the app. The first time a user opens it, they spend about a minute looking for an answer to “what is this going to do for me,” and if they don't find one, they don't come back. Designing that one minute was the part I left until last for a long time, and the part that cost me the most.

In this post I'll walk through the decisions I made while building the first-launch flow — especially the ones I changed later, because those are the genuinely instructive ones.

The first thing I gave up: the intro carousel

In my early apps I built the classic setup: three screens, an illustration on each, a sentence underneath, and “Next” at the bottom. On the third screen, “Get started.”

The problem with these screens is that they don't do anything. The user taps “Next” three times, then lands in the real app, and what they see there doesn't line up exactly with what the carousel described. Instead of showing what you described, you end up describing what you're about to show.

The approach I prefer now is to drop the user straight into the app and give the explanation where it's actually needed. Showing how the map works while they're on the map screen, explaining filters while they're on the filter screen. The same information, but delivered at the moment they can see what it's for.

Sign-up: required or not

Asking someone to create an account the moment they open the app is the most common and most expensive decision. I decide based on one criterion: can the user see the app's value without creating an account?

• If they can, sign-up should be deferred. Let them browse, search, look around; only ask for an account when they need to do something personal (placing an order, saving, messaging).
• If they can't — if the app runs entirely on personal data anyway — sign-up can come first, but then the sign-up screen itself has to explain what the app does.

When I build deferred sign-up, the thing I watch for is that the work the user has done up to that point doesn't get lost. If they pick something, tap “save,” and get asked to create an account, that selection has to still be there after they sign up. Sending the user back to the start loses more people than the sign-up screen does.

Permissions: the most common mistake

Asking for location, notification and camera permissions back to back the instant the app opens is the quickest way to drive your grant rate down. The user is being asked for something before they know what the app does, so they decline by reflex. And on mobile platforms you usually can't ask again for a permission that was denied — you have to send the user to the system settings.

The order I use is this:

1. Don't ask at all until the action that requires it. Location permission isn't requested until the user taps the “show what's near me” button.
2. Show my own explanation before the system dialog. A dismissible card inside the app: “We'll use your location to show what's nearby. Your location isn't stored.” If the user taps “Continue” there, I open the system dialog.
3. Don't break the flow if it's denied. With no location, I continue by letting them pick a city. A user who declines a permission shouldn't become a user who can't use the app.

The benefit of the intermediate step in the second item is this: if the user says “not now” at that step, the system permission stays in the never asked state. That means you still have a chance to ask later. If you open the system dialog directly and get denied, you've spent that chance.

Empty states are part of onboarding too

Thinking of onboarding as “the intro screens” is a common way to narrow it down too far. In reality, every screen the user sees for the first time is part of onboarding — and most of them are empty: an order list with no orders, an inbox with no messages, favorites with nothing saved.

I split an empty state into three parts: one sentence explaining the situation, one sentence saying what can be done, and a button that does that thing. “You don't have any favorites yet. Tap the heart icon on products you like to add them here.” + a Browse products button.

The reason this works better than an onboarding carousel is that it lands at exactly the moment of need and in exactly the right place.

Data on first launch: sample or empty

In some apps, showing sample data on first launch works — the user gets to see the interface in its filled-in state. But presenting fake data as if it were real is risky: the user gets confused as soon as they tap it and try to do something.

My preference is to show real but generic content instead of sample data. For example, showing real listings from the nearest large city when there's no location permission. The user is looking at something real, the interface looks full, and how much difference personalization will make becomes obvious on its own.

How I measure it

Seeing where you lose people matters as much as designing the onboarding itself. What I look at is the share of users who move from each step in the flow to the next one. The step with the biggest drop is the first place to work on.

The critical distinction here: the drop may be because the step is hard, but more often it's because the step is unnecessary. Before I try to improve a step, the question I ask is always the same — what would I lose if I removed this step entirely? If the answer is “not much,” then removing it is the best improvement.

Summary

If I boil down what I've learned about the first-launch flow: show the app itself instead of an intro screen, defer sign-up until it's genuinely needed, tie permissions to an action and show your own explanation beforehand, turn empty states into prompts, and prefer cutting the number of steps over improving them.

The single idea behind all of it is the same: for a user to understand the app, they need to use it, not read about it.

• Mobile Development
• UX
• Product
• Design