Interactive Product Tour

A senior product marketing director's playbook for designing in-product tours, tooltips, and contextual help that teach product capabilities without becoming friction. Trigger logic, tour architecture, contextual placement, completion tracking. The discipline of building help systems that surface at moments of need and disappear when not needed.

Most product tours fail in one of two ways. They paint every button, link, and feature with "click for tour" hints until the visual noise is so great that users develop blindness to the dots. Or they show a single first-login tour the user skips or skims, after which the same help never re-surfaces when the user actually hits a moment of friction. Help that is invisible at the moment of need is help that does not exist.

The tours that work do something different. They trigger when the user is at a moment of friction, not all the time. They surface contextual hints when the user enters a section they have not explored, clicks into a feature requiring setup, or returns after a long absence. The system knows what the user knows and surfaces help at the right moment.

The voice is the senior product marketing director who has watched feature adoption double when tours were redesigned and watched it collapse when more tooltips were piled onto every surface. Practical, opinionated about the trigger logic that distinguishes useful help from visual noise, willing to call out when no in-product tour at all is the right answer.

When to use this skill: scoping an in-product help system for the first time, auditing a tour system that produces engagement metrics with no adoption lift, designing the trigger logic that decides when help surfaces, or deciding which features warrant tours vs documentation.

What this skill covers

This skill spans in-product tours, tooltips, and contextual help. The growth-tooling distinctions:

• onboarding-wizard-design is the sequential first-run experience. This skill is contextual help WITHIN the product, surfacing across the lifecycle.
• chatbot-flow-design is conversational help. This skill is non-conversational tour and tooltip help.
• interactive-product-tour (this skill) is trigger logic, tour architecture, contextual placement, completion tracking, and the discipline of being absent until needed.
• discovery-research-synthesis is research that informs tour content. Input, not part of.
• pm-spec-writing is the spec for engineers building the tour. This skill is about WHAT to build; pm-spec-writing is about communicating it.

The audience: product marketers, growth marketers, in-house product teams, agencies running activation work for SaaS clients.

Out of scope: first-run wizards (covered by onboarding-wizard-design); conversational help (covered by chatbot-flow-design); the engineering implementation; specific Userpilot/Pendo/Appcues platform configurations (those stay implementation-side).

The tour decision: when tours earn vs when documentation suffices

Before designing the tour system, decide whether tours are the right tool.

Tours earn investment when:

• The product has features users genuinely miss without prompting. Specific functionality buried in menus, advanced workflows that require sequence, integrations users do not know exist.
• The audience benefits from in-context guidance more than out-of-context documentation. Tours teach in the place the user will use the feature; docs require context-switching.
• The team can maintain tours as the product evolves. Tour content decays; without maintenance commitment, tours point to deprecated UI.
• The success metric is defined. Feature adoption, time-to-value for specific capabilities, reduction in support tickets for tour-covered features.

Tours do NOT earn investment when:

• The product's feature set is small enough that documentation suffices. A few tooltips on key features may be all that is needed.
• The audience prefers self-directed discovery. Some audiences resent in-product guidance and prefer to explore.
• The team cannot maintain tours alongside product changes. Stale tours are worse than no tours.
• The product changes frequently. Tour maintenance can exceed tour value if the product churns rapidly.

The decision is not "should we have a tour system"; it is "is in-product tour the right tool for this product and audience."

Detail in references/tour-decision-criteria.md.

Tooltip-spam vs one-and-done vs contextual-when-needed

The keystone framing.

Tooltip-spam. Every button, link, and feature has a "click for tour" hint or pulsing dot. Visual noise. Users develop blindness to the dots; the tour system fails as a teaching surface. Cost: the design effort produces help nobody perceives; the visual clutter degrades the product overall.

One-and-done. A single tour shown on first login. Users skip or skim. The same tour never re-surfaces when the user actually hits a moment of friction. Cost: help that is invisible at the moment of need does not help. Feature adoption stays low; support tickets persist for features the tour covered.

Contextual-when-needed. Tours and tooltips trigger when the user is at a moment of friction (entered a section they have not explored, clicked into a feature requiring setup, returned after a long absence, hit a feature flag's first activation). The system knows what the user knows and surfaces help at the right moment. Cost: trigger logic is meaningful work; payoff is help that compounds adoption over time.

The litmus test. Watch a user encounter a feature for the first time. Does the help system surface useful guidance at that moment, or did it surface guidance at first-login that the user has long forgotten? If the former, contextual-when-needed. If the latter, one-and-done. If the help is competing with 14 other tooltip dots scattered across the page, tooltip-spam.

Trigger logic: event-based vs time-based vs state-based

The mechanism that decides when help surfaces.

Event-based triggers. Help appears in response to a user action. Clicked a feature for the first time, entered a new section, completed a flow.

When to use. Default for most contextual help. The user did something; help responds.

Time-based triggers. Help appears after time elapsed. Returned to the product after 30 days of absence; been on this page for 60 seconds without acting.

When to use. Time can signal need (long absence; stuck on a page). Use sparingly; time alone is a noisy signal.

State-based triggers. Help appears based on user state. New user vs power user; account size; feature usage history.

When to use. When the help differs by user segment. State-based triggers personalize help.

Combined triggers. Most production tour systems combine all three. Event-driven, with time and state modulating frequency and content.

The discipline. The trigger answers "when does this help surface and why." Decorative triggers (showing help when it is not needed) become tooltip-spam.

Detail in references/trigger-logic-patterns.md.

Tour architecture: single tour vs branched vs library of micro-tours

How help is organized.

Single tour. One linear tour covering the product. Simple; rigid; rarely fits how users actually explore.

Branched tour. Tour adapts based on user choices or path through the product. More relevant; more complex.

Library of micro-tours. Dozens of small focused tours, each tied to a specific feature or workflow. Triggered contextually. Most flexible; most maintenance.

The choice. Most modern systems use the micro-tour library approach. Single tours feel canned; branched tours are hard to maintain at scale; a library of contextual micro-tours matches how users actually explore.

Detail in [references/tour-architecture-patterns.md](references/tour-architecture-patterns.