Designing AI features people actually trust

The first version of almost every AI feature I've seen fails the same way. The model is fine. The demo is impressive. Then real people use it, it's confidently wrong once, and from then on nobody believes it, even when it's right.

That's not a model problem. It's an interface problem. When a feature can't explain itself, people have two choices: trust it blindly or ignore it. Most of them pick ignore.

So when I build something with AI in it, I spend less time on the prompt than you'd think, and a lot more on the moments around the answer.

Show the work

An answer on its own is a claim. An answer with its sources is something you can check.

If the model read three documents to answer, show those three documents, and link each statement to the one it came from. People rarely click through. But knowing they could changes how much they trust the answer, and the times they do click are exactly the times it matters.

It also keeps you honest as a builder. If you can't show where an answer came from, that's usually a sign the feature shouldn't be giving it.

Say how sure it is, in words

Confidence scores are tempting, and "87%" looks precise. But nobody knows what 87% means for their decision.

Words work better. "Based on your last three reports" is stronger than "based on general guidance". "I couldn't find this in your documents" is better than a vague answer. When the evidence is thin, say so, and say it before the answer, not in grey text under it.

Design for the slow moments

AI is slow by interface standards. A good answer can take five or ten seconds, which feels like forever when you're staring at a spinner.

The fix isn't making it faster (though that helps). It's making the wait legible:

• Stream the answer as it's written, so the first words appear in a second.
• Show what it's doing: "Reading 3 documents…", "Comparing with last year…". Real steps, not a fake progress bar.
• Keep the page usable while it works. Nobody should be locked out of their own screen by a model thinking.

Make being wrong cheap

Every AI feature will be wrong sometimes. The question is what that costs the person using it.

If an answer is editable, a mistake costs a few seconds. If it's copied straight into a report, a mistake costs a lot more. So I lean towards drafts over decisions: the model suggests, the person accepts, edits or throws it away. Anything with side effects (sending, saving, changing data) gets an explicit confirmation, and an undo where possible.

Treat failure as a state, not an exception

The thing that helped me most was modelling an answer's life explicitly, so every state has a design:

type Evidence = "strong" | "partial" | "weak";
type Failure = "timeout" | "no-sources" | "error";
 
type Answer =
  | { state: "thinking"; step: string }
  | { state: "streaming"; text: string; sources: Source[] }
  | { state: "done"; text: string; sources: Source[]; evidence: Evidence }
  | { state: "failed"; reason: Failure; fallback?: string };

Written like this, "no sources found" isn't an edge case someone forgets. It's a state with its own screen and its own words, and probably a fallback, like a link to search the documents yourself. The type checker makes sure every state gets designed, not just the happy one.

The model is the easy part

The models will keep getting better. What won't change is that people need to know when to rely on them. That's an interface problem, and it's the part of AI work I enjoy most: the sources, the wording, the waiting, the undo. It's the same craft as any other interface. The stakes are just a bit higher.