Onboarding Users Into an AI Feature
5 min read · updated August 3, 2026
An onboarding that makes people excited about an AI feature and an onboarding that makes them good at using it are different artefacts, and the first one produces the support tickets.
The wrong goal
Most AI onboarding optimises for activation: get them to try it, make the first result impressive. That works for a deterministic feature, where an impressive first result is representative of all subsequent results.
Here it is not. The feature that impressed on the first run will be confidently wrong on the fourth, and a user whose expectations were set by the first run has no framework for what just happened. The outcome is not disappointment proportional to the error — it is a disproportionate collapse, because their model of the tool said this could not occur.
Appropriate reliance
The literature to reach for is trust in automation rather than onboarding. Lee and See’s 2004 review Trust in Automation: Designing for Appropriate Reliance makes the central point: the design goal is not maximal trust but calibrated trust — trust that matches the automation’s actual capability — and both directions of miscalibration are failures with their own costs.
- Over-trust produces reliance where verification was needed. The failure mode is an undetected error shipped onwards: a wrong figure in a report, a wrong name in a message. Expensive, attributable to the user, and rarely traced back to the onboarding that caused it.
- Under-trust produces disuse. The feature is available, capable, and not used, because the one bad experience generalised. Cheap for the user and total for you.
Trust is also dynamic: it is updated by experience, and the updates are asymmetric — it builds slowly and drops sharply after a failure. Which means onboarding cannot install the right level once and be finished. Its job is to install a model accurate enough that later failures are interpretable rather than disillusioning.
What the first run should do
- Produce a real output on the user’s own data, in one action. Not a video, not a tour, not a sample document. The output is the only thing that teaches what the feature does, and on their own data it also teaches what it does for them. This is the same argument as suggestions drawn from user data.
- Choose a task the feature is reliably good at. Deliberately, and knowing that it is unrepresentative in the easy direction. A first run that fails is a much worse outcome than one that is unrepresentatively smooth — but this is precisely why the boundary has to be taught in the same session.
- Show the recovery affordances in the first interaction. The user should see the regenerate control, the edit control and the undo before they need them. Discovering that a bad output is recoverable at the moment of a bad output is far less effective than knowing it in advance.
- Do not gate. A blocking tour in front of a text box is skipped by the people who most need it, and retained by nobody. Everything worth teaching can be taught by the interface at the point of use.
Teaching the boundary without a tour
The boundary is what onboarding is genuinely for, and it cannot be delivered as a list of limitations because nobody reads those and nobody retains them. Three techniques that work because they are attached to the moment of use rather than to a session:
| Technique | Description |
|---|---|
| Show the shape of the input space | A visible set of what the feature handles — slash commands, a mode picker, categorised suggestions — teaches the boundary as a side effect of being useful. A user who sees six categories has learned the edges without being told them. |
| Fail visibly and early, on purpose | If the feature cannot do something users will obviously try, make it say so immediately and specifically rather than attempting it badly. One clear 'I can't read PDFs yet' teaches more than a paragraph of caveats. |
| Attach the limit to the artefact | A file chip that says how much was read, a marker on unsourced claims, a note that the model's knowledge ends at a date. These are the placement rules from the expectation-setting page and they do the teaching that a tour cannot. |
There is also a piece of onboarding that happens before your product gets a turn: your marketing copy. If the landing page promised an assistant that handles everything, the first-run experience is not setting expectations, it is repairing them — and it is worth knowing which of those two jobs you are doing.
The first failure is part of onboarding
The moment that decides whether someone keeps using an AI feature is not the first success. It is the first failure, and almost nobody designs it, because it does not happen inside the onboarding flow where the design attention went.
Instrument it: find the first bad outcome per user — a regenerate, a discard, an abandoned session, an explicit thumbs-down — and treat that event as the last step of onboarding. What the interface does there matters more than anything on the first screen. Concretely, at that moment the user needs the recovery path to be obvious, an interpretation of what happened that does not read as an excuse, and something specific to try instead. If all three are present, a failure calibrates trust. If none are, it ends the relationship, and no amount of first-run polish recovers it.
There is a version of this that is worth doing deliberately, though it takes some nerve: let the first run include something the feature handles imperfectly, and handle the imperfection well. A user who sees an output that is 80% right, sees the interface acknowledge which part is uncertain, and fixes it in two clicks has learned the actual operating model of the feature in one interaction. A user who sees three flawless outputs has learned a model that will be falsified later, at a worse moment, with no interface around it.
The same logic applies to onboarding’s length. Everything in this page argues for less of it, not more: less explanation, fewer screens, no tour, limits attached to the point of use rather than gathered into a lesson. What replaces the missing material is the interface itself being honest in ordinary operation — which is the whole of this cluster and is why onboarding is one of the shortest pages in it. If the product needs a tour to be usable, the tour is compensating for something, and the something is where the work is.