Error State

Failure is certain to happen and the screen for it is routinely skipped. Design only the path where everything works, and at the moment something breaks the screen says nothing at all.

A request to load the document list at Pagedeck failed for several minutes once. Where the list belonged, the screen was simply blank. Of the eleven support messages that arrived in those minutes, nine said the documents were gone. The data was untouched — only the request to fetch the list had failed — but the screen never communicated that difference, so people assumed the worst. Failed states got drawn as their own screens after that.

Three things have to be on the screen for this state to do its job: what failed, why, and what to do now.

1. Name what failed specifically. "Something went wrong" supplies none of the three. "We couldn't load your documents" goes in the same space and supplies the first.
2. Split causes into ones the user can fix and ones they can't. A file over 20 MB is fixable by the person holding it; a server fault isn't. Give the second kind a user action and people go and change the wrong thing.
3. Put the next action in a button. Retry covers most cases, with a route to support behind it when retrying doesn't help. The same outage produces different support volumes with and without that button.
4. Match the position to the scope of the failure. A whole screen failing goes in the centre of the screen; one row of a list failing goes on that row; an invalid field goes directly under that field.
5. Never discard what the user was working on. Clearing a half-written document when saving fails turns a failure into a loss.
6. Don't signal it with colour alone. A red border is no signal at all to someone who can't distinguish that colour, so words go with it.

"There's no error state here, so failure just renders as a blank screen."

The failed case is missing from the design.

"Replace 'something went wrong' with what actually failed."

The sentence doesn't narrow the scope, so the user can't choose a next action.

"This isn't an error, it's a zero-result case — it belongs in the empty state."

Separating failure from absence of content so each gets its own screen.

After the outage, Theo split the list screen into three states: loading, zero results, and failed. What Noa put in the failed version was one sentence and one button, and the sentence carried two facts — the list couldn't be loaded, and the documents themselves were intact. Two months later the same request failed again and two messages came in, neither of them about missing documents.