By Mehdi HassanHow do you design onboarding for an AI product?
You design onboarding for an AI product by working backwards from one first useful result: the output a new user would keep. Then you remove everything between signup and that result, and replace the blank input with starting points. Unlike classic SaaS, the hard part isn't learning the interface. It's learning what to ask and how far to trust the answer.
Most of the general principles from our SaaS onboarding UX guide still apply: a short signup, one value event, empty states that teach. This article covers what's different when the product's core is a model. The output varies, users arrive with inflated or skeptical expectations, and the main control is often a text box that says nothing about what to type in it.
Onboarding question | Classic SaaS | AI product |
|---|---|---|
What users must learn | Where things are | What to ask and how to judge the answer |
First empty state | Empty list or dashboard | Empty prompt box |
Value event | Created the first project | Kept the first useful output |
Main risk in session one | Confusion | A weak first answer that sets a bad impression |
What fixes it | Clear UI and sample data | Starting points, expectations and easy refinement |
Why is the blank prompt box an onboarding problem?
The blank prompt box is an onboarding problem because it asks users to describe what they want before they know what the tool can do. Usability researcher Jakob Nielsen has called this the articulation barrier: many people struggle to put a complex need into words, and a blinking cursor gives them no help.
The result is a predictable first session. Users type something vague, such as "help me with marketing", get a generic answer, and conclude the tool is generic. Or they test it with a trick question, see a mistake and leave. Neither tells them what the product is actually good at.
Treat the empty prompt as your most important empty state and design it like one. It should show what kind of request works, offer a few concrete starting points and make the first click easier than typing. The input can stay open for confident users; it just shouldn't be the only thing on the screen.
What should replace the empty prompt on first run?
On first run, replace the empty prompt with starting points tied to the user's job: starter prompts, templates or a one-click task that uses their own material. The best starting point produces a result the user would recognize as real work, not a demo.
- Role-based starter prompts: three or four specific requests matched to what the user said they do. "Summarize this week's support tickets by theme" teaches more than "Try summarizing something".
- Templates with blanks: a prompt with the structure filled in and only the specifics left to add, so users learn the shape of a good request by using one.
- Bring your own input: let users upload a document, paste a link or connect one source in the first minute, with a sample file for those who aren't ready.
- Show an example output: a short preview of what a good result looks like sets the bar before the user asks anything.
- One-click first task: for agent-style tools, a safe, reversible task the user can watch from start to finish.
To pick the right starter prompts, you need to know who's arriving. A one-question welcome screen asking about role or goal is often enough; our guide to welcome screens and onboarding surveys covers how to ask without adding friction.
How do you set expectations about AI output quality?
You set expectations about AI output quality by saying, early and in plain words, what the product does well, where it makes mistakes and what the user should check. Microsoft's Guidelines for Human-AI Interaction start with exactly this: make clear what the system can do, and how well it can do it.
Do it in context rather than in a terms-style disclaimer. A line under the input such as "Best for first drafts of support replies; check prices and dates before sending" does more than a generic "AI can make mistakes" footer, because it tells users where to look. For outputs built on sources, show the sources so users can verify without leaving.
Expectation-setting also covers time and cost. If a task takes a minute, show progress steps rather than a spinner. If the product runs on credits, show what the first task costs before it runs. Our guide to AI product UX covers transparency and control patterns in depth; onboarding is where users meet them first.
Hypothetical example: rewriting a first-run screen for an AI research tool
For example, suppose an AI tool that answers questions about a company's internal documents launches with a single input reading "Ask anything about your docs". New users ask broad questions before any documents are connected and get nothing useful.
A redesigned first run would do three things. First, ask the user to connect one source, with a sample folder available. Second, show three starter questions written from that source's actual contents. Third, add one line under the input: "Answers cite the documents they come from. If a source is missing, the answer may be incomplete." The interface barely changes; the first answer gets much more useful.
What counts as the first useful result in an AI tool?
The first useful result is an AI output the user acts on: they copy it, export it, send it, save it or accept the change it proposes. A prompt sent is not activation, and neither is a response generated. Only a response kept shows the product did its job.
Define this event before you design anything, because it decides which steps are allowed in the first session. If the value event is "accepted a drafted reply", connecting the inbox belongs in onboarding and configuring tone presets doesn't. Our guide to finding your aha moment shows how to identify the event from retained users' behavior, and time to value covers how to shorten the path to it.
Track the event alongside a quality signal. Retries, edits and thumbs-down on the first output tell you whether users reached a useful result or just a result. A first session with three retries before a copy is a session that nearly failed.
How do you design for a weak first answer?
You design for a weak first answer by making refinement faster than giving up. Some first outputs will miss, because model output varies and first requests are often vague. The question is whether the user knows what to do next.
Offer specific refinements
Suggest one-click follow-ups next to the output, such as shorter, more formal or focus on pricing, so users don't have to rewrite the request from scratch.
Make editing direct
Let users edit the output in place and keep their edits, rather than forcing another prompt.
Ask a clarifying question
When a request is too vague, ask one short question back instead of guessing broadly.
Keep undo obvious
If the AI changed something, a visible undo makes users willing to try again.
Collect lightweight feedback
A thumbs up or down with an optional reason tells you which first requests fail most often.
Review those failed first requests every week. They're the most direct input for better starter prompts and clearer expectation copy.
Should AI onboarding UX use product tours?
AI onboarding rarely needs a product tour, because the interface is usually simple and the hard part is the request, not the layout. A tour that points at the input box teaches nothing a good empty state can't. Spend that effort on the first output instead.
Contextual guidance works better: a hint the first time a user sees citations, a short note when they first hit a usage limit, a tooltip on the one control that isn't obvious. Our comparison of product tours vs contextual guidance covers the trade-offs, and if you're adding AI into an existing product rather than launching a new one, see adding AI to an existing SaaS product.
For teams building generative AI products, this is the work our product design service focuses on: the words, screens and states of the first session, designed together.
