AI UX Design: 8 Patterns for AI Features Users Trust

People trust an AI feature when it tells them what it can and can't do, shows what its answer is based on, lets them change or reject the result, and fails in a way that still gets them where they were going. Good AI UX design is mostly those four things, done consistently and on every screen.

That sounds obvious. It isn't how most AI features ship. The usual version is a sparkle icon, a text box and an output that looks equally confident whether it's right or badly wrong. Users try it, get burned once, and quietly stop.

Below are the patterns we reach for when designing AI products, each with a hypothetical example so you can picture it in a real interface. The examples are illustrations, not client work.

Why AI UX design is different from normal UX

Ordinary software is deterministic. Click "Export" and you get the same file every time. If it breaks, that's a bug.

An AI feature gives a different answer to the same question on different days. Some of those answers will be wrong, and wrong in a fluent, plausible way. So the job changes. You're no longer designing a happy path with a few error states bolted on. You're designing for an output that might be wrong, and making sure the user can tell and can do something about it.

Two well-known sets of guidelines say this better than most blog posts do. Microsoft's Guidelines for Human-AI Interaction, published at the CHI conference in 2019, open with "make clear what the system can do" and "make clear how well the system can do what it can do." Google's People + AI Guidebook (from its PAIR team) covers similar ground, with good chapters on mental models and on handling failure. Both are free. What they don't give you is screen-level detail, which is what follows.

1. Set expectations before the first use

Say you're adding an AI reply-drafter to a customer support tool. The agent opens a ticket and sees a "Draft reply" button.

What does that button promise? If it promises nothing, the agent's mental model fills the gap. Some will assume it knows the customer's order history. Some will assume it's just autocomplete. Both will be surprised.

Fix it in the first encounter, not in a help article nobody reads:

• One line under the button: "Drafts a reply from this ticket and your help centre. It can't see order or billing data."
• Example prompts or sample outputs in the empty state, so people see the ceiling and the floor.
• A plain label that this is AI-generated, every time, not only on first use.
• A short note on what to do when the draft is wrong: edit it, or write the reply yourself as usual.

The "can't" half matters more than the "can". Users forgive limits they were told about. They don't forgive limits they discover by being embarrassed in front of a customer.

2. Show what the answer is based on

Picture an AI search on an e-commerce site. A shopper types "waterproof hiking boots under 400 grams for wide feet" and gets six products.

Why those six? If the interface doesn't say, the shopper has to take it on faith. Instead, show the reasoning in their language: small tags on each result reading "Waterproof: yes (product spec)", "Weight: 380 g", "Wide fit: mentioned in 14 reviews". Now they can check the claim in two seconds, and they'll notice when one result only matches two of the three things they asked for.

For anything that summarises documents (policies or contracts, say) link each claim to the passage it came from. Clickable citations do more for trust than any amount of reassuring copy.

Should you show a confidence score?

Usually not as a raw number. "87% confident" means nothing to most people, and it implies a precision the model often doesn't have. Translate confidence into behaviour instead. When the system is sure, show the answer plainly. When it isn't, say so in words ("I couldn't find this in your documents; here's my best guess") or show two options and ask the user to pick. Low confidence should change what the interface does, not just add a percentage.

3. Keep the user in control: editable outputs and undo

Back to the support tool. The draft appears. Can the agent edit it inline, or do they have to copy it into the reply box first? Can they regenerate just the second paragraph? Can they make it shorter or more formal with one click?

Each of those is a small control, and together they decide whether the feature feels like a colleague or a vending machine.

A few rules we hold to:

• AI drafts, humans send. Anything that leaves the building (an email or a refund, for instance) needs an explicit human action. Start with suggestions and only add autonomy once you have evidence it's earned.
• Undo for every AI action. If the AI re-tagged 200 tickets, there's a single "Undo" that puts them all back. Not a support request.
• Keep the original. When AI rewrites a user's text, keep their version one click away.
• Make the AI's edits visible. Highlight what changed, the way a tracked-changes view does.

This is ordinary interaction design, the same craft you'd apply anywhere in a UI/UX design project. AI just raises the stakes, because the content changing under the user's hands isn't theirs.

4. Build feedback loops people will actually use

Thumbs up and thumbs down are fine. They're also the least useful feedback you'll collect, because almost nobody clicks them and those who do rarely say why.

Better signals come from what people already do. In the reply-drafter, the edits an agent makes before sending tell you far more than a thumbs-down would. Did they delete the last paragraph every time? Swap "Unfortunately" for "I'm sorry"? That's your feedback, and it costs the user nothing.

