A product spends almost none of its life looking like the design. On day one it is empty. In week two something fails. In year three a customer has three hundred records and a product name that is ninety characters long.
Designs get approved as a set of desktop screenshots showing ideal content, and then developers invent the other eighty per cent under time pressure. That is where interfaces come apart, and it is entirely avoidable.
The five states every component has
For any component that displays data, there are five states. Designing one of them is designing twenty per cent of the work.
- Empty. No data yet. This is the state every new user sees first, and it is the one most often missing from the design file.
- Loading. Data is coming. What holds the space, and does the layout move when it arrives?
- Partial. Some data, some failures. One integration is down and three fields are unavailable. Does the component say so, or silently show zeros?
- Ideal. The state in the design file.
- Overloaded. Far more data than anticipated, or far longer strings. The table with four hundred rows, the name that does not fit, the description that runs to six lines.
The empty state is the most valuable screen you will design
It is the first thing a new user sees, it is where they decide whether the product is worth learning, and it is almost always designed last, if at all.
A good empty state does three things: it explains what will be here, it says why there is nothing yet, and it gives the single action that fills it. "No shipments yet" is a fact. "Shipments appear here within an hour of being booked in the transport system – book one, or check your connection settings" is an interface.
The bad version is a grey box with a shrug icon, which tells a new user their product is broken and an existing user nothing at all.
Design with the worst realistic content
Placeholder text hides every layout problem you will actually meet. Designing with the real extremes finds them before they cost anything.
Take the longest product name in the catalogue, not a plausible one. Take the customer with the most orders. Take the German translation, which will be around thirty per cent longer than the English. Take the error message that legal insisted on and which runs to three sentences.
This is not pessimism, it is sampling. Those cases exist in the data already; the only question is whether they are found in design, where the fix is moving a box, or in production, where the fix is a support ticket.
Errors are content, not decoration
Most error states are written by whoever was implementing the validation, at the end of the sprint, and it shows.
An error message has to do three things: say what went wrong in the user's terms, say what to do about it, and appear next to the thing that caused it. "Invalid input" does none of them. "Enter an email address in the format name@company.com" does all three.
They also have to be announced, not just displayed. A message that appears visually next to a field but is never associated with it programmatically does not exist for anyone using a screen reader – and the association costs one attribute.
What this changes about handover
When the five states are designed, the handover conversation stops being a negotiation. The developer does not have to invent the empty state, guess at the truncation rule or write the error copy at 6pm. Estimates get more accurate because there are fewer unknowns hiding inside "build the table component".
It also changes what design review is for. Reviewing an ideal-content screenshot is an aesthetic exercise. Reviewing the five states is a product conversation: it surfaces questions about data availability, permissions and failure handling that would otherwise arrive halfway through development.
The cost is perhaps twenty per cent more design time on components, and it is repaid several times over during the build.