In-app guidance is instructional content delivered inside your product, at the moment a user needs it: tours, checklists, tooltips, inline hints, banners and help menus. Done well, it shortens the path to the first moment of value. Done badly, it is a pop-up between your trial user and the thing they came to do.
This guide is for product leaders and founders at B2B SaaS companies. It covers the patterns and what each is for, how to decide when to show guidance, what the research says about tutorials, and where guidance fails in real free trials.
TL;DR
- In-app guidance is not one feature. It is a set of patterns (tours, checklists, tooltips, inline help, banners, resource centers) that each do a different job.
- Pull beats push: help triggered by a signal that the user needs it outperforms tutorials forced on everyone at launch.
- Completing a guide proves nothing. Measure task success and feature adoption downstream, not guide views.
- Guidance must be skippable, resumable and recoverable, or it turns into interruption.
- Fix the setup that comes before any value first. Guidance on top of a bad flow only decorates the problem.
Table of Contents
- What in-app guidance actually is
- The patterns and the job each one does
- Push versus pull: the distinction that matters most
- What the evidence says about tutorials
- When to show guidance in a B2B free trial
- Failure modes we see again and again
- Special case: AI features and regulated products
- Choosing tooling without getting lost
- Our perspective
- A practical audit you can run this week
- Where we can help
- FAQ
- Sources
What in-app guidance actually is
The simplest definition: help that lives in the interface rather than in a separate documentation site, video or email. Amplitude's overview of in-app guides frames it as support across the whole lifecycle, from first use to core use to later releases, rather than a one-time welcome tour.
That lifecycle view matters for B2B SaaS. A trial user needs different help from a customer in month six. The first needs to reach a result fast. The second needs to discover the report builder, adopt a new integration, or recover after weeks of inactivity.
The practical goals are consistent across products:
- Shorten time to value.
- Improve onboarding and feature adoption.
- Help people finish multistep workflows.
- Communicate product changes.
- Deflect support requests that never needed a human.
The strongest B2B use cases are setup, activation, complex recurring workflows, new-feature adoption, re-engagement and self-serve troubleshooting.
The patterns and the job each one does
Teams get into trouble when they reach for a tour for every problem. Each pattern has a distinct job, and the Dynatrace guided interaction guidelines lay out the same split.
| Pattern | Best job | Typical misuse |
|---|---|---|
| Product tour | Sequential orientation to a small, unfamiliar interface | A ten-step tour on first login that nobody finishes |
| Tutorial | Teaching a task or an advanced capability | Teaching obvious controls |
| Checklist | Showing a finite path to activation | A list of tasks that are not tied to value |
| Tooltip | Clarifying one specific control | Tooltips stacked on every element |
| Inline help | Explaining a field at the point of entry | Help text that repeats the label |
| Banner | Announcing a change | Banners that never expire |
| Launcher or resource center | Pull-based self-service | Hiding it, so help cannot be found again |
| Feature highlight | Revealing newly released functionality | Showing it to users who will never need it |
A useful rule: push patterns (tours, banners, highlights) interrupt, so they must earn the interruption. Pull patterns (launchers, inline help, tooltips on demand) wait until the user asks or shows signs of needing help.
Push versus pull: the distinction that matters most
The debate is rarely "tour or no tour." Nielsen Norman Group separates push revelations, such as intrusive tutorials and change lists shown at launch or at random points, from pull revelations, which are triggered by a signal that the user would benefit from the information right now.
Their recommendation is to understand the user's journey to the feature before choosing a pattern. Contextual help is more likely to be noticed because it appears when the user has an immediate goal. It should be easy to dismiss, easy to recall, revealed progressively, and shown alongside each step of a multistep task so users do not have to memorize instructions.
The same principle shows up in platform guidance. Android's onboarding guidelines recommend separating what must happen before first use from what can happen in the app, showing value before asking for permissions or account creation, and giving clear skip and resume behavior. The guidance is for mobile apps, but the logic transfers directly to a SaaS trial: do not ask for commitment before you have shown something worth committing to.
What the evidence says about tutorials
Most teams assume that if users complete the guide, the guide worked. The data is less flattering.
In a 2020 NN/g study across four mobile apps, primary-task success was 91% for people who read the tutorial and 94% for people who skipped it. Tutorial readers also took longer, 93.49 seconds against 85.17 seconds. Neither difference was statistically significant, which is the point: the tutorial did not measurably help.
That is not a case for removing guidance. A 2025 field study presented at ACM UIST examined whether a minimal intervention during onboarding can influence long-term behavior. In a field experiment with thousands of users, a small onboarding intervention increased activity and visits, and the effect declined over time but stayed significant. The intervention was light and left the user in control, not a heavy lesson.
Taken together, the lesson is practical:
- Passive reading of product information is weak.
- A small nudge that helps users state their intent or take a meaningful first action can change behavior.
- Guide completion rate is a vanity metric. Track whether users complete the task the guide supports, and whether they come back and adopt the feature.
When to show guidance in a B2B free trial
A trial is a short, high-stakes window. Your user has a job to do, limited patience, and often a colleague asking whether the tool is worth buying. Here is how we would sequence guidance.
Before first value: remove, then guide
The first question is not which tooltip to add. It is what stands between sign-up and the first useful result. Long forms, mandatory integrations, empty states with no sample data and unexplained permission requests all delay value. Remove or defer what you can. Then guide through what remains.
Identify the user's desired job and the smallest action that produces value. Show only the guidance needed for that action, anchor it to the relevant interface element, allow dismissal, and make it retrievable later.
During activation: a short, honest checklist
A checklist works when it exposes a finite path to an outcome the user cares about, for example connecting one data source, building one report, inviting one teammate. It fails when it lists admin chores. Each item should map to behavior that predicts retention in your product. If you do not know which behaviors those are, find out before you build the checklist.
Inside complex workflows: step-level help
For multistep workflows, break the help into guidance attached to each step instead of a long explanation up front. Users apply instructions best when they sit beside the live control and can be acted on immediately. This reduces split attention, where people flip between a help article and the screen and lose their place.
Later in the lifecycle: releases and rarely used features
Show help when functionality changes or when a user reaches a rarely used feature. Use targeting based on role, lifecycle stage, actions taken or feature state. Without targeting, an announcement is an interruption for everyone it does not concern.
Failure modes we see again and again
These are the problems that most often sink in-app guidance, and they overlap with the failure patterns NN/g documents for onboarding tutorials:
- Front-loading. Too much content at first login, before the user has any context to attach it to.
- Blocking the task. A modal covers the control the user is trying to reach.
- Wrong moment. Guidance fires on a timer instead of on evidence of need.
- Repeating dismissed messages. The user said no. Respect it.
- Explaining the obvious. A tooltip on a search box teaches nothing and trains users to dismiss everything.
- No way back. If a dismissed overlay cannot be recovered, it is one-time content.
- Documentation as a substitute. A link to a help center is not in-context support.
The Dynatrace team puts the structural point well in its introduction to guided interaction: guidance is part of the core workflow, with consistent components, a persistent way to recover dismissed help, and relevant documentation links, not a separate onboarding project. Overlays with no recovery path, or no behavioral targeting, do harm.
Special case: AI features and regulated products
Two kinds of product need extra care.
AI features. Users need to understand the result, what permissions the feature needs, how their data is used and how to recover when the output is wrong. Show value before asking for trust, let people defer the explanation, and make the recovery path visible. A good first prompt that helps users articulate what they intend to do beats a lecture on how the model works.
Enterprise and regulated products. Combine lightweight contextual guidance with a local help menu and links to authoritative documentation, instead of forcing a mandatory tour. People in finance, insurance and healthcare often work under audit pressure and cannot afford a flow that surprises them.
Choosing tooling without getting lost
Most teams ask about tools before they have a guidance strategy. The market falls into a few types:
- Platform-native builders designed for one ecosystem, such as a CRM's own guidance tool.
- Broader no-code digital adoption platforms that combine guide creation with segmentation, analytics, surveys, experimentation and resource centers.
- Design system components your engineering team builds and maintains in code.
The Amplitude guide notes that vendor capabilities and pricing change often, so treat any list as a category map. During procurement, verify current US pricing, data-processing terms, browser and SDK coverage, accessibility, localization and integration support.
Implementation can also be harder than it looks. Anchoring help to live controls is difficult in proprietary interfaces or products without accessibility APIs, as shown in MIT research on contextual help for GUIs. Plan your instrumentation and component strategy early, particularly in enterprise products.
Our perspective
We rarely start with the guidance layer. When we work on a B2B free trial, we sign up as a real user, move through the trial step by step and note where momentum dies. In our experience the cause is more often structural than instructional: setup that comes before any value, prompts at the wrong moment, unclear pricing.
That changes what we recommend. If a trial asks for five integrations before showing a single result, no tooltip fixes it. Reorder the flow, then add the smallest guidance that makes the first win obvious. Guidance should be the last mile of a well-designed path, not a bandage on a poorly designed one.
We also hold teams to a simple standard: every guide needs a user job, a trigger based on evidence of need, a way to skip, a way to get it back, and a downstream metric. If one of those is missing, we cut the guide. Our background across SaaS, fintech, gaming and regulated industries has taught us that restraint is usually what raises conversion.
— Edijs
A practical audit you can run this week
You do not need a tool purchase to find out whether your guidance helps.
- Sign up as a new user. Use a fresh account and a work email. Time how long it takes to reach the first meaningful result.
- List every interruption. Count each modal, tooltip, banner and email prompt before that first result.
- Tag each one. Is it push or pull? Is it triggered by behavior or by a timer? Can it be dismissed and recovered?
- Remove what explains the obvious. If a control is conventional, cut the explanation.
- Pick one workflow. Rewrite its help as step-level guidance beside each action.
- Define the outcome metric. For example, the percentage of trial users who complete the key task within their first session, not the percentage who finish the tour.
- Test the change. Compare cohorts, and watch whether the effect holds after the first week.
Where we can help
If your trial users stall and you are not sure whether the problem is setup, timing or messaging, our AI + UX Discovery engagement is the place to start. We go through your trial as a real user, map where people drop off and show what to fix first and why, backed by research. When you are ready to build, AI + UX Design covers the guided experiences themselves, and our AI Agents & Workflows work covers prototyping assistants that help users through complex tasks. You can see how a setup change played out in our Supliful case study, or browse all services.
FAQ
What is the difference between in-app guidance and onboarding?
Onboarding is the first-run experience that gets a new user to value. In-app guidance is the broader toolkit, and it keeps working after onboarding: feature adoption, new releases, re-engagement and troubleshooting. Onboarding uses guidance, but guidance is not limited to onboarding.
Are product tours worth it?
Sometimes. A short tour can orient people in a small, unfamiliar interface. NN/g's mobile study found no significant task-success gain for tutorial readers, so test a tour against contextual help before committing to it, and make it skippable.
How do I measure whether in-app guidance works?
Measure what happens after the guide, not the guide itself. Task completion, time to first value, feature adoption and return visits tell you far more than views or completion rates. Compare users who saw the guide with similar users who did not.
Should I build guidance in-house or buy a tool?
It depends on your interface and team. No-code platforms are faster to launch and bring segmentation and analytics. In-code components give tighter control and consistency. Whichever you choose, check US pricing, data terms, accessibility and browser coverage before you commit.
Does in-app guidance reduce support tickets?
It can deflect avoidable requests, especially when help appears beside the control that causes confusion. It does not replace documentation or human support. Offer more than one form of help, such as in-context hints, searchable answers and a way to reach a person.
Sources
- Onboarding Tutorials vs. Contextual Help, Nielsen Norman Group
- Mobile Tutorials: Wasted Effort or Efficiency Boost?, Nielsen Norman Group
- Authentication & Onboarding, Android Developers
- Components and patterns, Dynatrace Developer
- Introduction to guided interaction, Dynatrace Developer
- Digital Nudging in Mobile App Onboarding: Field Evidence on User Engagement, ACM
- A Guide to In-App Guides, Amplitude
- Creating Contextual Help for GUIs Using Screenshots, MIT CSAIL
Recommended
Made with BabyLoveGrowth to strengthen your backlink profile