Designing for uncertainty in AI features
By Allan Leone on
Most AI features ship with one visual state: confident. The model is wrong some of the time and the interface looks identical either way, which quietly transfers the whole verification burden to the user.
A feature that is right 90% of the time and presents everything with the same certainty is worse than one that is right 70% of the time and tells you which is which. That sounds wrong until you think about what the user is actually doing.
Their job was never reading the output. It is deciding whether to trust it. If the interface gives them nothing to decide with, they have to verify everything, and a tool you fully verify has saved you nothing.
Confidence is a design surface, not a model property
Teams tend to treat confidence as something the model either exposes or does not, and then stop. But most of what a user needs is not a probability score. It is a set of cues about where the answer came from.
- Retrieved versus generated. If part of the answer is quoted from a real document and part was written, those should not look identical.
- Coverage. Was this drawn from twelve sources or one. That difference matters more to a reader than a percentage.
- Recency. An answer built from a document last updated in 2019 deserves a mark.
- Disagreement. If the sources conflict, saying so is more useful than silently picking one.
Making "I don't know" a real state
In most products, low confidence falls through to the error path or, worse, to a confident guess. Neither is designed. Both are the absence of a decision.
A designed version looks different: it says what it could not establish, shows what it did find, and offers the next action. "I could not find a stated refund window for this plan. Here are the two policy documents I searched. Ask the account team?" That is a useful answer even though it answers nothing.
Correction has to stick
If a user fixes a wrong output and the same error returns next session, they stop correcting and start distrusting. The loop matters more than the accuracy rate, because it is the part the user can feel working.
Showing that a correction persisted is a small piece of interface with a disproportionate effect on whether people keep using the feature.
Where to start
- Find every AI output in your product and ask what its low-confidence state looks like. If the answer is "the same", you have a design gap rather than a model gap.
- Add source attribution inline, next to the specific claim, not in a footer. Footers do not get read.
- Write the copy for "I could not determine this" before you build the feature. It is harder than it sounds and it shapes the rest.
- Instrument corrections. If you cannot see how often users override the output, you cannot tell whether trust is improving.
Tags: ai, ux, trust