In this guide 6 sections
Happy paths are not enough. Design an empty state for first use, a loading state for slow networks, an error state for failed saves, a denied state for missing permission and a no-results state. Each message must tell the clerk what happened, whether the work is safe and which button to press next without phoning anyone.
Why these screens get skipped
Designers draw tidy sample data. Developers build it, test it with their own records and ship it on a Friday, and nobody ever draws the version where the table has zero rows.
Real users meet the unhappy screens constantly. A new branch opens with no customers, a warehouse tablet loses signal between aisles, and a save fails because a colleague edited the same invoice first.
A blank panel looks broken. A spinner that never ends does worse, because the clerk either phones support or enters the order twice and leaves accounts to untangle the duplicate invoice at month-end.
The five states every screen needs
Check each screen against five cases. The cases are first use, loading, error when a save or fetch fails, denied when the role lacks permission, and no results when a search finds nothing.
Draw all five in the prototype. Budget an hour per screen, because a developer who sees them in the design file builds them on the first pass instead of patching them after launch.
Add a sixth for partial success. Bulk imports of price lists hit it, with 40 rows imported and 3 rejected, so the clerk needs a downloadable list of rejected rows with reasons.
- Empty: first use, nothing created yet
- Loading: records on the way, slow connection
- Error: save failed, server unreachable, session expired
- Denied: the role cannot open or edit this
- No results: the search or filter matched nothing
Empty states that start the work
An empty list can teach. Skip the grey “No data” and say what belongs there, for example “Create your first purchase order from an approved requisition” with the button placed right beside the words.
Never-used and filtered-to-nothing are different cases. The first needs a starting action such as a Create button, while the second needs a Clear filters link that restores the full list in one click. Never mix them up.
Offer a sample row. Link an import template when staff usually begin by uploading a spreadsheet, so the first minute goes on real work and not on guessing column names.
Loading and error messages a clerk can act on
Skeleton rows beat a bare spinner. Anything slower than a few seconds deserves a line saying what is happening, such as “Fetching the March stock ledger,” because silence feels like a freeze.
A good error names the problem in plain words, says whether the work is saved and gives one next step, all in two short lines. Something like “Could not save, your entries are still on screen, check the connection and press Retry” works because the clerk knows nothing was lost and what to do. A bare “Error 500” helps nobody.
Never wipe typed data after a failure. Keep the form filled, mark the offending field and place the message beside it, not in a pop-up that vanishes before the clerk finishes reading.
- Say what happened in plain words
- Say whether the work was saved
- Give one clear next action
- Keep a support reference for the help desk
Denied, offline and no-result screens
A permission wall names the role needed and who can grant it, as in “Only Accounts can approve vendor bills, ask your finance lead,” not a blank page.
Settle offline behaviour on paper. Decide what can be viewed and what can be queued, because a small “3 waiting to send” badge tells the clerk a delivery note is safe.
A failed search should suggest a fix, such as checking the spelling, widening the date range or searching by invoice number when the customer name returns nothing. Pick your busiest screen and list how each of the five states looks there today, then mark each gap with the person who will draw the missing state.
Screen states checklist
Print this on one sheet. Screens run down the left, while five columns named empty, loading, error, denied and no results run across, each cell holding the message text and a done tick. A footer notes offline behaviour for field devices, and a second block sets the wording style, covering tone, message length and the verbs on buttons.
Open a blank worksheet to printQuestions owners ask
What is an empty state in software design?
It is the screen a user sees when a list, table or dashboard holds no data yet, such as a new branch with no customers. A good one explains what belongs there and puts the Create button right beside that text, so nobody hunts through a menu.
Should every error show a technical code?
No. Show plain wording to the user and keep a short reference code for the help desk, so support can find the exact log entry in seconds. Nobody reads a stack trace aloud.
How do we test these states?
Use a test account with no records, throttle the network in the browser and force a failed save, so each state appears on demand. Then ask a daily user to attempt one real task in each case and write down the exact point where they stall or hesitate for a few seconds.
Do small internal tools need all this?
Yes, in a lighter form. Internal tools meet slow connections and permission limits too, and staff cannot switch to a competitor when a screen confuses them, so they ring the help desk instead. A few clear messages cut those calls.