A model with 94% accuracy is wrong roughly once every sixteen times. If your interface presents every output with identical confidence, users will meet that sixteenth case, and from then on they will discount all sixteen.
This is the central design problem in AI products, and it is not solved by making the model better. A 99% model is wrong once every hundred times, and a user who cannot tell which time it is still has to check all hundred.
Uncertainty is a design surface
The useful question is not "how do we hide that the model is uncertain" but "how do we put uncertainty where the user can act on it."
A few patterns that hold up in practice.
Show the evidence next to the conclusion
An answer alone is unverifiable. An answer with its sources is checkable in seconds. This is why citation-first interfaces outperform confident-summary interfaces even when the summaries are equally accurate — the user is not reading the citation, they are reading the fact that there is one.
The cheap version of this is a link. The good version highlights the specific span of the source that produced the claim, so verification costs a glance rather than a page of reading.
Bands beat percentages
"87% confident" reads as false precision to most people, and as noise to the rest. In user testing we consistently see people round anything above 80% to "yes" and anything below to "no," which discards the entire signal.
Calibrated bands work better because they carry a meaning rather than a number:
- Strong — many similar cases in training, historically reliable here
- Mixed — features disagree, worth a closer look
- Sparse — little comparable data, treat as a prompt rather than an answer
The third band is the one teams resist shipping and the one users value most. Admitting the model is out of its depth is what makes the other two bands credible.
Make disagreement cheap
If accepting a suggestion is one click and rejecting it is a modal with a required reason code, you have not built a feedback loop. You have built a compliance funnel, and the data coming out of it is worthless.
Symmetrical cost is the rule: rejecting should take exactly as long as accepting. Ask for a reason, make it optional, and accept free text. You will get more structured feedback this way, not less, because people who were previously avoiding the interaction entirely will now engage with it.
Latency is a trust signal
Streaming changed what users expect, but it also created a new failure mode: an interface that streams confidently and then contradicts itself three sentences in.
Some rules we apply:
- Never stream a verdict you might retract. Stream the reasoning, then commit to the conclusion. Reversing a rendered answer is worse than a slower answer.
- Show the shape of the wait. "Searching 1,240 documents" beats a spinner, not because it is faster but because it is falsifiable — the user can tell whether the system is doing something plausible.
- Budget for the p95, not the median. AI features have long tails. An interface that feels good at 800ms and broken at 6s will be remembered as broken.
The interaction nobody designs
Almost every AI feature ships without a designed answer to: what happens after the user notices it was wrong?
Not the error state — the model returning something plausible and incorrect is not an error, it is normal operation. The question is whether the user has a path from "this is wrong" to "the system knows it was wrong and I can move on."
Without that path, the user's only option is to stop using the feature. Which is what most of them do, quietly, and it does not show up as an error in any dashboard.
What this costs
Designing for uncertainty makes the happy path slightly worse. Citations take space. Bands are less satisfying than a big number. An easy reject button will be used.
That trade is worth making, because the alternative is not a cleaner interface — it is a feature users abandon after the first time it burns them. A product that is honest about being wrong 6% of the time gets used for the other 94%. A product that pretends to be certain gets used until the sixteenth case, and then not at all.
Related reading
Design tokens that survive a rebrand
Most token systems break the first time the brand changes. The fix is a layer most teams skip — and it costs about a day to add.
Your component API is a contract, so write it down
Variant tables, prop naming and the boolean that should have been an enum. Notes from maintaining component libraries other people have to use.
Dense tables that stay readable
Row height, alignment, tabular figures and the filter model. What actually makes a 40,000-row table usable rather than merely displayable.
One useful email a month
Design system patterns, front-end techniques and case study breakdowns. No promotions, no digest of other people's links.