Designing for AI uncertainty
A model is a probability distribution. A chat bubble is a confident sentence. Most of the work of designing AI products is closing that gap.
Here’s the same query, answered three ways. The underlying knowledge is identical. The design of the response is doing all the work:
No signals. Sounds authoritative. The user has no way to tell whether the model is right, stale, or guessing.
Only one of those is safe to ship. The other two are the same response with different framing, and the framing is the product.
Confidence is a design decision, not a model output
Every model has access to its own uncertainty. Token probabilities, retrieval scores, tool-call failures, recency of training data. By the time the answer reaches the user, that signal has been flattened into a sentence that reads like fact.
The design choice is: which of those signals do we keep, and how do we show them? A confidence pill. A data-cutoff footnote. A yellow underline on the part that’s weakest. A button that says “verify.” Each is a tax on the writing, and each is a gift to the reader.
The three treatments have different failure modes
Confident is the default when nobody on the team has thought about it. The model says something, the UI wraps it in a bubble, ship it. The failure mode is silent: a user acts on a hallucination and finds out later.
Calibrated is what teams reach for first. Add a confidence score, add a source, add a cutoff date. It works, but it costs visual weight. If every response carries three signals, every response reads like a disclaimer. The failure mode is noise.
Hedged is the most design-engineering answer. The voice does the work. The response says “I’m not sure” in plain words and offers the user a concrete next step. No new UI. The failure mode is scale: it’s hard to apply consistently when the response is generated, not written.
In practice, you want all three. Confident for things the model knows (facts with short shelf life and high priors). Calibrated for things it’s unsure about but still useful. Hedged for anything it shouldn’t answer at all.
The signals that carry weight
Five patterns do most of the work. Pick two, not all five:
- Confidence pill. Green, amber, red. Place it near the response, not floating in a sidebar. Colour is doing a lot, so make sure it passes contrast in both themes and has a text label for colour-blind users.
- Data cutoff. One line. “Trained through October 2024.” It’s the cheapest honesty signal available.
- Inline source. Link the claim, not the bibliography. A citation under the response is ignored. A link inside the sentence gets followed.
- Verify action. A button the model suggests itself. “Check apple.com,” “Run this query,” “Open the doc.” Turns uncertainty into a next step.
- Hedge words in voice. “I’m not sure,” “likely,” “based on what I can see.” Cheap. Scales through the prompt.
The hardest design problem is the refusal
“I don’t know” is the single hardest response to design. The model has been trained to avoid it, the UI has been designed around the assumption that a response fills the bubble, and the user is holding their breath for an answer.
Three things make a refusal land:
- Name what you don’t know. Not “sorry, I can’t help”, but “I don’t have live calendar data.” Specificity is what separates a refusal from a wall.
- Offer the next step. A button, a link, a suggested tool call. “Want me to check?” The refusal becomes a handoff.
- Keep the voice warm. The user’s mental model is that they’re talking to a thing that can help. A cold refusal breaks that. A warm refusal with a handoff preserves it.
Most chat products get this wrong in the same way: they refuse with apology, not with specificity. “Sorry, I can’t do that” is the interface equivalent of a shrug.
The prompt is UI
The hedged response up top isn’t rendered by the frontend. It’s shaped by the system prompt telling the model how to behave under uncertainty. That prompt is a design artifact, not just an engineering one.
A system prompt I’ve used, roughly: “If you’re not at least 80% sure, say so. Offer a tool you could use to verify. Don’t apologise.” Three sentences, shipped everywhere. Cheaper than building a confidence pill component and more consistent.
Design engineers are well placed for this: we can write both the prompt and the component that catches the prompt’s output. The two have to be designed together or the UI and the voice drift apart.
Calibration is the thing
Accuracy is a number the model hands you. Calibration is the design problem of making that number visible in a way the user can act on. Every AI product is either calibrated or lying.
The good news: the patterns aren’t complicated. A pill, a cutoff, a source, a verify button, hedge words in the voice. Pick two. Ship. The bar is embarrassingly low and most products don’t clear it.