AI feature onboarding: teaching what it can and cannot do

An AI feature's onboarding should explain what it does, what it can't and how it improves. How to design the first session so users reach a first useful result.

info Quick Definition
AI feature onboarding is the way a product introduces a feature built on a model: what it does, what it does not do and how it can improve. Its goal is to get people to a first useful result quickly, with realistic expectations.

What problem does it solve?

Traditional software shows its capabilities. There are buttons, menus and labelled fields that indicate what can be done. In an AI feature, much of the capability sits in the model, and the screen often shows only a text box. The person does not know whether they can ask for a summary, a table or a correction, and does not know what happens when they ask for something out of scope.

That produces a gap between what users expect and what the product can do. The “Mental Models” chapter of Google’s People + AI Guidebook addresses this problem: everyone arrives with a prior mental model of what the product does, and if the product does not help adjust it, the first experience can leave a wrong idea of its capabilities. That gap is one reason people abandon a feature that could have helped them.

Why does it matter to a designer?

Because AI onboarding is not like classic software onboarding. In classic software, the tutorial shows where things are. With AI, you have to teach something harder: how to think about a system that is probabilistic, sometimes wrong and can change.

PAIR’s guidance recommends introducing AI in stages: explain what it can do, what it cannot do, how it may change and how to improve its results. It also asks you to explain the benefit, not the technology, and to introduce new features only when they are needed.

Another point is human-like treatment. The guidance warns that people using a conversational interface tend to attribute human traits to it, and that if the system’s limits are not communicated they may expect too much of it. Its recommendation is to state clearly that the product is not a person and to choose the level of humanization according to what the AI can actually do. See anthropomorphism.

How do you design the first session?

A 2026 proposal by Tian Pan, adapted here, has five parts (the first four are his; the last comes from PAIR’s guidance):

  1. A real task. The first experience should solve something from the person’s own work, not a generic demo. That way the value is visible in their context.
  2. Little input before the first result. Ask for the minimum needed to produce something useful and leave configuration for later. If role or team context already exists, preload it.
  3. Integration into the flow. Bring the first request to where the person already works. A feature that lives in another tab gets used less.
  4. Few capabilities in view. Tian Pan argues that three clear examples of what the AI can do work better than twenty. Each example should be a task the person recognizes.
  5. Reversible actions. PAIR’s guidance asks you to design for experimentation. A draft that can be discarded or a suggestion that isn’t applied on its own lowers the cost of trying.

For limits, PAIR recommends a default experience that does not depend on AI, so the person is not stuck when the system cannot complete a request, and avoiding error messages with no next step. See AI errors and recovery for which messages help.

How do you measure whether it works?

In its article on onboarding, Pendo recommends following cohorts of new users and studying how the ones who stay behave in their first one to three days, because aggregate feature use can be misleading. It also mentions A/B tests and gradual rollout of onboarding. Pendo does not discuss AI in that text: this is a general product practice that applies equally here.

Tian Pan proposes measuring time to first value (the moment the person sees an output relevant to their need) rather than time to first action, and checking whether the first session produced a result from the user’s own data instead of sample data. His article includes conversion and churn figures without saying where they come from, so they are not reproduced here: treat them as hypotheses to test in your own product.

When NOT to build AI onboarding

  • When the feature is obvious. If the result is understood on its own, a tutorial adds friction.
  • When the explanation would be a list of capabilities with no context. It is better to show the feature when it is relevant to the task the person is doing.
  • When there is no non-AI path. If the person cannot finish their task when the AI fails, onboarding should teach that way out, not hide it.
  • When onboarding promises more than the AI does. Overstating capabilities creates disappointment and loss of trust.

Example

Illustrative example: a project management tool that adds an assistant for writing meeting minutes. On the first visit to a meeting, a card appears: “I can draft the minutes from your notes. I don’t know the agreements you didn’t write down, so review each point before sharing it.” Below, a “Try with this meeting” button applies the feature to a real meeting of the user’s, with a draft they can edit or discard. Only afterwards does the option to configure templates appear. The first time the person sees minutes built from their own agreements, they understand what the assistant does, and the warning about what it doesn’t know is no longer abstract.

Common mistakes

  • Putting a seven-step tour in front of the feature before the person has used it.
  • Presenting the AI as a named persona with a personality, without saying it is a system.
  • Explaining the technology instead of the benefit to the user.
  • Measuring success by how many finished the tutorial, not how many reached a useful result.
  • Not re-orienting users when the feature changes significantly.

Sources

Frequently asked questions

What should AI feature onboarding explain?
What the feature can do, what it cannot do, how it may change over time and how the user can improve its results. Google’s PAIR guidance recommends this from the first interaction.
Why don't users find AI features?
Because the capability lives in the model and the interface often shows only a text box. Users don’t see a map of what they can ask, so they need a real first experience.
What is the best first experience with an AI feature?
A real task from the user’s own work, with little input up front and a quick result, so they see the value before configuring more.
Do you need a long tutorial to teach AI?
No. A short, staged onboarding tied to the moment the feature is relevant works better, with brief explanations and reversible actions for experimenting.