The onboarding trap

There is a recurring conversation we have with clients who are about to commission an onboarding-flow design. The client believes that their product needs a guided tour — a sequence of tooltips and overlays that walks the new user through the interface. Our position, almost always, is that the product needs the opposite: a better empty state, fewer modals, and a single clear primary action on the first screen. The conversation usually takes about an hour and ends with the client agreeing, often grudgingly, that an onboarding tour is the wrong shape of intervention.

The reason guided tours fail is that they treat the new user as a problem to be managed rather than as a person to be served. The tour is designed for the team that built the product: it shows off the features the team is proud of, it walks through the navigation the team finds intuitive, it celebrates the parts of the interface the team is anxious about. The new user, meanwhile, has a job they are trying to do, and the tour is in the way of that job. Every additional tooltip is a delay before the user gets to the thing they came for. Every additional modal is a context switch. The completion rate on multi-step onboarding tours, in my experience, is appalling — somewhere between 12 and 28 percent across the systems I have measured — and the conversion impact of those tours is usually negative.

The intervention that does work is harder to design and easier to maintain. It is the empty state — the screen the user lands on when there is no data yet. A well-designed empty state does three things. It tells the user, in plain language, what this screen is for. It shows them, with an illustration or a sample row, what this screen will look like when there is data. And it offers them the single most-likely first action, as a clear primary button. That is the entirety of the onboarding pattern for most SaaS products. No tour. No tooltips. No multi-step modal sequence. One screen, three things, the user takes the action, the empty state is no longer empty, and the rest of the product reveals itself in context as the user needs it.

When we run a product UI sprint for a client whose original brief was an onboarding tour, we usually ship a redesigned empty state and a redesigned first-action flow, and that is enough. The metric we report at the end of the sprint is not "tour completion rate" — that metric should not exist — but rather "time to first meaningful action" and "seven-day retention". Both of those move when the empty state is right. Neither moves when the tour is. The next time someone asks you to commission an onboarding tour for their SaaS, ask them what the empty state looks like first. If the answer is "what empty state?", you have the actual brief.