What is a product tour?
A product tour is a guided in-app walkthrough that highlights features or onboards new users to a SaaS product. Tours appear as overlays, tooltips, or modals anchored to UI elements, stepping users through a path. They’re triggered by user state — first sign-in, feature release, plan upgrade — and dismissed once completed.
Done well, a product tour helps a new user reach their first meaningful action faster. Done poorly, it’s a forced sequence of blue dots people dismiss without reading. The rest of this guide is about the difference.
Types of product tours
“Product tour” is a category, not a single pattern. Most SaaS products end up shipping at least three of these:
Welcome tours
The first tour a new user sees, usually on their first sign-in. Purpose: get the user from sign-up to the first action that delivers value — creating their first project, sending their first invite, publishing their first thing. Keep it short, 3–5 steps maximum. Anything longer drops off.
Feature announcement tours
A short tour triggered when you ship something new. Purpose: tell existing users about a feature they’d otherwise miss. Often shown as a single overlay or a 2-step interactive walkthrough. Frequency-cap these so power users don’t see them on every visit.
Secondary onboarding
The tour you run a week after sign-up, after the user has hit their activation milestone, to introduce depth — advanced settings, integrations, team features. Triggered by user state (e.g., “has created 3+ projects”), not by time.
Training tours
Aimed at admin users, power users, or new hires inside a customer account. Longer than first-run (5–10 steps). Often role-targeted so only admins see them.
Activation nudges
Single-step prompts that aren’t really tours — a tooltip, a contextual hint, an empty-state CTA. Worth mentioning because most tour platforms ship them under the same SKU. Use these for interactive product tour patterns where a full walkthrough would be overkill.
When to use a product tour (and when not to)
Reach for a product tour when your product has non-obvious workflows, when onboarding drop-off is measurably high, or when you ship features users keep missing. The signal isn’t “new feature shipped” — it’s “new feature shipped that nobody clicked.”
Skip the tour when the product is self-evident, when your audience is technical and resents hand-holding, or — most often — when better empty states would do the same job for less. A welcome screen with one good CTA usually beats a five-step walkthrough explaining what the buttons do.
The hardest case to call: the tour as a crutch. If you’re reaching for a tour because users keep getting stuck somewhere, the tour might be papering over UX you should fix instead. Ask whether you’d still need the tour if the screen made the next step obvious. If the answer is no, fix the screen first.
What makes a good product tour
Six things separate the tours people complete from the ones they dismiss in the first second:
1. Brevity
First-run tours work best at 3–5 steps. Past five, completion rates fall off a cliff. If you’re tempted to write a sixth step, consider whether that step belongs in a separate secondary-onboarding tour triggered later, after the user has reached their first activation milestone.
2. Skippable, always
Make “Skip” visible on every step, not just the first. Users who feel trapped get angry — users who feel in control finish. Counter-intuitively, an obvious skip button increases completion rates because it removes the “is this thing going to end?” anxiety.
3. Triggered by state, not on every load
Frequency-cap by user state. A tour should run once per user — or once per state change (e.g., when they upgrade plans). Showing the same tour on every page load is the fastest way to make a power user hate your product. Implement frequency capping at the platform level so individual tour authors don’t have to think about it.
4. Targeted by role, plan, or page
A tour aimed at admins shouldn’t play for end users. A feature-announcement tour for the Pro plan shouldn’t play for free users (it’s a paywall). Targeting reduces noise and increases relevance — both of which compound into higher completion rates over time.
5. Anchored to stable selectors
The biggest cause of tour breakage in production: tours anchored to UI elements that change CSS classes or DOM position when the product is redesigned. Use stable test IDs (data-tour-target attributes) when you can. Audit broken tours before each release.
6. Tracks completion and drop-off
Without analytics, you don’t know if a tour is working — you only know it exists. Track per-step views, completion rate, and where users drop out. Drop-off at step 3 of a 5-step tour is the signal to rewrite step 3, not to keep iterating on step 5.
How to build a product tour
Two paths, depending on how much engineering time you want to spend:
Hand-coded
Open-source rendering libraries handle the overlay, popover, and keyboard navigation. Around them you’ll need to build your own targeting (which user sees which tour), frequency capping (so the same tour doesn’t replay), analytics (per-step engagement), and a content surface (so non-engineers can edit the copy). A hand-coded approach is fine if you have one or two tours and a spare engineer; it stops being fine the moment a marketer wants to ship a tour without filing a Jira ticket.
No-code platform
Platforms like StepsKit, Appcues, Pendo, ProductFruits, and Userpilot ship the rendering, targeting, frequency capping, content editor, and analytics as one product. You install one script tag, build tours visually, and non-engineers can author copy. The trade-off: a recurring subscription instead of one-time engineering time. The break-even is usually around three or four tours — past that, no-code wins on time-to-ship.
StepsKit takes the no-code path with a flat $19/month — no per-MAU fees and no per-seat fees, which most platforms charge. See pricing →
Examples of well-designed product tours
A few tours worth studying. None of these are perfect, but each gets one thing right that’s worth borrowing:
Linear’s first-run
A single overlay that gets you straight to creating your first issue. No five-step explainer, no “welcome to Linear” modal. Borrows the principle: the fastest tour is the one that skips itself once you take the action it was about to recommend.
Notion’s empty states
Notion mostly doesn’t use product tours — they use rich, actionable empty states. The empty page itself is the tour. A good reminder that the best tour is sometimes a redesign of the screen you would have toured.
Figma’s overlay introductions
Figma uses contextual overlays the first time you encounter a feature in context — frames, components, auto-layout — instead of a big upfront tour. This is secondary onboarding done right.
Stripe Dashboard’s progressive disclosure
Stripe rarely shows tours; it uses small in-context hints that point you to the right docs page. Treats the documentation site as an extension of the product.
Vercel’s settings hints
Small contextual help icons next to settings that explain what each setting does inline. Not a tour at all — but it solves the problem that most tours are trying to solve, with less interruption.
The pattern across all five: the tours that work are the ones that feel like the product is being helpful, not the ones that feel like a marketing plan got embedded in your software. For more concrete walkthroughs, see the types of patterns above and the product tour examples we shipped under each.
How to choose product tour software
If you’ve decided to use a platform instead of hand-coding, these are the things worth comparing — in roughly the order they affect your bill and your day-to-day:
Pricing model
Most platforms price per MAU (monthly active user). That sounds fair until you realize the number you’re trying to grow — engaged users — is the same number that grows the bill. A flat-rate plan decouples the cost from the success of the product.
No-code support
Can a non-engineer build a tour without filing a ticket? If the answer is no, you’ll end up using the platform like a hand-coded library and paying for the convenience you’re not getting.
Targeting
Can tours be targeted by user role, plan, page URL, or custom user attributes? “Show this only to admins on the Pro plan visiting the billing page” should be a checkbox, not a custom JavaScript function.
Frequency capping
Show-once-per-user is the floor. Better: show-once-per-state-change so the same tour can re-run when something meaningful shifts. If a platform makes you build this yourself, that’s a real cost.
Analytics depth
At minimum: per-step views, completion rate, drop-off step. Bonus: event funnels you can connect to your own analytics tool.
Web vs. mobile
Most product tour software is web-only. If you have a native mobile app, your shortlist gets much shorter.
Theming
Can you match your brand without writing CSS overrides? If the platform’s default look doesn’t fit your product, you’ll spend hours fighting it.