Designing for Uncertainty

I The UX Problem with AI

Traditional software is deterministic. Click "Calculate Total" and you get the same number every time. The search bar returns the same results for the same query. Buttons do what their labels say. Users have spent decades building mental models around this predictability, and for good reason: it works.

AI breaks that contract. The same prompt can produce different outputs on different runs. Quality varies from brilliant to embarrassingly wrong within the same session. The model might confidently hallucinate a fact, hedge on something it actually knows, or refuse a perfectly reasonable request because a guardrail misfired. And the trust problem runs deeper than individual interactions: Stanford HAI's 2026 AI Index found that 73% of AI experts expect positive job impact, but only 23% of the general public agrees — a 50-point gap between the people building AI products and the people using them.

This creates a design problem that most product teams wildly underestimate. You are shipping a feature whose output you cannot fully predict.That's not a minor UX wrinkle — it's a foundational break from how software has worked for decades. The happy path is easy to design. The challenge is everything else: how does the user know when to trust the output? What happens when the model is wrong? How do you communicate uncertainty without undermining confidence in the product?

Four design patterns help you navigate this: confidence signals, progressive disclosure, transparent loading states, and AI-specific error handling. Together they form the toolkit for AI UX that earns trust rather than demanding it.

II Confidence Signals

When a doctor says "I think this is a migraine," the word "think" is doing important work. It tells you this is a judgment, not a lab result. It invites you to ask follow-up questions. It sets expectations for what comes next.

AI responses need the same kind of calibration. Without confidence signals, users default to one of two extremes: they either trust everything the model says (dangerous) or trust nothing (useless). Neither serves your product. Anthropic's own usage data bears this out: new users auto-approve only about 20% of agent actions, while experienced users with 750+ sessions approve over 40%. Trust grows with exposure, but even power users still override the majority of the time. Confidence signals accelerate that trust curve by giving users something concrete to calibrate against.

The design space for confidence signals spans a wide range:

• No signal. The response appears as plain text, with no indication of certainty. This is the default for most AI products today, and it is the most dangerous — it implicitly frames every output as authoritative.
• Subtle visual indicators. A colored icon, a small badge, a background tint. Low-friction signals that nudge without interrupting. Best for low-stakes contexts where the user just needs a gentle heads-up.
• Explicit confidence. A percentage, a written caveat, highlighted uncertain phrases. High-information signals for high-stakes domains where the user genuinely needs to evaluate trustworthiness.

The right choice depends on two factors: your audience and the stakes. A casual writing assistant can get away with no signals. A medical triage tool cannot. A developer tool might show confidence scores that a consumer app would hide behind simpler language.

See how the same response feels different with each approach:

The response text is identical in all three modes, but the user's relationship with it changes fundamentally. The first invites blind trust. The second introduces a moment of pause. The third provides enough context for the user to make an informed decision about what to do next.

For most product teams, the subtle icon approach is the right starting point. It is low-effort to implement, causes minimal friction for the majority of correct responses, and meaningfully changes user behavior when the signal is amber or red. Graduate to explicit confidence when user research shows people need more granularity, or when your domain demands it.

III Progressive Disclosure

AI models can generate a lot of output. A summarization model might produce a one-sentence answer and a three-paragraph explanation. A research agent might return a conclusion, its reasoning chain, ten source documents, and a list of caveats. Dumping all of this on the user at once is overwhelming and counterproductive.

Progressive disclosure solves this by layering information in order of importance. Show the answer first. Let the user drill into the reasoning if they want it. Bury the sources and caveats behind a toggle for the skeptical few who need them.

The layered reveal pattern works especially well for AI because it handles uncertainty gracefully. A confident response might only need one layer — the answer is clear and needs no qualification. An uncertain response can progressively reveal its reasoning, alternative interpretations, and sources, letting the user decide how deep to go.

Three rules make progressive disclosure work in AI products:

