Every AI feature demo shows the good case. The model understands, the answer appears, the user is delighted. Ship it, and users spend a meaningful share of their time in the other case — the answer that is plausible and wrong, or the one that never comes.
That case is where the interface is actually designed, and it usually isn't.
Confidence is a design decision, not a number
Showing a raw confidence score to a user rarely helps: nobody knows what 0.72 means, and it invites false precision. What helps is the interface behaving differently at different confidence — presenting one answer when it is sure, options when it is not, and a question when it has nothing.
The failure mode to avoid is a product that renders every output with the same typographic certainty. If a guess looks exactly like a fact, users learn to distrust both.
Make correction cheaper than starting over
When the model is wrong, the user has three options: fix it, redo it, or leave. Most interfaces only make the third one easy.
- Keep the input visible next to the output, so adjusting is one edit rather than one retype.
- Let a partial result be kept. Rejecting the whole answer to fix one paragraph is why people go back to doing it manually.
- Record the correction. If the same fix has to be made twice, the product is not learning and the user notices before your metrics do.
Waiting is part of the interface
Generation takes time, and a spinner spends that time telling the user nothing. Streaming output, showing which step is running, or naming the sources being read all convert dead time into evidence that something sensible is happening. It also makes a slow answer feel like work rather than a hang.
Transparency has a floor and a ceiling
Users need to know enough to judge an answer — where it came from, what it did not see, what it is not allowed to do. They do not need the architecture. The useful test is whether someone could tell a colleague why they trusted the output. If the only available answer is "the AI said so", the interface has not given them enough.
Design the wrong case first
Wireframe the empty state, the low-confidence state, the refusal and the timeout before the happy path. The happy path mostly designs itself. Everything that determines whether the feature survives contact with real users lives in the other four.
