Why I design onboarding backwards

The first onboarding flow I ever shipped had nine screens. Nine. A welcome screen, a value screen, three tutorial screens explaining icons that were already fairly obvious, a permissions screen, sign-up, email verification, and a bewildered “you’re all set” screen that tried, and failed, to be a confetti moment.

It tested fine in usability sessions. People understood it and could finish it. And almost half of them never came back.

That flow was designed forward. We built it screen by screen from the moment someone lands, each time asking “what should we tell them next?” That’s the wrong question. It almost always produces an explainer reel, which keen users skip and unsure users use as a reason to leave.

These days I do the opposite. I start at the moment the product clicks for someone, and walk backwards.

Name the moment it clicks

Product teams call this the activation moment: the first time someone gets real value from the product. Before I draw a single screen, I write one sentence: the user has activated when ___.

For a wishlist-led shopping app in 2023, it was: when they save their first product to a wishlist and come back within seven days. For a B2B reporting tool: when they share a report with a teammate. For a recipes app: when they cook a saved recipe and rate it.

I hold that sentence to a plain, unromantic standard. It has to be:

1. Visible in the data: something I can see happen, not guess at.
2. A sign of staying: closely linked to people coming back or spending, ideally both.
3. Reachable in one visit: if it isn’t, the job becomes “get them to come back”, which is a different and harder problem.

If the sentence fails any of these, I throw it out and try again. It’s worth a week if a week is what it takes. Everything else is built on it.

Working backwards strips things out

With the sentence in hand, I put it on the right of the page and work leftwards.

1. 1 Write the moment Put the activation sentence on the far right.
2. 2 Ask what comes just before What is the least someone must have done to be standing here?
3. 3 Draw that screen Place it to the left, then ask the same question again.
4. 4 Stop at the front door Keep going until you reach the point where people arrive.

What you end up with is almost always shorter than what you started with. Most things teams want in onboarding don’t actually help anyone reach that moment. Sign-up? Often not. Email verification? Almost never. The four-screen tutorial? Definitely not. Permission requests? Sometimes, but rarely all at once and rarely up front.

The question to keep asking: does this bring the user closer to the moment, or does it bring the team’s worries closer to the user? Most explainer screens are worry pointed outwards. The team fears people won’t understand, so they explain everything first. But explanation without context is just noise. People learn by doing, and onboarding is the cheapest chance you’ll ever get to let them.

The best onboarding flow I ever shipped had two screens before the activation moment. The second one was a search field.

An example: asking for sign-up later

Here’s the pattern I keep coming back to in online retail. Most apps ask for an account before people have done anything that makes handing over an email feel worth it. The sign-up wall appears before the value does. The drop-off is so consistent across the industry it might as well be a law.

On one project, my sentence was: the user has activated when they save their first product to a wishlist. So I worked backwards.

To save an item, you need a wishlist. To have a wishlist, you need somewhere to keep it. Traditionally, that’s an account. But “an account” is a technical detail dressed up as a product requirement. What you actually need is a way to recognise the same person again, and the phone itself can remember that, for this visit and beyond.

So we dropped up-front sign-up entirely. New users could browse, search, save to a wishlist and even add to bag without seeing a form. We first asked for an email when they tried something the phone couldn’t do alone: sync across devices, place an order, or get a price-drop alert.

Wishlist creation went up. Sign-ups went up too (by less, but still up) because we asked when people had a reason to say yes. The seven-day return rate, the number I actually cared about, rose by about a third.

The pushback, and my answers

I hear two objections most: “marketing needs the email” and “how will we know who’s coming back?” Both are fair, and both have answers.

Marketing does need emails, but not unmotivated ones. Emails collected at the moment of value convert better in every funnel I’ve looked at, often by an order of magnitude. A smaller list of engaged people is worth more than a bigger list of cold ones.

Tracking returning users is a real problem, but it’s a tooling problem, not a product one. An anonymous ID can be linked to a real account once someone signs up. Don’t let an analytics limitation shape your onboarding.

How I work now

When I sit down with a team, my first question isn’t “what do we want users to know?” It’s “what does activation look like, in one sentence we can see in the data?” If we can’t answer that, we don’t design onboarding yet. We find out first, through research and data, and come back when we know.

It feels slow. It saves months. The flows that come out are usually two or three screens shorter than the team first imagined, and they perform clearly better. They’re also easier to maintain, because there’s less to argue about. Every screen has to earn its place against the sentence. If it doesn’t, it goes.

The nine-screen tutorial sits in a folder somewhere. I keep it as a reminder. It taught me more than any of the flows that worked.