Designing AI product UX: trust, waiting, errors and handoff

Most AI features are designed around the happy path: someone asks, a good answer appears. Real use is messier. The model takes twenty seconds. The answer is plausible and wrong. The agent stops halfway through a task. Those moments decide whether people trust the feature, and they’re usually designed last, if at all.

We build our own SaaS products, so we run into these moments ourselves. The patterns below apply whether you’re adding one AI feature to an existing product or building an agent that acts on someone’s behalf. For the other side of this, how we use AI inside our own design process, see Where AI belongs in a design workflow.

What should people see while the AI is working?

Waiting is the first moment, and the one people hit every time. A spinner says nothing about whether the product is working, stuck or about to fail. Good waiting states give people information and a way out.

• 01Show progress that means something (“Reading 12 files”), not just a spinner. Steps the user recognizes are more reassuring than a percentage nobody believes.
• 02Stream partial results when possible. Text that appears as it’s written feels faster than the same text all at once, and it lets people spot a wrong direction early.
• 03Let people keep working or cancel. Long tasks should run in the background and say when they’re done, and cancel should actually stop the work.

Set expectations before the wait starts. If a task usually takes a minute, say so on the button or right below it.

How do you show uncertainty in an AI product?

Any AI answer might be wrong. The design question is how to make that visible without burying every answer in disclaimers.

• 01Show sources and make them easy to check. A link to the exact passage, row or file beats a generic list of references.
• 02Signal confidence only where it changes what the user should do. A flag on the one field worth double-checking is useful; a score on every sentence is noise.
• 03Prefer “here’s a draft to review” over “here’s the answer”. Framing output as a draft invites people to read it, edit it and own it.

Raw confidence scores rarely help on their own. Most people can’t tell what 72% means for the task in front of them. Sources, review steps and draft framing do the same job in terms they already understand.

How should errors work in an AI product?

AI products fail in more ways than ordinary software. The request can be out of scope, the model can refuse, the answer can come back empty, or a plain old service can go down. People need to know which one happened, because the right next step is different for each.

• 01Separate “the AI couldn’t do it” from “something broke”. The first needs a different request or a different approach. The second needs a retry or a status update.
• 02Offer a next step: retry, edit the input, or do it manually. An error with no action is a dead end.
• 03Never blame the user’s prompt. “Try being more specific” pushes the model’s limits onto the person. Suggest a concrete rewrite or an example instead.
• 04Keep what they typed. A failed request should never wipe the input.

An AI error should end with something the user can do next, never with a lecture about prompting.

How do you design UX for an AI agent?

Agents raise the stakes because they act, not just answer. They send messages, change records, book things and delete files. The design has to make those actions visible before they happen and reversible after.

• 01Undo and edit for every AI action. If the AI changed something, people should be able to see the change and roll it back.
• 02Agents show what they’re about to do before high-stakes steps, and ask for confirmation. Show the plan in plain language, with the specific items it will touch.
• 03A clear path to a human or a manual mode. When the agent is stuck, or the user doesn’t trust it with this one, there should be an obvious way to take over.
• 04A readable log of what happened, so people can check the agent’s work after the fact.

Decide which actions need confirmation by what a mistake would cost. Drafting a reply can run freely; sending it to a customer probably shouldn’t. If everything asks for confirmation, people stop reading the prompts, and the one that matters gets clicked through with the rest.

How should AI onboarding set expectations?

Set honest expectations: what it does well, what it doesn’t, and an example that works the first time.

The first result shapes everything after it. If the first request fails, people decide the feature doesn’t work, and they rarely give it a second chance. Suggested prompts, templates or a prefilled example get them to a good result before they have to learn how to ask. Being clear about the limits up front also makes later errors easier to forgive, because nobody was promised otherwise.

A checklist for any AI feature

• 01What does the user see in the first two seconds after asking?
• 02Can they cancel, and does cancel stop the work?
• 03Can they check where the answer came from?
• 04Is the output framed as a draft when it should be reviewed?
• 05Does every error offer a next step and keep the input?
• 06Can every AI action be undone or edited?
• 07Does the agent confirm before high-stakes steps?
• 08Is there a visible way to reach a human or do it manually?
• 09Does the first example work every time?

If you’re shipping an AI feature and want these moments designed before launch, send your brief.

• AI
• Product
• UX