The Uncertainty Pattern Library
Every expression of uncertainty is one of these. Nothing else is available.
The template
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