Onboarding flows that convert for new apps

What onboarding is actually for

Onboarding has one job: get a new user from "I just signed up" to "this did something useful for me" with as little in between as possible. Everything else, the welcome tour, the profile questions, the feature highlights, is only worth including if it shortens that path.

Nielsen Norman Group splits onboarding into three components:

• Feature promotion: telling people what the app can do.
• Customisation: collecting information to tailor the experience.
• Instructions: teaching people how to use the interface.

Their guidance on mobile onboarding is blunt: skip it when you can. Onboarding adds interaction cost, asks people to remember things out of context, and in their research, deck-of-cards tutorials did not improve task performance. They recommend testing the app without onboarding first, fixing the interface where people struggle, and only adding onboarding when a prototype shows it helps.

That runs against what most AI builders produce when you ask for "an onboarding flow": a three-slide welcome carousel with an illustration on each slide, followed by a long form. It looks like onboarding. It mostly delays the user.

The four parts of a new app's first run

For a typical SaaS or marketplace MVP, the first run has four moments. Each has a version that helps and a version that gets in the way.

1. Sign-up

Ask for the minimum needed to create an account. Name, company size and role can wait until you have a reason to ask.

Make sign-in easy to get right. WCAG 2.2 added success criterion 3.3.8, Accessible Authentication (Minimum), at level AA. It says an authentication step should not rely on a cognitive function test, such as remembering a password, unless there is an alternative or a mechanism to help. The W3C's Understanding document lists the practical ways to meet it: let password managers fill the fields, allow copy and paste, or offer email link sign-in, a third-party provider using OAuth, or WebAuthn. Blocking paste into a password field fails it.

Correct autocomplete values help password managers and browsers fill the form, and they also meet success criterion 1.3.5, Identify Input Purpose:

// app/(auth)/sign-up/page.tsx
import { signUp } from "./actions"
 
export default function SignUpPage() {
  return (
    <form action={signUp} className="grid gap-4">
      <div className="grid gap-1.5">
        <label htmlFor="email" className="text-sm font-medium">Work email</label>
        <input id="email" name="email" type="email" autoComplete="email" required />
      </div>
      <div className="grid gap-1.5">
        <label htmlFor="password" className="text-sm font-medium">Password</label>
        <input id="password" name="password" type="password" autoComplete="new-password" minLength={12} required />
        <p className="text-sm text-muted-foreground">At least 12 characters. Your password manager can create one.</p>
      </div>
      <button type="submit">Create account</button>
    </form>
  )
}

Use autoComplete="current-password" on the sign-in form instead. It is a small detail, and it is one AI-generated forms often leave out.

2. Setup

Some apps cannot do anything useful until they know something: a budgeting app needs an account to connect, a scheduling tool needs working hours. NN/g's guidance is that customisation belongs in onboarding when the app depends on it, should be brief, should explain why each piece of information is needed, and should be skippable where it can be.

What does not belong here: choosing a colour theme, writing a bio, inviting the team before there is anything to show them. People cannot judge those choices before using the product.

3. The first screen

This is where most new apps lose people. After sign-up and setup, the user lands on the main screen, and the main screen is empty because they have not created anything yet.

An empty screen is the best onboarding surface you have, because it is exactly where the user is and exactly when they need to know what to do. NN/g's guidelines for empty states say to communicate what is happening, teach what the area is for, and give a direct path to the key task. Their examples include an alerts panel with a Create button and a Learn more link, and a logging product that offers either adding a real source or exploring with demo data.

That second option, sample data, is worth considering for any product where the value is hard to picture until there is content. A dashboard full of realistic example numbers shows what the product is for in a way no tour can. Label it clearly as sample data and make it easy to clear.

The code for designing these screens properly is in empty states, errors and loading states AI forgets.

4. Help in context

NN/g's work on onboarding tutorials and contextual help draws a line between "push" help, which appears regardless of what the user is doing, and "pull" help, triggered by a sign that the user needs it now. Tutorials at sign-up are push help: people skip them, and they forget what they saw. The paradox of the active user, in NN/g's terms, is that people want to start working immediately and treat any learning beforehand as an obstacle.

So put help where the feature is. A short hint the first time someone opens the invoice editor. A one-line explanation next to an unfamiliar setting. A persistent help or "What's new" menu where they can find it again later. Skip explanations of standard patterns entirely: nobody needs a tooltip telling them the gear icon means settings.

Patterns compared

How to tell if it works

I cannot give you a benchmark activation rate that applies to your product, and you should be wary of anyone who does. The useful number is your own, and it needs three things:

1. An activation event. The action that shows a user got value. For an invoicing tool, the first invoice sent. For a marketplace vendor, the first listing published. Pick one.
2. A funnel from sign-up to that event. Track each step in between: account created, setup completed, first item created, activation event. The step with the biggest drop is where to look first.
3. A few real sessions. Numbers tell you where people stop. Watching five people sign up tells you why.

The setup for tracking this is in analytics for your MVP. Change one thing at a time and watch the same funnel.

Where onboarding starts before sign-up

The first part of onboarding happens on your landing page. If the page makes it clear what the product does and who it is for, the people who sign up arrive with the right expectations, and the first run has less explaining to do. Feature promotion, the thing NN/g says to avoid at first launch, belongs there instead. Landing pages for AI-built products that convert covers that half.

When to get help

Onboarding is where product design and the build meet most closely: which questions to ask depends on the data model, and what the first screen shows depends on what the product can do with no data. That is the kind of decision I make in the same pass as the code, because I design and build. You can see how I designed for visitors, vendors and hosts in one marketplace on FindPopups, and the design guide for AI-built apps puts onboarding in context with the rest of the product.