Designing for Uncertainty and Errors

Your AI feature will be wrong. Not occasionally and not only on edge cases: on some fraction of ordinary requests, it will produce an answer that's incomplete, out of date, or confidently invented. Principles of AI UX covered designing for that fact in general. This one is about the specific moments where it happens.

There are two moments to design. The first is before the user knows whether the output is right: what can the interface tell them about how much to rely on it? The second is after something has gone wrong, whether that's a bad answer, a refusal, or a request that timed out. In this lesson you'll replace vague confidence scores with signals you can actually measure, build a three-level review system for Deskmate's drafted replies, show sources in a way people use, and write error states that keep users moving.

Why a confidence percentage doesn't help#

The tempting design is to ask the model how confident it is and show the number: "Confidence: 92%." It looks rigorous. It rarely helps, for two reasons.

First, a model's self-reported confidence is a guess, not a measurement. When you ask for a number, you get text that looks like a probability, produced by the same process that produced the answer. It can be high on wrong answers and low on right ones, and you have no way to know how well it tracks reality for your feature without measuring it yourself.

Second, even an accurate number doesn't tell users what to do. Is 78% good enough to send the reply? Should they check the whole thing or one sentence? A number pushes the hard judgment back onto the user without giving them anything to act on.

What users can act on is concrete: "this sentence isn't backed by a help article," "the customer asked two things and the draft answers one," "no article covers this topic." So instead of displaying confidence, compute signals in code and turn them into specific, actionable states.