Test Your Error States by Causing the Errors

Foundations & Process · process, errors, checklists

Updated 2026-08-04

Trigger the failure on purpose instead of waiting to see it in production. Error states are the least reviewed screens in most products because nobody has a reliable way to reach them.
Build a way to force each failure in a development build. A state that can only be reached by unplugging a router will not be reviewed, refined, or translated.
Work through the failures a real system produces:

Run the same list at the sizes that break layouts. Zero results, one result, and ten thousand results are three different designs.
Check every error state for the things that make it usable: a plain explanation, one clear next step, the user's work preserved, and a reference support can trace.
Watch what happens after recovery, not only during failure. Returning from offline should restore the screen rather than leave it frozen in the state it failed in.
Put the failure states in the design review alongside the happy path. A review that only sees the success case has reviewed a fraction of the product.
Do it before launch, at a small scale, on purpose. The alternative is doing it at full scale, by accident, in front of everyone.

Every product has error states, and the only question is whether they were designed or discovered.