The craft

The empty state is the product

A demo is a performance of the happy path — the account already full, the data already flowing, every field populated with something tidy. It is honest about what the product can do and quietly silent about most of the moments a real user will actually live in.

The states a demo skips

The person running a demo has rehearsed the route and cleared the obstacles. The person meeting the product for real has not. They arrive at an empty screen on day one, a spinner while something loads, and red text when something fails — and they meet all three before they ever reach the polished dashboard the demo was built around.

It is in exactly those states, the ones no screenshot flatters, that a user decides whether to trust the thing at all. A product is not the sum of its best-case screens. It is what it does in the ordinary, awkward, first-run moments — and those are the moments most teams leave for last, or leave undone.

The empty state teaches

An empty state is the first thing a new user sees, which makes it the single most important screen in the product and the one most often left as a shrug — a blank table, a grey "No data yet." That blankness squanders the one moment the user is most willing to be taught. A good empty state does the opposite: it says what will live here, why the first item is worth adding, and exactly how to add it, so emptiness becomes an invitation instead of a dead end.

Designing it well also forces a useful question early — what is the very first thing a person does here? Answer that in the empty state and you have designed the onboarding almost by accident. Skip it and you have shipped a front door that opens onto a blank wall and a faint sense that you arrived too early.

Loading and error decide trust

Loading and error states are where trust is won or lost, because they are where the software stops feeling like magic and admits it is a machine talking to other machines. A considered loading state shows shape — a skeleton of what is coming — so the wait reads as progress rather than a hang. A considered error state says what went wrong in plain language, says what the user can do next, and never blames them for it.

We treat these as the product, not the trimmings — which is why Koryvant renders every screen in every state, empty, loading and error, in both themes, before a line of production code is written. A prototype that only shows the happy path is a demo of a demo. If you want the unglamorous states designed as carefully as the pretty one on software built for you, that is part of custom web application development.

Questions

People also ask

    Why do empty, loading, and error states matter so much?

    Because a real user meets them before ever reaching the polished screens a demo shows. The first-run empty state, the wait, and the failure are where a person decides whether the product is trustworthy — so they deserve as much design attention as the happy path.

    What makes a good empty state?

    It teaches rather than apologises: it says what will live on the screen, why the first item is worth adding, and exactly how to add it. Done well, the empty state doubles as onboarding, because it forces the question of what a user should do first.