The product tour best practices that survive contact with real users are unglamorous: three to five
steps, one action and one reason per step, always skippable, and ending on something the user actually
made rather than a congratulations modal. The practice nobody lists is the most important one — know
when not to build a tour at all, because most bad onboarding is a tour doing a job the screen itself
should have done.
When is a product tour the right tool?
Only when order matters.
That is the whole test. If step three genuinely makes no sense until step two has happened — you
cannot invite a teammate until a workspace exists, you cannot run a report until data is connected —
a sequence is the honest shape for the information, and a tour is a sequence.
If the steps could each stand alone on their own screen, you do not need a tour. You need four better
screens. A tour in that situation is a way of apologising for an interface rather than a way of
teaching it, and it has the unfortunate property of hiding the problem from the team: activation goes
up slightly, the underlying confusion stays, and nobody revisits the screens.
The other legitimate use is a genuinely new capability shown to existing users, where the sequence is
short and the audience already knows the product. That is a different job from onboarding and it
should be a different, shorter tour.
What do the best product tours have in common?
Five properties. None of them are surprising, which is the point — the failures are failures of
discipline, not of insight.
They end on an artefact. The last step is the user looking at the thing they made: the project,
the imported list, the first report. Tours that end on "You're all set!" replace the moment of
accomplishment with marketing copy, and the user leaves having completed your sequence rather than
their task.
One action and one reason per step. "Click Import to bring in your existing contacts" works.
"This is your dashboard" does not — it spends attention and moves nobody.
They are escapable, and recoverable. Skip must be available, and so must a way back in. An
unskippable tour also destroys your own measurement, because completion no longer distinguishes
useful from mandatory.
They pre-fill whatever they can. Asking a new user to invent sample data is asking them to do work
before they have seen any value. If you can seed a plausible starting state, seed it.
They are short enough to finish in one sitting. Three to five steps. If the tour needs more, the
product needs simplifying — and the tour is now the place that truth goes to hide.
When should you skip the tour entirely?
Three situations, each with a better tool.
When an empty state would do. This is the big one. A projects list with no projects can explain
what a project is and offer the button that creates one. It teaches the same lesson without
interrupting, nobody has to dismiss it, and — critically — it cannot fall out of sync with the screen,
because it is the screen. Most tours should have been empty states.
When the work happens outside your product. Setting up an integration, configuring DNS, getting a
key from another vendor — a tour cannot follow the user there, so it strands them at the moment they
leave. Documentation and a checklist survive that; a tour does not.
When the user did not come to learn. Someone who arrived from a shared link to do one specific
thing wants that thing, not an orientation. Tours interrupt best at the start of a session the user
opened with no fixed intent.
The wider question of which onboarding pattern fits which job — empty states, checklists, tooltips,
tours — is the subject of in-app guided onboarding. This post is
about doing the tour well once you have established you actually need one.
How do you keep a tour from breaking?
A tour is a set of pointers into code it does not live in. Step four says "click Export"; six weeks
later Export becomes a menu item; the pointer resolves to nothing. Nothing fails in CI, nothing
reaches your error tracker, and the only witnesses are new users who do not file bugs.
Two things make this tractable.
Anchor steps to markers you own in your own source rather than to CSS selectors inferred by a
recorder. A marker attribute sitting on the element makes the dependency visible in a diff — deleting
that element is now an obvious act rather than an invisible one. Rendemo's tours work this way, as
described in building a tour.
Then check it automatically. Markers only help if something fails when one goes missing:
rendemo check reads a lockfile of every anchor and exits non-zero when one no longer exists, turning
a silent production breakage into a failed build.
The trade is real and worth stating: this approach needs the tour's anchors to live in your
repository, so a marketer cannot ship a tour alone on a Tuesday afternoon. No-code overlay tools can,
and for a team with no engineering time to spend on onboarding that is a genuine advantage. You are
choosing between verifiability and independence.
What should you measure?
Not completion rate, which every tool puts on the front of the dashboard and which answers the wrong
question. A high completion rate means the tour was useful, or it means the tour was hard to escape.
Measure whether new accounts reach the outcome you built the tour around, compared against a cohort
that never saw it. Then look at the second week: a tour that lifts day-one activation and changes
nothing about week-two retention taught people to click through a tour.
And watch per-step drop-off for its diagnostic value rather than its score. A step everyone abandons
is rarely a copywriting problem. It is usually the step where your product asks for something the user
does not have yet — which is a fact about the product, arriving through the tour.
If what you are actually building is a demo for people who have not signed up, the constraints are
different enough that the practices above do not transfer cleanly;
interactive product demos covers that case instead.
Top comments (0)