In-App Onboarding for Web Apps: What It Is
What in-app onboarding means in a web app, why the advice written for mobile apps doesn't work here, what to build instead, and when you're better off building nothing.
Jonas Budelmann6 min read
On this page
In-app onboarding is the help you show a user inside your product, while they're actually using it. In a web app that usually means a short tour that points at things on the page, a checklist of the first few tasks worth doing, or a tooltip that opens when a feature becomes useful. Almost everything written about in-app onboarding describes mobile apps, where onboarding is a run of full screens a user swipes through before the app even opens. Web and mobile onboarding share a name and very little else.
That difference changes what you build and where you put it. In-app onboarding is one part of SaaS onboarding, which also covers the emails, the help docs and the people who answer questions. The in-product part is the one that differs most between a web app and a phone.
What is in-app onboarding?
In-app onboarding is the help you add to teach a user a product they're already inside. Nielsen Norman Group defines onboarding as "the process of getting users familiar with a new interface, using dedicated flows and UI elements that are not part of the regular app interface" (Mobile-App Onboarding, Alita Kendrick, Nielsen Norman Group, June 2020). That last phrase, "not part of the regular app interface", is what separates onboarding from the product itself. A tour, a checklist or a tooltip is something extra, laid over your normal screens, and it's meant to come off once a user knows their way around. So the test of a good flow is whether they can manage without it next time.
The word "onboarding" also gets used for two completely different jobs, which is where a lot of the confusion comes from. Employee onboarding is what HR does when a new hire joins a company. Client implementation is the project your team runs with a big new customer to get them set up and live. In-app onboarding is neither of those, and it's a smaller job than both of them. A user has signed up, they're looking at your product, and something has to get them from that first screen to a result worth coming back for.
How is in-app onboarding different on web and mobile?
On a phone, onboarding usually happens before the product does. A user installs the app, swipes through a few full screens explaining what it's for, allows notifications, makes an account, and only then sees the real interface. It runs once, and the app stays hidden behind it the whole time.
On the web, a user is already inside. They signed up in a browser tab, landed on a dashboard, and anything you show them has to work on top of a screen that's already full. There's no gap between arriving and getting started. So your guidance either points at the button or field it's describing, or it floats over the top of the screen and hides the very thing a user needs to see.
That one difference has knock-on effects. Web sessions run longer than phone sessions and users come back to the same screen for months, so you can spread onboarding over several visits instead of cramming it into the first minute. There's also more room on screen, so a step can point straight at a button instead of describing where it is.
Which mobile onboarding advice doesn't transfer?
Some of the standard mobile advice goes wrong the moment you move it to the web.
"Delay the sign-up so users see value first" makes sense for an app installed on a whim and deleted just as fast. A user signing up for a business tool has usually done it on purpose, sometimes after a demo or after getting it approved internally, so by the time they see the screen there's nothing left to delay. "Reach value in under sixty seconds" is a number that gets passed around in mobile onboarding advice, where a user who gives up is usually gone for good. A web user who gets stuck on Tuesday will often come back on Wednesday, so a sixty-second deadline isn't the thing to design against.
Fits a web app
Steps that point at the button they're talking about, so a user's eye lands in the right place. Progress spread over a few visits, because your users will be back. Prompts that wait until the feature is actually useful.
Borrowed from mobile
Full-screen welcome slides that hide the screen they're describing. Permission and setup screens stacked up before first use. A sixty-second target borrowed from a world where giving up is permanent.
Welcome slides are the ones that stick around longest, because they're easy to build and they look like onboarding. They also ask a user to memorize a screen they haven't seen yet, then test them on it straight away.
What you actually build in a web app
Three things cover most in-app onboarding on the web, and each one solves a different problem.
A guided tour walks a user through a real task, with each step attached to the button or field it's talking about. In HelpHero a highlighted step dims the rest of the page so the target stays lit, which stops a tour turning into a slideshow that gets clicked past. Tours work best for a first task that ends in something real.
A checklist gives a user the two or three things worth doing first and ticks them off as they go. It covers the thing a tour can't: steps that happen over days instead of all in one sitting. The five habits in our onboarding tips for SaaS teams mostly come down to getting that order right.
Hotspots are the ones a user opens themselves. A small beacon sits on a button and shows a short explanation on hover or click, for the feature a user will ask about on their fourth visit, not their first. All three work better with rules about who sees what, so a trial account in week one and a regular admin don't get the same prompts. Our user onboarding features page shows how the pieces fit together.
When should you skip it entirely?
Often, and more often than most vendors in this market will admit. Nielsen Norman Group's advice is to test your product without any onboarding first, and to add it only once users clearly struggle and fixing the design hasn't helped. Their research covers mobile apps, where they found most shouldn't have onboarding at all, and the reasoning holds on the web too: a user should be able to learn a screen by using it.
The other common mistake is teaching the screen instead of the task. A tour that names every panel on a dashboard has told a user what's on the screen and nothing about what to do with it. Build the tour around the job they signed up to get done and it still makes sense to them a week later.
Good onboarding puts itself out of a job
The test for anything you build is whether a user needs it a second time. A tour that gets them through a first real task and never runs again has done its job. A tooltip that has to sit on a button forever is telling you that button is badly labeled.
Getting this right on the web starts with ignoring the mobile playbook. Your users are already inside a product they chose, with something they came to get done, and the help that works is the help that gets out of the way once it has. You can start free and build your first flow without writing any code.
Common questions about in-app onboarding
What is in-app onboarding?
In-app onboarding is the help shown inside a product to get a new user to their first useful result: guided tours, checklists and tooltips laid over the working screen. On the web it runs after sign-up, while a user is already in the product, instead of as a set of screens before it.
Is in-app onboarding the same on web and mobile?
No, and treating them as one thing is the most common mistake here. On a phone, onboarding is usually a set of full screens that runs once before the app appears. On the web it sits on top of a screen a user is already working in, and it can be spread over many visits.
How long should in-app onboarding be?
Short enough to end in one real result. There's no time limit worth chasing on the web, because your users come back over days and weeks, so a flow that stops when the first task is genuinely done beats one built to beat a clock.
What's the difference between a product tour and in-app onboarding?
A product tour is one of the tools. In-app onboarding is the whole job, which also covers checklists, tooltips, empty screens and the rules that decide who sees what. A tour is often the first thing teams build, and it isn't always the right one.
Do you need a tool to build in-app onboarding?
Not always, though building flows in your own code means engineering time for every change and a release before you can fix anything. A no-code tool hands that job to whoever can see where users are getting stuck, which is usually a product or customer success owner rather than a developer.
