Design reviews tend to walk the happy path. The form is filled in correctly, the payment clears, the network holds, and the user gets the confirmation screen. It looks excellent, and it is roughly a third of what actually gets built.

The remaining two thirds — validation, timeouts, empty states, partial failures, permissions — are usually specified during implementation, by whoever happens to be writing that screen, under time pressure. It is not surprising that this is where products feel worst.

Errors are where trust is decided

Nobody forms a strong opinion about software that works. Opinions form when something goes wrong: whether the system explained itself, whether it protected the work in progress, and whether recovery was possible without starting again.

An interface that fails gracefully earns more goodwill than one that succeeds elegantly, because the first one was tested under conditions the user cares about.

Say what happened and what to do

"Something went wrong" is an apology, not information. A useful error names what failed, whether the user caused it, whether their data survived, and what action is available now.

This is mostly a writing problem rather than an engineering one, and it is routinely left to the person least equipped to solve it — the developer, at the end, with no copy guidance.

Empty states are a design surface

Every list is empty on the first day, and a first impression rendered as a blank rectangle wastes the moment a user is most willing to learn. The empty state is where you explain what belongs here and how to create the first one.

It is also where a great many products silently lose people who never got as far as having data.

Never lose the user's work

A form that clears itself on a validation failure is the clearest signal that nobody tried the error path. Preserve input, mark the specific fields, and keep the user where they were. This is old, well-understood ground, and it is broken constantly.

Specify them in the design, not the sprint

For each screen, list the states before building: loading, empty, partial, error, permission-denied, offline. It takes minutes and it moves those decisions to the point where someone is thinking about the user rather than about the deadline.

The happy path is table stakes. Everything memorable about an interface, good or bad, happens somewhere else.

Written by the Global IT Solutions engineering team. Have a project this touches on?

Start a conversation