7 App Onboarding Best Practices (and What Duolingo Gets Right)
Why a longer onboarding flow can sometimes work better than a shorter one, and what I look for when designing first-time app experiences.
Whenever I look at an app’s onboarding, one of the first things I notice is how quickly it tries to get me to sign up.
Some apps ask for an email address before you’ve even seen what they do. Others walk you through three or four beautiful screens explaining their features, only to drop you into an empty dashboard.
And then there’s Duolingo.
You open the app, pick a language, answer a few questions, and start learning. You translate a word, get something right, make a mistake, and try again.
By the time Duolingo asks you to create an account, you’ve already completed a lesson.
Depending on the onboarding path, you might have gone through dozens of screens. But it doesn’t really feel like onboarding. It feels like you’ve started learning a language.
I think this is what makes Duolingo such an interesting example of app onboarding.
Most onboarding advice focuses on reducing friction by removing steps. Keep it short, make signup easy, and get people to the main screen as quickly as possible.
That’s not necessarily bad advice, but I don’t think screen count tells us much about whether an onboarding flow is actually good.
You can have five screens that feel exhausting and thirty that feel surprisingly easy.
What matters is what the user is doing during those screens.
Here are a few things I’ve taken from looking at onboarding flows and thinking about how I’d design them in my own products.
1. Start With What the User Came to Do
When designing an app, it’s tempting to start with the welcome screen.
You open Figma, create a few mobile frames, add a headline, maybe an illustration, and then a button that says “Get Started.”
I’ve found it more useful to think about what happens after all of that.
What did someone actually download the app to do?
If it’s a fitness app, they probably want to start working out, not read about all the workout plans.
If it’s a budgeting app, they want to understand their spending.
And if it’s an AI writing tool, they probably want to see whether it can write something useful.
Take Hookquill, an AI scriptwriting product I’ve been working on, as an example.
There are plenty of things we could ask a creator during onboarding. What kind of videos do they make? Who’s their audience? What’s their preferred writing style? How long are their videos?
Some of that information could be useful. But I wouldn’t want the first experience to feel like filling out a questionnaire.
I’d rather help someone enter a video idea, generate an initial script, and see what the product can actually do.
Once they’ve seen a result, asking about their writing preferences makes much more sense.
That’s the part I like about Duolingo. It doesn’t spend the first ten screens convincing you that learning a language is fun.
It lets you try.
Of course, this won’t work exactly the same way for every product. A banking app has legal and security requirements that an AI writing tool doesn’t.
But the question is still useful: How much of the product can someone experience before we ask them to commit?
2. If You’re Going to Ask Questions, Make the Answers Matter
Personalization is something I really like in onboarding, especially when it’s done well.
But there’s a difference between making an experience personal and just collecting information.
Imagine opening a language-learning app.
It asks why you’re learning English. You select “Work and client meetings.”
Then it asks how much time you can spend practicing. You choose 15 minutes a day.
You finish the setup, open the app, and see the same generic lessons everyone else gets.
What was the point of those questions?
Now imagine the same onboarding, except the app immediately prepares a 15-minute lesson around speaking confidently in meetings.
That’s a much better experience. You can see that your answers changed something.
Headspace is a useful example to look at here. Its onboarding lets people select the goals they’re interested in, rather than assuming everyone comes to the app for the same reason.
Speak also connects the user’s reason for learning a language to the outcome they’re working toward.
When I’m thinking through questions for an onboarding flow, I like to ask what we’re actually going to do with each answer.
If the user selects a goal, does the next screen change?
If they choose a preference, will the app remember it?
If they tell us they’re a beginner, are we giving them a different starting point from an experienced user?
If the answer is no, maybe that question doesn’t need to be there yet.
Another small thing: not every question needs its own screen.
Sometimes a single screen with three quick selections is easier than making someone tap Continue three separate times.
I wouldn’t force everything into fewer screens, though. Some questions genuinely need more explanation or space.
The important thing is that people understand why they’re being asked.
3. Make the Small Interactions Worth Paying Attention To
One thing Duolingo does particularly well is make ordinary interactions feel satisfying.
You select an answer and immediately know whether you got it right.
The progress bar moves. You hear feedback. The next question appears.
Nothing particularly complicated is happening, but you’re constantly doing something.
Compare that with an onboarding flow where every screen has a paragraph explaining a feature and a Continue button underneath.
After a while, you’re not even reading. You’re just tapping through until the app finally lets you in.
This is something I try to pay attention to when laying out app flows.
It’s easy to design how a screen looks in Figma. The more interesting part is what happens when someone interacts with it.
Say the user is choosing their interests.
Does the selection respond immediately? Can they select more than one? Is it obvious what they’ve picked? Can they change their mind?
Or imagine an app generating a personalized plan.
A loading screen that simply says “Please wait” doesn’t tell the user much.
A screen that explains what’s being prepared, and then actually shows the result, gives that waiting time some context.
Small details like these change how an app feels.
I also don’t think everything needs an animation.
Sometimes designers go too far with transitions, confetti, and elaborate loading states. It looks impressive in a prototype, but using it repeatedly can become annoying.
A quick response to a tap, clear feedback, and a smooth transition can be enough.
The goal is to make the interaction easy to understand, not to turn every button into an event.
4. Think About When You Ask Users to Sign Up or Pay
This is probably my favorite part of Duolingo’s onboarding.
Get Xermio’s stories in your inbox
Join Medium for free to get updates from this writer.
It doesn’t ask you to create an account just because you opened the app.
You first make progress, and then it gives you a way to save that progress.
The signup screen now has a purpose.
I think a similar idea applies to notification permissions and paywalls.
I’ve opened plenty of apps that immediately ask me to enable notifications, even though I haven’t done anything that would require a notification.
Why would I say yes when I don’t even know what the app is going to send?
Compare that with a learning app that asks about reminders after you’ve created a daily practice schedule.
Now the request makes sense.
Brilliant is an interesting example of this approach. It uses a contextual screen to explain the benefit of learning reminders before asking for notification permission.
Paywalls need similar thought.
I’m not against showing a subscription offer during onboarding. For some apps, that’s part of the business model.
But I would rather connect the offer to something the person has already experienced.
If you ask someone to pay before they’ve seen anything useful, all they have to judge is your marketing.
If they’ve already generated a script, completed a lesson, or seen a plan tailored to their goals, they have a better idea of what they’re paying for.
That doesn’t mean every product should offer a free trial or delay payment indefinitely.
It just means the timing of the ask is as important as how the paywall looks.
You can have a beautifully designed subscription screen, with perfect typography and a great illustration, and still show it at completely the wrong moment.
5. The First Screen After Onboarding Matters Just as Much
This is the part I think gets overlooked.
Imagine spending a few minutes setting up an app.
You select your goals, choose your preferences, and finish the onboarding.
The app congratulates you.
“You’re all set!”
You tap Continue and arrive at an empty dashboard with a button that says “Create New.”
Now you have to figure out what to do.
I always find that a little disappointing.
The product spent several screens learning about you, but none of that seems to have helped you get started.
I prefer onboarding that leaves people with something useful.
For a learning app, that could be a recommended first lesson.
For a fitness app, it might be a workout plan based on the goals you selected.
For a project management app, it could be a starter project with a few example tasks so you can understand how things work.
I think about this in terms of the first-time experience as a whole.
The welcome screens might look great, but what does the actual product look like when there’s no data yet?
Is the dashboard completely empty?
Are there useful examples?
Can someone figure out the next action without opening a tutorial?
Sometimes I think we spend too much time polishing onboarding illustrations and not enough time designing the empty states people see immediately afterward.
And those empty states are often where the real experience begins.
6. Not Every App Needs a Long Onboarding
After looking at Duolingo, it’s easy to come away thinking that longer onboarding is somehow better.
I don’t think that’s the lesson.
Some apps barely need onboarding at all.
Take a simple email verification tool. If someone visits the website to check whether an email address is disposable, the most useful thing you can do is give them an input field.
They type an email, get a result, and understand the product.
Adding five welcome screens would only make that experience worse.
The same can be true for AI chat products.
Someone opens the app because they want to ask a question. If they can type their first prompt immediately, that might be all the onboarding they need.
Other products genuinely need more setup.
A fitness app may need to understand someone’s goals before recommending workouts. A language app needs to know which language they want to learn.
So I wouldn’t begin by deciding whether an onboarding should have three screens, ten screens, or thirty.
I’d begin by working out what someone needs to know or provide before they can get a useful result.
Then I’d design around that.
What I’d Check Before Shipping an Onboarding Flow
When reviewing an onboarding design, these are the questions I find most useful:
- What’s the first useful thing someone can do? Not just the first button they can tap, but the first result they’d care about.
- Are we asking for information too early? Could signup, preferences, or permissions wait until there’s a reason for them?
- Does every question change something? If we’re asking someone about their goals, the product should reflect those answers.
- Are we explaining too much? Could users understand the feature better by trying it instead of reading about it?
- What happens after the last screen? Do users have something to work with, or are we dropping them into an empty app?
I also like going through an onboarding prototype without reading any of the explanatory copy.
It’s a surprisingly useful test. You quickly notice where the interface is clear and where it depends too much on text to explain itself.
Of course, a good-looking flow isn’t proof that people will complete it. If the product is live, I’d want to look at where users drop off and whether they actually reach the action the onboarding was designed around.
Sometimes the screen you thought was helping is the one slowing everyone down.
A Final Thought
What I like most about Duolingo’s onboarding isn’t the number of screens or the animations.
It’s that the product lets you experience what you came for before asking much in return.
You don’t finish the onboarding knowing where every feature is.
You finish knowing a little more of the language you wanted to learn.
That’s a much better first impression than a beautiful welcome screen followed by an empty dashboard.
And it’s something I keep coming back to when thinking about how to design apps.
Before adding another onboarding step, I’d rather ask whether it helps someone get closer to the thing they opened the app to do.
Sometimes that means removing screens.
Sometimes it means adding a few.
Either way, I’d rather design an onboarding people actually enjoy using than one that just looks good in a Figma presentation.
I design and build apps at Xermio, and onboarding is where we find the most mistakes that are easy to fix. If you want a coding agent to review yours, my free app design skill has onboarding and paywall patterns built in. Run it in Audit mode on a screenshot of your first screen and see what it flags.
