Design the failure state first
Tags: errors, empty states, trust
In a product built on a model, the interface is decided by what happens when the answer is wrong — not by what happens when it's right. So draw that screen first. The same input can produce a different output tomorrow, so there is no single correct screen to design: there is a distribution, and the job is to make the whole distribution survivable.
Design the happy path first and bolt error handling on afterwards, and you get a product that is confident exactly when it shouldn't be.
Wrong is not one thing
"The model failed" collapses at least five different situations that need different interfaces. Treating them as one error state is why so many AI features have a single grey box.
| Failure | What the user actually gets | The design that holds |
|---|---|---|
| Confidently wrong | A plausible, well-formed, incorrect answer | Make checking cheaper than trusting — citations that resolve, the source passage inline |
| Nothing to say | An empty or refused result | An empty state that says why and offers the next move, not a shrug |
| Slow | A long wait with no signal | Stream partial output; always offer cancel |
| Did more than asked | An unrequested change to their work | Undo, not a confirmation dialog |
| Saw what it shouldn't | Sensitive data sent to a model | Prevent at the input, never at the output |
The last row is the one people get wrong most often, and it is where this stops being a slogan.
The decision
Two questions, in order. The first sorts recoverable failures from the one kind that isn't. The second stops the cure being worse than the disease.
The failure you cannot undo
Most failure states are recoverable. A wrong answer can be corrected, a slow one waited out, an unasked change reversed. Data leaving the machine is not in that category — once a confidential document has been sent to a third-party model, no interface fixes it afterwards.
That is why the fifth row says prevent at the input. For an unrecoverable failure the design work happens before the model is reached, not in the presentation of what it returned.
Grounded in
DocRobot, an enterprise AI workspace for teams working with confidential documents. The blocker to adoption was never accuracy or speed — legal and security would not permit the documents anywhere near a hosted model. The failure state the model sees something it must not had to be impossible rather than merely handled.
So redaction became the first step in the flow rather than a setting somewhere in preferences. In the first working version that was manual search-and-replace, which is slow and unglamorous, and it was still the thing that let a security review pass. Designing that failure first produced a different product, not a safer version of the same one: from the happy path — upload, ask, get an answer — redaction would have arrived late as a settings toggle, and the review would have killed it.
How you know it worked
Failure design is the part most likely to be quietly wrong, because nobody demos it. Two habits keep it honest.
- Write the failure cases down as examples before you build, with the actual bad output pasted in. A wrong answer you have written down is a design brief; a wrong answer you imagine is a reassurance.
- Build an evaluation loop early enough to tell you whether a change helped. The behaviour is a distribution, and improving one case routinely degrades another. Without measurement, teams tune prompts by anecdote and call it iteration.
Anti-patterns
- The single grey box. One error state standing in for five different situations, so none of them gets the interface it needed.
- Hedged into uselessness. Confidence indicators on every sentence, warnings stacked on warnings, a confirmation before anything happens. That isn't trustworthy, it's tiring — and it pushes the judgment back onto the user, which is what they came to the product to avoid.
- Failure handling that taxes success. Citations cost nothing when the model is right; they sit there quietly and pay off when someone checks. A modal asking "are you sure?" costs something on every single interaction.
The test
Does the failure design cost anything when the model is right? Undo is nearly free. Confirmation is a tax on the common case. Design the failure state first — then make sure it disappears when nothing has failed.
Related patterns
- Mark what the product vouches for — the interface half of "confidently wrong."
- Undo over confirm — the answer to "did more than asked."
- Redaction moves to the export — where the unrecoverable failure goes once the model is local.
- Evaluation loops — how you find out the failure design works.
The full argument: Design the failure state first.