When you do ask, ask narrowly. After a thumbs-down, offer three or four quick reasons ("Wrong facts", "Wrong tone", "Too long", "Didn't answer the question") plus an optional comment. Then close the loop: if a correction changes future behaviour, tell the user. "Got it, I'll keep replies shorter for you" makes the feedback feel worth giving.

5. How do you design for AI errors?

Assume the AI will be wrong, decide in advance what "wrong" looks like for your feature, and design a specific recovery for each case. In practice: admit the limit in plain language, and give the user a next step that doesn't depend on the AI, which often means a human who can see the conversation so far.

Take a chatbot on a clinic's website. A visitor asks whether they can take ibuprofen with their blood pressure tablets.

The bad version guesses. The slightly less bad version says "I'm sorry, I can't help with that" and stops. The good version says something like: "I can't give medical advice about your medicines. A pharmacist or your GP can. Would you like the clinic's number, or to book a call?" Then it offers both as buttons.

Notice what that does. It sets a clear boundary and still keeps the visitor moving. If the visitor does choose to talk to a person, pass the conversation along so they don't have to repeat themselves. Nothing burns trust faster than a handoff that starts with "How can I help you today?"

Write these fallback messages before launch, alongside the happy-path copy. They're part of the product, and if you leave them to the model, it'll improvise.

6. Design the wait: latency and streaming states

AI responses take longer than a page load and vary a lot. A spinner that sits there for eight seconds feels broken.

Some options, roughly in order of preference:

1. Stream the output so text appears as it's generated. People start reading immediately and the wait feels shorter.
2. Show the steps for longer jobs: "Reading 12 reviews… Comparing sizes… Writing summary." This is honest about what's happening and gives the user something to check.
3. Let them leave. For anything over a few seconds, let the user keep working and notify them when it's done.
4. Always offer Stop. If the answer is heading somewhere wrong, the user should be able to cut it off and rephrase.

One accessibility note: streaming text can be noisy for screen reader users if every new word is announced. Announce once when the response starts and once when it finishes. (Our piece on accessibility in UX design goes further on live regions and focus.)

7. Be clear about privacy and data use

This is the pattern the popular guides skip, and it's often the one buyers ask about first.

Users want answers to a few blunt questions. What does the AI see? Is my data used to train anything? Who else can read this conversation? Can I delete it?

Answer them in the interface, at the moment they matter:

• In the support tool, a short line in the draft panel: "Uses this ticket and your help centre only."
• In a chatbot, a note before the first message about what's stored and for how long, with a link to the full policy.
• Before the user uploads a document, a sentence on whether it's kept after the session.
• A visible way to clear history, rather than a settings page three levels deep.

Then make sure engineering and design agree on the facts. If the interface says "not used for training", that has to be true of every model provider and every log in the chain. Getting this right is as much an AI development decision as a design one, so involve both teams early.

8. Know when not to use AI at all

Some features are worse with AI in them. Be willing to say so.

Skip AI, or keep it well away from the decision, when:

• A rule would do. If "orders over a set amount need approval" covers it, write the rule. It's cheaper, and it's always right.
• Users need the same answer every time. Pricing and eligibility are the obvious ones. Variation there is a defect.
• A wrong answer is expensive and hard to spot. Dosage or tax filings, for example. AI can help a professional check their work; it shouldn't be the one giving the answer to the public.
• The existing flow already works. If a three-field form takes ten seconds, a chat interface that does the same thing in a minute is a step backwards.

A useful test: describe the feature without the word "AI". If what's left is still worth building, AI might make it better. If nothing's left, you're adding AI for the press release.

What makes users trust AI products over time?

Consistency. Trust builds when the feature behaves the same way across many small uses and admits its limits each time it hits them. One impressive demo does very little. A hundred unremarkable, correct drafts and a couple of honest "I don't know" responses do a lot.

That's also why trust is hard to retrofit. Starting narrow and honest, then widening scope as the feature proves itself, beats launching big and walking it back.

Where to start

If you're planning an AI feature now, sketch the failure states before the success state. Write the "can't" line for your onboarding. Decide what the undo does, and who a confused user gets handed to. Those decisions will shape the feature more than the choice of model will.

If you want the wider context, our UX design process covers how research and testing fit around work like this, and AI in UX design looks at the flip side: using AI as a design team. For a quick check on an existing product, the UX audit checklist is a good first pass.

And if you'd like a second pair of eyes on an AI feature you're planning, you can see how we approach AI development or simply tell us about your project.