The five screens nobody designs · Design, Before Any Software

The happy path is one state out of six

Almost every design review looks at a screen full of plausible content. The screens that actually determine how the product feels are the other ones:

Empty. No items yet. The first thing every new user sees.
One item. Where a grid designed for twelve looks broken.
Too many. Two hundred rows, a name of sixty characters, a number with nine digits.
Loading. Between the tap and the content.
Error. The request failed.
Offline or no permission. Which is an error with a different remedy.

Each of these ships whether or not it was designed. Undesigned, they ship as a blank rectangle, a broken grid, truncated text, a spinner, and the words Something went wrong.

The empty state is a first impression

The screen a new user sees before they have done anything is, by definition, the empty state — and it is usually the last screen anybody designs, if it gets designed at all.

A useful empty state does three things: says what belongs here, says why there is nothing, and offers the action that fills it. That is a sentence and a button. The illustration is optional and frequently takes the place of the sentence, which is the wrong trade.

Distinguish between empty types, because they need different responses:

Nothing yet — invite the first action.
Nothing matching this filter — offer to clear the filter, and say what was filtered.
Nothing because something failed — that is an error, not an empty state, and saying No results when the request failed is a lie the user will act on.

Loading, and the thresholds that matter

The response-time thresholds have been stable since they were first characterised in the 1960s and repeated in usability work since:

Under about 100 milliseconds feels instantaneous. No indicator. Adding a spinner here makes the interface feel slower, because a flash of spinner reads as a stutter.
Up to about 1 second keeps the user's flow of thought unbroken. A subtle indicator at most.
Up to about 10 seconds is the limit of held attention. A clear indicator is required, and ideally something that shows progress.
Beyond 10 seconds the user will switch to something else. You need a progress bar with a real estimate, and ideally a way to leave and be notified.

The practical rule that follows: do not show a loading indicator immediately. Delay it by around 300 milliseconds, so a fast response never flashes one.

Skeletons versus spinners. A skeleton screen shows grey blocks in the shape of the content to come. The argument for it is that it communicates the layout and reduces the sense of waiting; the evidence is largely industry testing rather than strong independent research, and results are mixed. What is uncontroversial is that a skeleton must match the real layout, or the content shifts when it arrives, which is worse than a spinner was.

Error messages

An error message has three jobs and most manage none: say what happened, say why if you know, say what to do next.

Bad:  Something went wrong.
Bad:  Error 500.
Good: We could not save your changes because the connection dropped.
      Your text is still here. Try again.

The last line of that is the part that matters most and is omitted most often. A user who does not know whether their work survived will assume it did not.

Never blame the user, never show a stack trace to somebody who cannot act on it, and never use red alone — the colour rule from the previous block applies here as much as anywhere.

Design with hostile content

The third state on the list deserves a specific habit. Design with the longest realistic values, not the convenient ones:

A name that is sixty characters, or two characters.
A price of 1,20,00,000 rather than 99.
A title that wraps to four lines.
A translated string. German runs roughly 30% longer than English on average; Tamil and Hindi strings are frequently longer too, and a button sized to fit Save in English will not fit its translation.

Using John Smith and Item name in a mockup is not neutral; it is a decision to test the easiest case only. Substituting the longest plausible values takes two minutes and finds most truncation bugs before they exist.

The checklist

Before any screen is considered finished, produce it in all six states. It takes far less time than it sounds — most are a variation on the same layout — and it converts a class of bug that normally surfaces in production into an hour of design work.