Flagship Skill · Interactive product tour

The interactive product tour skill.

Tours that earn attention by being absent until needed.

A senior product marketing director's playbook for designing in-product tours, tooltips, and contextual help that teach product capabilities without becoming friction.

Audience: product marketers, growth marketers, in-house product teams, agencies running activation work.

View the skill on GitHubBrowse the full catalog

What this skill is for

Growth tooling, grouped by funnel stage.

Interactive-product-tour sits in the Activate cluster alongside onboarding-wizard-design and chatbot-flow-design. The trio covers the activation surface across sequential, contextual, and conversational help.

Capture

Activate

  • onboarding-wizard-design

    First-run wizards that engineer the ah-ha moment.

  • interactive-product-tour (this skill)

    Contextual tours that surface at moments of friction.

  • chatbot-flow-design

    Conversational flows grounded in knowledge.

Convert

Architect

The keystone distinction

Three positions. Both extremes are failure modes.

Failure mode

Tooltip-spam

Every button has a hint or pulsing dot. Visual noise. Users develop blindness; tour system fails as a teaching surface.

Failure mode

One-and-done

Single first-login tour. Users skip; the tour never re-surfaces when help is actually needed. Help invisible at the moment of need.

The discipline

Contextual-when-needed

Tours trigger at moments of friction: entered new section, returned after absence, hit a feature requiring setup. Help surfaces at the right moment, not all the time.

Anatomy of contextual-when-needed help

Tour fires at a moment of friction with frequency cap.

A user returning after 30 days encounters a section they have not explored. Tour surfaces with respectful framing and clear dismiss; trigger logic and frequency cap visible at the bottom for design transparency.

Product UI (your dashboard)

Sidebar

  • Dashboard
  • Reports
  • Analytics
  • Settings

Welcome back

Your dashboard

Metric A
Metric B

Contextual tour (1 of 1)

Reports just got an upgrade

You have not explored the new Reports section yet. Want a 30-second tour?

Trigger: user has not visited Reports in 30 days; new feature shipped

Frequency: once

The framework

Twelve considerations for product tour design.

  1. 01The tour decision (or documentation)
  2. 02Contextual-when-needed, not tooltip-spam or one-and-done
  3. 03Trigger logic sound
  4. 04Tour architecture matches usage
  5. 05Contextual placement non-intrusive
  6. 06Dismissal mechanics honest
  7. 07Completion tracking instrumented
  8. 08Re-trigger logic respectful
  9. 09Power-user vs new-user differentiation
  10. 10Mobile parity
  11. 11Maintenance discipline
  12. 12Adoption as success metric

What is in the skill

Twelve sections covered in the body.

  1. 01

    What this skill covers

    In-product tours, tooltips, contextual help. Distinct from onboarding-wizard-design (sequential first-run) and chatbot-flow-design (conversational).

  2. 02

    The tour decision

    When tours earn vs when documentation suffices.

  3. 03

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

    The keystone framing. The litmus test for tour quality.

  4. 04

    Trigger logic

    Event-based, time-based, state-based, combined triggers.

  5. 05

    Tour architecture

    Single tour vs branched vs library of micro-tours.

  6. 06

    Contextual placement

    Tooltip, spotlight, sidebar, inline. Placement and visual design.

  7. 07

    Completion tracking and re-trigger logic

    Per-user state, re-trigger logic, the over-trigger and under-trigger traps.

  8. 08

    Power-user vs new-user differentiation

    Differentiation signals and patterns.

  9. 09

    Common failure modes

    9+ patterns: tooltip-spam, one-and-done, over-trigger, under-trigger, mobile-broken, brand-inconsistent.

  10. 10

    The framework: 12 considerations

    Decision, contextual-when-needed, trigger logic, architecture, placement, dismissal, completion tracking, re-trigger, power-user differentiation, mobile, maintenance, adoption metric.

  11. 11

    Reference files

    Nine references covering decision criteria, trigger logic, tour architecture, contextual placement, completion tracking, power-user vs new-user, dismissal, anti-patterns, failures.

  12. 12

    Closing: tours earn attention by being absent until needed

    The tour systems that compound feature adoption are the ones that surface contextually.

Reference files

Nine references that go alongside the SKILL.md.

  • references/tour-decision-criteria.md

    When tours earn the build vs when documentation suffices.

  • references/trigger-logic-patterns.md

    Event-based, time-based, state-based, combined triggers.

  • references/tour-architecture-patterns.md

    Single tour vs branched vs library of micro-tours.

  • references/contextual-placement-patterns.md

    Tooltip, spotlight, sidebar, inline. Placement and visual design.

  • references/completion-tracking-and-re-trigger.md

    Per-user state, re-trigger logic, the over-trigger and under-trigger traps.

  • references/power-user-vs-new-user-patterns.md

    Differentiation signals and patterns. The over-helping and under-helping traps.

  • references/dismissal-and-non-intrusion-patterns.md

    Dismissal mechanics. The non-intrusion principle.

  • references/tour-anti-patterns.md

    The patterns that look like tours but degrade the product.

  • references/common-tour-failures.md

    9+ failure patterns with diagnoses and cures.

Browse all reference files on GitHub

Pairs with these platforms

Three platforms with tour-relevant workflows.

The skill is platform-agnostic. These platforms ship workflows that fit tour programs: PostHog (per-tour adoption-lift tracking), Notion (tour content authoring), AirOps (workflow automation around triggers).

Bridges to other skills

Five sister skills that compose with product tours.

  • Sister: sequential first-run

    onboarding-wizard-design

    Onboarding-wizard-design is the sequential first-run experience. Interactive-product-tour is contextual help within the product across the lifecycle. Different timing.

  • Adjacent: conversational help

    chatbot-flow-design

    Chatbot-flow-design is conversational help. Interactive-product-tour is non-conversational tour and tooltip help.

  • Engineering handoff

    pm-spec-writing

    Writing the spec for engineers building the tour. This skill is about WHAT to build; pm-spec-writing communicates it.

  • Upstream input

    discovery-research-synthesis

    Customer research informs which features need contextual tours. Patterns surfaced through research drive the tour library.

  • Measurement support

    experimentation-analytics

    Reading per-tour adoption-lift data. This skill instruments; experimentation-analytics interprets.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository. MIT licensed.

View SKILL.mdBrowse the full catalog

Frequently asked questions.

How is interactive-product-tour different from onboarding-wizard-design?
Onboarding-wizard-design is the sequential first-run experience post-signup. Interactive-product-tour is contextual help WITHIN the product, surfacing across the full lifecycle. Wizards are linear; tours are contextual. Different timing, different design considerations.
What is 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. The system knows what the user knows and surfaces help at the right moment, not all the time.
What is 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. Cumulative cognitive load degrades the product itself.
Why is one-and-done insufficient?
A single first-login tour shows once, then never re-surfaces. Help that is invisible at the moment of need does not help. Feature adoption stays low; support tickets persist for tour-covered features. Re-trigger logic at moments of relevance is the cure.
How should we differentiate tours by user state?
Power users do not want tours on features they already use. New users need tours on features they are encountering for the first time. Differentiation signals: feature usage history, tenure, engagement frequency, plan or role. The system should know which user is which.
What conversation should adoption metrics enable?
Per-tour adoption-lift measurement: do users who saw the tour adopt the feature at higher rates than users who did not? If lift is zero, the tour is not adding value; redesign or retire. Tour completion alone is not the metric; downstream feature adoption is.