Usually because the first session asked them to work before it gave them anything. They wanted to see whether the product solves their problem. Instead they got a setup wizard, an invite step and a form about company size. Nothing they saw was worth returning for.
Onboarding is the part of a product most often designed by committee and least often tested. Every team wants their step in it, and each step seems small on its own.
So we use a deliberately narrow framework when we work on these flows, built around four questions. It is opinionated, and it exists mainly to give teams a reason to say no to steps.
One thing: get a new user to the moment where the product is obviously useful to them, as fast as possible, with as little input as possible. That is the whole objective. Everything else, including data collection, activation metrics and feature education, is secondary and usually harmful in the first session.
This is different from teaching someone the product. Teaching comes later, once they have a reason to learn. A person who has not yet seen value has no motivation to remember anything you tell them, which is why product tours shown to brand new users are so poorly retained.
It is also different from qualifying them. Sales qualification questions in onboarding trade the user's momentum for your reporting, and the user pays for it.
Four questions, answered in order, before any screen gets designed. What is first value for this user? What is the shortest path to it? What setup can be deferred until after it? And how does the user know they are making progress along the way?
The order matters more than the questions. Teams usually start at the fourth question, designing progress indicators for a flow whose destination nobody has agreed. Defining first value first tends to delete half the proposed steps on its own.
Each question has a test attached. If you cannot state first value in one sentence a customer would recognise, you are not ready to design. If a step does not move the user along the shortest path, it is deferred or cut. If setup cannot be deferred, you should be able to say precisely why.
Describe the smallest moment where the user sees their own situation improved, in their words rather than yours. Not activated, not completed setup. Something like seeing their own data in a chart, or watching the first message get routed correctly.
The critical constraint is that it must involve their reality, not a demo. Sample data gets you a faster first session and a much weaker one, because the user discounts anything that is not theirs. If importing real data is genuinely slow, the design problem is how to show partial real results early, not how to make the sample look convincing.
Write it down and get the whole team to agree the sentence. In our experience this conversation is where the real disagreement surfaces, and it is much cheaper to have it in a document than in a design review three weeks later.
Anything that serves you rather than the user. Team invites, billing details, profile photos, integration setup, and every question whose answer only feeds a report. None of these help the user reach first value, and each one adds an opportunity to leave.
Defer rather than delete. The information you need is still worth collecting, just later, in context, at the point where the user has a reason to provide it. Asking for a team invite after someone has built something worth sharing works far better than asking on step two.
The heuristic to lean on here is aesthetic and minimalist design, one of the ten usability heuristics Jakob Nielsen developed with Rolf Molich in 1990 and which have remained unchanged since 1994. Every extra unit of information in an interface competes with the relevant units and diminishes their visibility. Our notes on progressive disclosure cover how to stage the rest.
By making the system's state obvious at every moment. Visibility of system status is the first of Nielsen's heuristics for a reason: users need to know what is happening, and a design that keeps them informed builds trust.
A progress bar is the laziest version of this and it often backfires, because it draws attention to how many steps remain. Better signals are showing the thing being built as it is built, naming what just happened in plain language, and making waits visible with an honest description of what the system is doing.
Empty states carry a lot of this weight and are usually neglected. A screen with nothing in it yet is an opportunity to say what will appear here and how to make it happen. Our piece on loading and empty states covers how to use them properly.
Rarely, and almost never for a first time user. A tour front loads information at exactly the moment the person has the least context to attach it to, and the standard behaviour is to dismiss it and move on.
The heuristic that argues against tours is recognition rather than recall. Good design minimises the user's memory load by making elements and options visible, so that information needed to use the interface is available when it is needed rather than memorised in advance. A tour asks for memorisation. A well labelled interface does not.
Where contextual help does work is at the moment of use. A short explanation attached to the control it describes, appearing the first time someone reaches it, respects the same heuristic and gets read. That is a different pattern from a tour and it is worth the effort.
With five people at a time, repeatedly. Jakob Nielsen argued in an article published on March 18, 2000 that testing with five users per iteration beats one large study, because the first five reveal roughly 85% of the usability problems and the remaining budget is better spent on further rounds after redesign.
That advice fits onboarding unusually well, because onboarding problems are severe and obvious rather than subtle. You do not need statistical confidence to learn that nobody understands what the second screen is asking for. You need to watch five people not understand it.
Test with people who match your actual new users, not colleagues. A teammate cannot un know your product, and their fluency will hide precisely the confusion you are looking for.
Designing the flow for the most complex customer. There is always a large account with an unusual configuration, and their needs pull every step towards more options and more questions. The result is a flow that serves the rare user badly and the common user worse.
The fix we now default to is designing for the most common case and giving the complex case an explicit escape route early. A visible path for teams with an existing setup costs one link and rescues the main flow from being negotiated to death.
The other recurring mistake is treating onboarding as a project rather than a surface. It gets built once, then features accumulate around it for two years and nobody owns it. Whoever owns activation should own these screens continuously, the way somebody owns the pricing page.
Write the first value sentence and get three colleagues to agree it. Then list your current onboarding steps and mark each one as on the path, deferrable, or serving only internal reporting. That exercise usually removes two or three steps before any design work begins.
Then watch five real users go through the flow without help. It takes an afternoon and it will tell you more than a quarter of analytics. If you want help redesigning an onboarding flow, or a fresh set of eyes on where yours loses people, we are happy to walk through it with you at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.