In-app onboarding design: how to welcome a new user

Step 1

Check whether you need onboarding at all

Nielsen Norman Group defines onboarding as the process of getting users familiar with a new interface through dedicated flows and UI elements. It covers not only teaching but also any necessary setup, and not only the first launch: existing users are onboarded too when new features or redesigns ship. At the same time, NN/g recommends avoiding separate onboarding whenever possible: it costs time and attention, strains memory and doesn't always improve performance. According to NN/g, onboarding is justified when:

• •you can't start without information from the person: for example, a bank needs to verify identity;
• •the app depends heavily on the person's context and preferences: for example, a diet app benefits from knowing their current weight;
• •the main feature is genuinely new and unusual, with no standard patterns for it.

💡 NN/g's advice: first test the app without onboarding. If people manage, you don't need it. If they don't, start by making the interface itself clearer.

Step 2

Break down what onboarding is made of

NN/g identifies three components that most often appear in mobile onboarding. Each has its own rule:

• •feature promotion (“what the app can do”): NN/g advises against showing it at first launch: the person has already downloaded the app, so these screens feel like marketing and get skipped. They belong on the app store page, or as a tip at the moment a feature becomes useful;
• •customization (language, interests, goals): ask only for what you can't start without. Apple recommends postponing nonessential setup and providing reasonable defaults so most people can start right away;
• •instructions (how to use it): the riskiest component. It's the next step.

Step 3

Teach by doing and in context, not with slides

Classic onboarding is a few slides of tips before you start. NN/g calls these push revelations: they appear with no link to what the person is doing right now. Such tutorials interrupt, are often skipped, and what they show is quickly forgotten. Apple advises the same: teach through interactivity and, instead of one long flow, offer context-specific tips. What to do instead of slides:

• •a tip next to the feature at the moment it's needed: NN/g calls these pull revelations;
• •a first action instead of an explanation: let the person do the main action right away on safe sample data;
• •if you need a separate tutorial, make it short and optional, and, per Apple, don't show it again once skipped, but keep it findable, for example in settings or help;
• •teach your app, not how to use the phone.

Step 4

Permissions, the account and empty screens

The first launch is when an app most often asks for things. The order of those asks is design too:

• •permissions: Android's documentation advises asking for a permission in context, when the person starts using the feature that needs it, not blocking them, and letting them cancel an explanatory screen. Apple adds: if the app can't work without a permission, explain in onboarding why it's needed and what the benefit is;
• •ratings and purchases: Apple recommends letting people experience the app before asking for a rating or a purchase;
• •the account: if you can show something before sign-up, show it. It's easier to agree once you've seen the value;
• •empty states: NN/g recommends using empty screens to explain what will appear, give learning cues and offer a direct button for the first action.

💡 Lay out the first launch on paper: each ask is a separate card. For each, ask yourself: “Could I ask for this later?” Move everything that gets a “yes” closer to the moment it's actually needed.

Step 5

Design the first launch and test it with newcomers

A portfolio exercise: pick an imaginary app, such as a habit tracker or an app for swapping books with neighbors, and design its first launch in Figma.

• •define one first useful action: the reason the person downloaded the app;
• •draw the path from launch to that action and count the steps. Every step that doesn't bring them closer is a candidate for removal or postponement;
• •make two versions: one with minimal onboarding and one with tips in context. Link them into a clickable prototype;
• •give the prototype to people who haven't seen your app and a task for the first action. Compare where they reached the goal faster and what they remembered.

💡 How to build a clickable prototype with transitions is covered in Prototyping in Figma. And show both versions of the onboarding in the community and ask which one people would enjoy more, and why.