1. Lead with the answer, not the process.Users asked a question. Answer it. Don't start with "I analyzed 47 documents and considered 12 factors..." — that's the model being performative, not helpful. Nobody asked to watch it think.
2. Make expansion effortless.A single click or tap to see the next layer. No page navigation, no modal dialogs, no "Show More" buttons that reload the page.
3. Label each layer clearly."Sources," "Reasoning," "Caveats" — the user should know what they will see before they expand.

IV Loading States That Don't Lie

A generic spinner with "Loading..." tells the user exactly one thing: something is happening. That's barely more informative than a blank screen. For a database query that completes in 200ms, fine. For an AI process that takes 5–15 seconds, it's a recipe for frustration, tab-switching, and the quiet conviction that your app is broken.

Multi-step AI processes — document analysis, research tasks, complex reasoning — take significantly longer than traditional web requests. Users have been conditioned to expect sub-second responses. When you cannot deliver speed, you must deliver transparency.

Progress indicators reduce perceived wait time by up to 40%.The actual time is identical. The experience is fundamentally different. A user who sees "Reading your document... Identifying key themes... Generating summary..." feels like progress is being made. A user staring at a spinner feels like the app might be broken.

Compare the two approaches side by side:

The implementation cost is low. Most AI pipelines already have discrete stages — document parsing, embedding retrieval, generation. Surfacing those stages to the user is a small frontend change with outsized impact on perceived quality.

One caveat: do not fake the stages. If your process is genuinely a single model call with no intermediate steps, a well-designed skeleton loader or streaming text output is more honest than fabricated "Analyzing..." messages. Users will notice if Stage 3 always takes exactly the same time regardless of input. Fake progress is worse than no progress — it breaks the very trust you're trying to build.

V Error States for AI

Traditional software has a small taxonomy of errors: network failed, permission denied, resource not found, validation failed. Each has a well-understood UX pattern. AI introduces failure modes that most design systems have never encountered.

An AI feature can fail in at least four novel ways:

1. Timeout. The model took too long to generate a response. This is different from a network timeout — the request may have partially completed.
2. Hallucination detected. A self-check or grounding system flagged the response as potentially containing fabricated information.
3. Low confidence.The model produced output but assigned it very low confidence, below your product's threshold for showing results.
4. Content filtered. A safety guardrail blocked the response. The model may have had a perfectly good answer, but a policy rule prevented delivery.

Each of these requires a distinct error UX. A generic "Something went wrong" message is not just unhelpful — it actively erodes user trust by making every failure feel the same. The user cannot tell whether the system crashed, whether their request was bad, or whether the AI simply was not confident enough to respond.

Test your instincts — for each failure scenario, pick the best error UX:

The pattern is consistent across all four scenarios. The worst approach gives no context and no next step. The middle approach explains what happened but still leaves the user passively waiting. The best approach explains, offers agency, and turns a failure into a choice the user can make.

This matters more than you might think. Users who encounter a thoughtful error message are significantly more likely to retry, more likely to complete their task, and — critically — more likely to trust the product's correct outputs in the future. A product that handles failure well is perceived as more reliable than a product that never shows you when it fails.

VI What's Next

You now have four design patterns for AI products that earn trust instead of demanding it: confidence signals that calibrate expectations, progressive disclosure that respects attention, loading states that communicate progress, and error handling that turns failures into choices.

But here's the deeper question these patterns raise. In high-stakes domains — medical diagnosis, financial advice, legal analysis, content moderation — no amount of clever UX removes the need for a human to verify, approve, or override the AI's output. The best confidence badge in the world doesn't help if the stakes are someone's health or livelihood. The trust problem has three distinct layers: user comfort (will individuals accept the output?), organizational governance (can the company defend the deployment to regulators?), and public trust (does society believe this should be automated at all?). Good uncertainty UX addresses the first layer, but the other two require something different entirely. So when should you keep humans in the loop? Where should the handoff happen?

That's Part 2: When to Keep Humans in the Loop.