Designing AI Features People Can Trust

Every AI feature I've worked on reaches the same moment. The demo looks magical, everyone nods, and then a real person tries it on a real task and the first wrong answer lands. What happens in the next ten seconds decides whether they ever use it again.

The thing I keep relearning is that the goal isn't maximum trust. It's calibrated trust. People should lean on the AI when it's likely to be right and slow down when it isn't. Good design is how they tell the difference.

Set honest expectations before the first prompt

Most trust problems start before anyone types a word. A shiny button with a sparkle icon that says "Generate" promises something the model can't always deliver. When the result falls short, it doesn't feel like a limitation. It feels like a broken promise.

I try to swap the magic wand for a plain description of the job. Not "Write it for me" but "Draft a first version you can edit." Not an empty text box but a few example requests that show what works well, and quietly hint at what doesn't.

• Say what it's good at. Summaries, first drafts, rewording. Be specific.
• Say what it can't see. If it has no access to files outside this project, tell people up front.
• Say what happens next. Will it change anything on its own, or only suggest?

The same honesty applies to every label after that. "Suggested" instead of "Correct". "Draft" instead of "Final". A clear tag on generated content, especially anything that might be shared with someone else. And a bit of restraint with personality: "I think" can soften a guess, but a chirpy "Happy to help!" adds nothing when the answer is wrong.

Show your work: sources and confidence

A confident tone is not the same as a correct answer, and language models are very good at the tone. So the interface has to carry some of the honesty the text can't.

Sources are the strongest tool here. If an answer is built from documents, link the exact passage, not just the file name. Most people won't click every citation, but knowing they could changes how they read. The ones who do click catch mistakes early.

Confidence is trickier. A raw percentage looks precise but means very little to most people, and model confidence often isn't well calibrated anyway. Plain signals tied to what the system actually did tend to work better: "Based on 3 of your documents" versus "No matching sources found, this is a general answer." The first tells you what to check. The second tells you to check everything.

Design the failure, not just the happy path

AI features fail differently from regular software. A form either submits or shows an error. A model can return something fluent, plausible and wrong, with no error at all. So the failure states deserve as much design time as the happy path, maybe more.

When it can't help

Let it say so. "I couldn't find that in your notes" beats an invented answer every time. Then offer a next step: rephrase, add context, or do it manually.

When it gets it wrong

Make correction cheap. Regenerate is fine, but editing the output directly is better, because it keeps the parts that were right and fixes only the parts that weren't.

When it's slow

Latency is a trust signal too. A spinner that runs for fifteen seconds feels like something broke. Streaming the response as it's generated, or showing honest progress steps like "Reading 4 files" and "Drafting summary", tells people the system is working. It also lets them stop early if it's clearly heading the wrong way. A visible Stop button is one of the most underrated controls in AI interfaces.

Keep the human holding the pen

The quickest way to lose someone's trust is to change their work without asking. The quickest way to earn it is to make every AI action easy to inspect and easy to reverse.

• Preview before apply. Show a diff or side-by-side before anything gets overwritten.
• Undo that actually works. One step, every time, including bulk changes.
• Edit, don't just accept or reject. Treat suggestions as drafts, not verdicts.
• Override without a fight. If someone dismisses a suggestion, stop resurfacing it.

This is where my engineering side gets loud. Undo for AI actions is rarely free. If the model renames forty layers or rewrites a whole section, the previous state has to live somewhere. Plan for that in the first sprint, not after the first bug report from someone who lost an hour of work.

Test with real tasks, not demo prompts

Demos are curated. Real use is messy. The prompts in a review meeting are usually the ones the team already knows work, which tells you almost nothing about trust.

When I evaluate an AI feature, I try to put it in front of people with their own material and a task they genuinely need to finish. Then I watch for the small moments:

• Do they read the output, or accept it on sight?
• Do they notice when it's wrong?
• How long does it take them to recover?
• Do they come back the next day, or quietly go back to doing it by hand?

Over-trust is as much a problem as under-trust. If people stop reading the output, that isn't a success metric. It's a risk waiting for the wrong answer.

Trust isn't a feature you add at the end. It's the sum of many small, slightly boring decisions: a clearer label, a working undo, a source link, an honest "I don't know." Get enough of those right and nobody misses the magic wand. They just find the thing useful, which is better.