# The Uncertainty Pattern Library

> How a product says "I am not sure" without looking broken. Four moves, and the
> whole craft is picking the right one for the situation and the cost of being
> wrong. Most products default to one move for everything, which is why they read
> as either falsely confident or uselessly hedged.

---

## The four moves

Every expression of uncertainty is one of these. Nothing else is available.

**1. Show confidence.** Give the answer, attach a signal about how sure the system
is.
**2. Hedge the language.** Give the answer, soften the claim inside the words.
**3. Stay silent.** Show nothing rather than a weak answer.
**4. Ask.** Get the missing input from the user instead of guessing.

They are not interchangeable, and the choice is not about how uncertain the model
is. It is about what a wrong answer costs the person reading it.

---

## Choosing between them

| If being wrong costs... | And the user can verify... | Use |
|---|---|---|
| Little, and it is easy to spot | Easily | Hedge |
| Little, but hard to spot | With effort | Show confidence, with the source |
| A lot, and it is recoverable | With effort | Ask |
| A lot, and it is not recoverable | Not really | Stay silent, route to the human path |

The bottom row is the one teams get wrong. When the mistake is expensive and the
user cannot check the work, a confidence badge does not transfer the risk to
them. It just adds a decoration to a decision they cannot make.

---

## Pattern 1: Show confidence

**Use when** the user can verify the answer, and the signal changes what they do
with it.

**Forms, roughly in order of how much they are worth:**

- Cited source, opened in one action. The strongest confidence signal there is,
  because it lets the user do the checking rather than trusting a number.
- Coarse bands: high, medium, low. Useful when they change behavior.
- Numeric scores. Almost always worse than bands. A number implies calibration
  most systems do not have, and users read 73 percent as more precise than it is.

**Failure mode.** A confidence signal shown on every output, always in the same
place, becomes furniture within a week. Nobody reads a badge that is always
there. Show it when it is low, not when it is high.

**Rule of thumb.** If your confidence display would look identical on a great
answer and a mediocre one, it is not communicating, it is decorating.

---

## Pattern 2: Hedge the language

**Use when** the cost of being wrong is low and the hedge changes how the user
reads the sentence.

**Copy that works:**

- "Based on the last thirty days" rather than "Your usage is."
- "This looks like a duplicate" rather than "This is a duplicate."
- "I found two possible matches" rather than picking one silently.

**Copy that does not work:**

- "I might be wrong, but" attached to everything. Universal hedging is the same
  as no hedging, and it reads as an apology rather than information.
- Passive constructions that hide who is unsure. "It has been determined" is
  worse than being wrong plainly.

**Failure mode.** Hedged language on an answer the user cannot check. The hedge
transfers responsibility without transferring the ability to act on it.

---

## Pattern 3: Stay silent

**Use when** a weak answer is worse than no answer. This is underused, and it is
the pattern that separates products people trust from products people
double-check.

**What silence looks like in practice:**

- The suggestion simply does not appear, and the manual path is right there.
- The section renders with a plain "not enough to go on yet," and one action that
  would change that.
- The feature stays available and returns nothing, rather than disappearing.
  Disappearing controls make people think the product is broken.

**Failure mode.** Silence with no explanation and no path forward. An empty state
that does not say what would fill it reads as failure, not restraint.

**Rule of thumb.** Silence needs a sentence. Not an apology, a next step.

---

## Pattern 4: Ask

**Use when** one missing input is doing all the damage, and the user has it.

**What makes an ask good:**

- One question, not a form. If you need three things, ask for the most
  load-bearing one and try again.
- Show the work already done before asking. A question that arrives with no
  account of progress reads as the system starting over.
- Offer a default that is honest. "Assume last quarter" is a good default.
  Pre-selecting the answer you want is not.

**Failure mode.** Asking as a reflex. A product that asks whenever it is
uncertain is a product that has moved its uncertainty onto the user's calendar.
Ask once, remember the answer, and do not ask again for the same surface.

---

## The library table

Fill this in for your product. One row per surface. This is the artifact.

| Surface | Cost of being wrong | Can the user verify? | Pattern | Exact copy |
|---|---|---|---|---|
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |

The last column matters more than it looks. Uncertainty is expressed in words
almost every time, and if design does not write those words, they get written by
whoever is closest to the code at eleven at night.

---

## Three things to never do

Never express uncertainty with visual weight alone. Greyed-out text is not a
confidence signal, it is an accessibility problem.

Never let the uncertainty state be less designed than the confident state. The
uncertain path is the common one in a generated product, and it is where trust is
actually built.

Never apologize twice. One acknowledgment, then the path forward. Repeated
apology reads as a system that knows it is unreliable and has decided that is
your problem.

---

## The one thing to do this week

Take the surface where your product is most often uncertain. Write the exact copy
for all four patterns, then pick one and delete the other three. The deletion is
the design decision, and writing all four first is what makes it a decision
rather than a default.

---

_From "The Shape of Uncertainty", chapter 6 of The Design Operating Model._
_falkster.com/design/the-shape-of-uncertainty_