Empty states, errors, and the screens teams forget

Empty state design is the work of three screens teams usually postpone: the blank, the first success, and the failure. Those three teach the product faster than the happy path, because the happy path assumes the person already understands. The blank screen is where they learn what the thing is for. The failure is where they learn what it will not do. The first success is where they learn it worked.

Ship the happy path and leave these as defaults, and people meet your product at its least considered moment. The first session is often an empty account. The first week includes at least one error. Design those moments with the same nouns, the same actions, and the same calm as the full screen.

The blank screen

An empty state is a blank collection: no leads, no positions, no files, no messages. It should answer three questions in a few lines. What will appear here later? What can I do now? What does "done" look like for the first item?

Write it as a sentence plus one action. "No leads yet. Add the first person you plan to call." The button repeats the verb: "Add a lead." A illustration of a floating folder does not answer the questions. Use an illustration only if it shows the object the product actually holds. Otherwise the sentence is enough.

Do not lecture. A paragraph about the philosophy of the product belongs on the marketing site. Inside the tool, the person is trying to start. Nielsen Norman Group notes that visitors have time to read only about a quarter of the text on a page. An empty state that begins with four sentences of welcome has already spent the reading they will do.

Show the shape of the full screen underneath, quietly, if that helps orientation: table headers with no rows, or a list outline. A completely different layout for the empty case makes the product feel like it changed products after the first save. Keep the frame. Fill the middle with the sentence and the action.

There is a second blank that is not the first run: a filter that matches nothing. Say that clearly. "No leads match 'overdue.'" Offer to clear the filter. Do not reuse the first-run copy, or you will tell an experienced person that they have no leads when they have hundreds.

A third blank is the cleared state, after someone deletes the last item. It should look like the first-run blank, with one extra clause if the delete can be undone. "No leads. The one you removed can be restored until tomorrow." If it cannot be undone, say that once, at the moment of delete, not as a permanent scold on the empty page.

The first success

The moment after the first save is where trust starts. Say what happened, in the product's words, and show the new thing in place. "Lead added. Alex Kim is ready for a call." Then stop. This is a poor moment for a tour, a second feature, or a request to invite the whole company.

If the next step is genuinely part of the same job, offer it once. "Add a call time" is fair. "Explore the dashboard" is a detour. The person should see their object in the previously empty list, selected or placed at the top, so the blank and the success connect.

Success that is only a toast in the corner will be missed. A toast can confirm. It should not be the only evidence. The record itself is the evidence. If the record is hidden on another page, send them there. A success message that refers to an object they cannot find feels like a glitch.

Write the success line when you write the button. The button says "Add a lead." The success says "Lead added." The list says "Leads." One noun, one tense shift. Teams lose this when the button is written by design and the toast is written by whoever hits the empty string in the code. Put the lines in the same place.

For a longer job, success can be partial and still honest. "Draft saved. Nothing is sent yet." That sentence prevents the person from closing the laptop believing the work went out. Partial success is a state of its own. Design it. Do not borrow the final success copy.

The failure

An error should name the thing that failed, the likely cause if you know it, and a next step that is possible. "Could not add the lead. The email is missing. Add an email, or save without one." That is a different screen from "Something went wrong."

W3C's Web Content Accessibility Guidelines treat "understandable" as one of four principles, beside perceivable, operable, and robust. Conformance is a set of testable success criteria, not a visual style. A field that only turns red fails the spirit of those criteria, because the problem is not described in text. Say the problem in words, next to the field, and move focus to that text so a keyboard user hears it.

Separate failures the person can fix from failures they cannot. Validation belongs inline, as they leave the field or as they submit. A network or server failure belongs on the action they attempted: keep their input, say you could not save, and offer to try again. Never clear the form on a failed save. The punishment for your outage should not be their retyping.

Avoid blame and avoid cheer. "Oops, our bad!" and "Invalid user input" are both noise. Use a plain sentence. If the person needs to contact someone, say who and how, and include a reference they can repeat. "Write to your admin and mention error 4021" is useful. A code alone is not.

Also design the failure that is not an error: permission. "You can see this lead. You cannot change it. Ask the owner if it needs an edit." People who meet a disabled button with no reason will conclude the product is broken. Permission is a state. Write it.

Timeouts and conflicts deserve their own lines too. "This lead was updated by someone else. Reload to see their version. Your note is still in the box below." Keeping the person's unsent words is part of the failure design. A reload that destroys the note is a second failure stacked on the first.

Put the three in the spec

When you list screens, list these beside the happy path, not in a footnote.

• Blank, first run.
• Blank, because a filter matched nothing.
• First success, with the object visible.
• Field error, in text.
• Save or network error, with the input preserved.
• Permission, with a reason.

For each line, write the sentence and the action. Read them aloud. If you hear a different noun from the one on the button, change one of them. If the action on the error is "contact support" for a problem the person could fix, change the action.

Review them on a phone. Empty states are where teams accidentally leave a desktop illustration and a button below the fold. The sentence and the button should be the first things in view. The same is true of an error summary at the top of a form: it should be reachable without hunting.

Build them in the same pass as the feature. A ticket that says "handle edge cases later" produces the browser's default alert. Later rarely comes before a customer meets it. On a Hanabi build, those states are part of the interface work, in the same components as the full page, so they inherit type, focus, and wording instead of arriving as an afterthought.

If you want help designing the path including the bad days, see Hanabi's services. The useful brief is the job, plus the blank and the failure in the founder's own words.

The blank screen is also the start of onboarding, whether you planned a tour or not. Onboarding that respects a busy person's time is the next piece: when to teach, and when the empty state already did the teaching.