Designing for uncertainty: interface patterns for AI products

Interface conventions encode assumptions about the systems behind them. A button performs one action. A form validates against known rules. A query returns the same result twice. Two decades of interaction patterns rest on determinism, and determinism is precisely what model-backed products do not offer.

Most AI products have not absorbed this. They attach a probabilistic engine to interfaces that promise certainty, and the mismatch surfaces as a trust failure: the product behaves confidently, is wrong at some nonzero rate, and users recalibrate by leaving. This entry catalogs the design consequences we treat as foundational when building AI products, along with the open questions we have not resolved.

1. Output is a proposal

The single most consequential reframe available to a design team: every model output is a proposal, not a result. Once stated, the design question changes. The problem is no longer how to present an answer but how a person verifies, edits, or discards one at minimal cost.

This is where AI products systematically underinvest. Generation receives the design attention while the review loop receives none, despite the review loop being where the user actually spends time. Accept, reject, regenerate, and refine are the primary interactions of an AI product. When those controls are an afterthought, the product functions as a slot machine, and users describe it in exactly those terms.

2. Latency is a material

Model latency is not an engineering inconvenience to be hidden behind a spinner. It is a material property of the medium, comparable to ink bleed in print, and it should be designed with rather than around.

Streaming is the standard mitigation, but streaming is only honest for some content types. Token-by-token display suits prose. It actively harms structured output, where a half-rendered table communicates less than a short wait. The design work is specifying what a user sees at three hundred milliseconds, at two seconds, and at ten, and making each state legible. A skeleton screen that implies imminent certainty the system does not have is a small lie, and users accumulate small lies.

3. Provenance calibrates trust

A hallucinated claim renders in the same typeface, at the same weight, with the same assurance as a correct one. The interface cannot distinguish them, because the model cannot. No amount of visual styling resolves this, and confidence scores presented as percentages perform worse in practice than designers expect, because users have no stable interpretation of what the number means.

What functions instead is provenance. Show where a claim originates. Make citations load-bearing rather than decorative. Give the product an explicit way to state that it is unsure, and design that state to read as honesty rather than failure. Users calibrate quickly in both directions: a product that hedges at the right moments earns latitude everywhere else, and a product that never hedges loses all of it the first time it is caught.

4. Constrained surfaces outperform open chat

An input that accepts anything is the easiest AI interface to ship and, in our assessment, usually the weakest. Open-ended input transfers the full burden of scoping to the user, who has no model of what the system is good at, and it maximizes the surface across which the product can fail.

The stronger pattern narrows the surface: constrain the input, structure the output, and let the model perform one task inside a shape the interface controls. The most effective AI features we have shipped do not read as chatbots at all. They read as ordinary features that happen to be unusually good at one thing. Chat remains the correct answer for genuinely open-ended work, which is a smaller category of product than the current market implies.

5. Transcript review is design research

On deterministic software, behavior could be reasoned about from specification. On model-backed products, the specification does not describe what the system actually does. Transcripts do.

Reading real sessions, constructing a taxonomy of observed failures, and deciding which failures the interface should absorb and which it should expose is design work, not quality assurance. It cannot be delegated entirely to an eval suite, because evals measure the model. The designer's subject is the experience of encountering a wrong answer, and whether the product survives it.

6. Open questions

We do not consider this catalog complete. We have no satisfying pattern for communicating partial confidence without numbers. Undo semantics for agentic actions that touch external systems remain unresolved, since a sent email cannot be regenerated. And the field lacks a shared vocabulary for degraded modes: what a product should become when the model behind it is having a bad day. These strike us as design problems of the same magnitude as the ones this entry addresses, currently owned by no one.

Conclusion

Uncertainty is not a defect to be designed away. It is the medium. The AI products that feel trustworthy are not the ones that hide the seams. They are the ones where someone decided, deliberately, where the seams should go.