Blank space is not an explanation.
You open a page.
Nothing is there.
What does nothing mean?
No records have ever been created?
Your search found nothing?
Your filters removed every match?
You do not have permission?
The data source is offline?
You completed every outstanding task?
Nothing needs your attention?
The visual result is similar.
empty screen
The underlying realities are completely different.
This is why empty-state English matters.
An empty state is the sentence that tells absence what kind of absence it is.
Without that sentence, the reader has to diagnose the system from silence.
Quick Read
One-sentence answer: an empty state works when English accurately identifies why expected content is absent, distinguishes normal emptiness from filtering or failure, and gives the reader the most useful next step—or confidently says that no action is needed.
A strong empty state usually answers some combination of:
- what is absent? records, messages, results, alerts, files, tasks;
- why? first use, deletion, search mismatch, filters, permissions, configuration, system failure, successful completion;
- is this expected? normal state or problem state;
- what next? add data, change the query, remove filters, request access, retry, configure, or do nothing;
- what should not be inferred? for example, “no visible data” does not necessarily mean “no data exists.”
IBM Carbon’s empty-state guidance, updated in August 2026, treats empty states as distinct situations rather than one generic blank-screen pattern. It separates no-data states, user-action states such as no search results or successful completion, and error-management states such as permission problems, system issues and configuration requirements. Carbon’s guidance emphasises plain language, contextual explanation and a useful next step where one exists.
DWP’s current filter guidance adds an important special case: zero filtered results should show the active filters and give the user a route to loosen or clear them.
The central principle is:
Absence needs provenance.
No Data Yet Is Not an Error
A new account opens a dashboard.
There are no projects.
No charts.
No activity history.
The system is working perfectly.
The user simply has not created anything yet.
Weak:
No data.
Better:
No projects yet.
Create your first project to see progress and activity here.
Carbon describes this as a no-data empty state, common during first use or when content has been removed.
The English should orient rather than alarm.
Nothing has failed.
The page is waiting for its first object.
No Search Results Is a Different State
The collection contains thousands of records.
You search:
quantum grammar penguins
No result matches.
The database is not empty.
The query-result intersection is empty.
Carbon treats no search results as a user-action empty state and recommends explaining why the reader sees the message and suggesting useful adjustments when appropriate.
Weak:
Nothing found.
Better:
No results for “quantum grammar penguins.”
Try fewer words, check the spelling or search with a broader term.
The search phrase remains visible.
The reason for emptiness remains interpretable.
The user receives a recovery route.
Zero Filtered Results Is Not the Same as No Search Results
Suppose the search produced 237 records.
Then you apply:
- Status: Active
- Date: Last month
- Region: North
- Level: Advanced
Zero remain.
The correct explanation is not:
No data exists.
It is:
No records match your current filters.
DWP’s filter guidance treats this as one of the main states to design. It recommends keeping applied criteria visible and offering a way to remove or clear them.
A useful empty state might say:
No records found.
Applied filters: Status: Active; Date: Last month; Region: North; Level: Advanced.
Remove a filter or clear all filters to widen the results.
The emptiness becomes diagnostically useful.
The user knows which constraints produced it.
No Permission Is Not No Data
A dashboard is empty.
The data exists.
You are not authorised to see it.
If the interface says:
No records.
it communicates the wrong world state.
Carbon identifies permissions issues as an error-management empty state and recommends telling users that they do not have permission and explaining how access can be requested where appropriate.
Better:
You do not have access to these records.
Ask your administrator for the Reporting Viewer role.
The distinction protects both accuracy and trust.
not visible to you ≠ nonexistent
That principle is important far beyond software.
Absence from one observer’s field is not proof of absence from reality.
A System Failure Can Look Exactly Like an Empty Dataset
A reporting service cannot reach its database.
The table displays no rows.
If the interface renders an ordinary empty state:
No reports yet.
the user may conclude that the records were deleted.
Carbon treats system issues as another error-management state and recommends explaining that a related system is preventing the data from being supplied and giving a route to understand or recover where possible.
Better:
Reports are temporarily unavailable.
We could not load data from the reporting service. Try again, or view the activity log for system status.
This is why an empty state is not simply typography placed into blank space.
It is diagnosis language.
Configuration Required Is Another Kind of Absence
A chart is empty because no data source has been connected.
The user may have permission.
The source system may be healthy.
The feature simply has not been configured.
Weak:
No data.
Better:
Connect a data source to create this dashboard.
Start by choosing a source.
Carbon explicitly includes configuration-required empty states and recommends explaining the first corrective step.
The important thing is that the English identifies the missing precondition.
The space is empty because the pipeline has not been connected yet.
Successful Completion Can Produce an Empty State
You begin with five tasks.
You complete all five.
The task list becomes empty.
This emptiness is good news.
Weak:
No tasks.
Better:
You’re all caught up.
No tasks need your attention.
Carbon recognises user-action empty states that confirm successful completion.
But this is also where tone needs restraint.
A hospital alert dashboard with no alerts probably should not say:
Woohoo! Nothing happening!
Context matters.
The system can communicate normalcy without turning every absence into celebration.
Sometimes Nothing Requires No Next Action
An alert system shows:
No active alerts.
What should the user do?
Nothing.
That is a valid answer.
Carbon notes that not every empty state needs supplementary text or a call to action. If alerts are correctly configured and none have triggered, there may be no useful next step.
This is an important restraint principle.
Do not invent a task merely because the design template has room for a button.
Sometimes the clearest empty state is simply:
No active alerts.
Nothing else is needed.
The Empty State Is Not the Error Message
Error message:
Upload failed. The file is larger than 20 MB.
It explains a failed operation.
Empty state:
No uploaded files yet.
It explains the absence of content in a region.
The two can overlap.
If a system failure prevents data from loading, the empty state may contain error-recovery language.
But their core jobs differ:
error message = what failed in an operation
empty state = why this content region currently contains nothing
Keeping the concepts separate improves diagnosis.
The Empty State Should Occupy the Empty Place
Carbon recommends placing the empty-state message in the context of the missing data.
If a table is empty, explain the absence where rows would normally appear.
If a dashboard tile is empty, explain it inside the tile.
If a side panel has no items, explain it in that side panel.
This follows a proximity principle:
Put the explanation where the expectation was violated.
A global banner saying:
No data
may leave the reader unsure which of six panels it refers to.
Local absence deserves local explanation.
The Headline Should Name the State, Not Advertise the Product
A new user sees an empty dashboard.
Weak:
Unlock the power of productivity!
The space is empty, but the headline does not explain why.
Better:
No projects yet
Then:
Create a project to track tasks, files and progress here.
The headline is diagnostic first.
Persuasion can come later.
Empty-state English works best when it helps the user understand the current system state before asking them to do something.
One Primary Action Is Often Enough
Carbon advises against turning an empty state into a menu of unrelated possibilities. Where corrective actions exist, it recommends a clear hierarchy and often one primary next step.
Weak:
No projects yet.
Create project | Import project | Watch tutorial | Read docs | Invite team | Change settings | Browse templates
The empty state has become a dashboard.
Better:
No projects yet.
Create your first project to start tracking work.Create project
A secondary documentation link may be useful, but the main route should remain clear.
Absence already creates uncertainty.
The recovery surface should not add unnecessary choice overload.
Do Not Joke About Serious Absence
Empty states are famous for cheerful illustrations and witty copy.
Sometimes that is harmless.
Sometimes it is grotesque.
A photo library with no favourites can say something playful.
A medical dashboard unable to load patient records should not.
Carbon explicitly advises respectful, direct language in error-management empty states and warns against jokes or flippant language when the situation may be serious.
Tone should be proportional to consequence.
Blank space does not automatically create permission for whimsy.
The user may be staring at missing work, missing records or missing access.
Respect the stakes.
Empty States Can Teach the Future Shape of the Page
A good first-use empty state can explain what will eventually appear here.
Your saved searches will appear here.
Save a search to return to the same query and filters later.
The page is empty now.
The English gives the reader a model of its future populated state.
Carbon describes this as one of the strengths of empty states: they can communicate what users would see if data were available and how to add or create it.
This is future-model language:
current absence → explanation → imagined populated state → first action
The user learns the feature before the feature has anything to display.
Starter Content Can Be Better Than Emptiness
Sometimes the best empty state is not empty.
A design tool can open with an example project.
A writing app can provide a sample document.
A classroom platform can show one demonstration lesson.
Carbon discusses starter content and onboarding as alternatives or supplements for richer first-use situations.
Why?
Because sometimes seeing the populated object teaches better than reading about what a populated object would look like.
This is especially useful for complex primary features.
The design question becomes:
Should we explain the future state—or let the user experience a safe example of it?
An Empty State Can Reveal Data Architecture
Suppose a dashboard says:
No attendance data for this class.
That tells us the system expects attendance records to be related to classes.
Another says:
No marks have been imported for Term 3.
Now the absence is scoped by term.
Empty-state wording therefore exposes the system’s object relationships:
class → attendance records
term → assessment marks
account → projects
Good empty states identify the missing object at the right level.
“Nothing here” hides the architecture.
“No attendance records for this class” exposes it.
Absence Can Be Epistemically Dangerous
Humans are tempted to infer:
I cannot see it, therefore it does not exist.
Empty states can either reinforce or correct that error.
“No records” may imply nonexistence.
“You do not have permission to view these records” correctly locates the absence in observer access.
“Records are temporarily unavailable” locates the absence in system delivery.
“No records match the current filters” locates the absence in the criteria.
“No records have been created yet” locates the absence in world state.
These are different causal models.
Good empty-state English tells the reader which model is justified.
Primary School: Ask Why the Box Is Empty
Give children four empty boxes.
Label the scenarios:
- No books have been borrowed yet.
- Your search found no books called “Moon Dragon.”
- You cannot view the teacher’s private notes.
- The library computer cannot load the catalogue.
Ask students to write one empty-state sentence for each.
The visible emptiness is the same.
The explanations must differ.
This is causal reasoning through English.
Lower Secondary: Diagnose Before Writing
Give students a blank results panel.
Before they write any message, ask them to identify the cause:
- first use;
- query mismatch;
- filter mismatch;
- permission issue;
- system outage;
- completed task list.
Only after cause is known should they write the copy.
This teaches a fundamental rule:
Do not write the message until you know the state.
Good language begins with correct diagnosis.
Upper Secondary: Audit the Inference Boundary
Older students can analyse real empty states.
- What does the message claim is absent?
- Does it explain why?
- Could the same visual emptiness have another cause?
- Does “no results” mean no data, no match or no permission?
- Is the next action relevant to the cause?
- Does the tone respect the consequence?
- Does the state create a dead end?
- What belief would the user form if the explanatory sentence were removed?
The empty state becomes a powerful lesson in absence, evidence and observer limits.
Ten Failure Modes of Empty-State English
- Generic emptiness. “Nothing here” does not identify what is absent.
- Cause collapse. First use, filtering, permissions and system failure are treated as one state.
- Existence error. “No data” is shown when data exists but is inaccessible.
- Query blindness. No-results copy hides the search term that produced the empty set.
- Filter blindness. Zero results appear without showing active criteria.
- Dead-end recovery. A problem is explained but no useful corrective action is offered when one exists.
- Invented action. The interface adds unnecessary calls to action when no next step is needed.
- Tone mismatch. Serious missing data is met with jokes or celebration.
- Context displacement. The explanation appears far from the empty region it describes.
- Marketing substitution. Promotional copy occupies the space that should first explain the current system state.
How to Write a Better Empty State
Start with diagnosis.
Why is the region empty?
First use?
No matching query?
No matching filters?
No permission?
System unavailable?
Configuration missing?
Work completed?
Then name the missing object.
Explain the cause in plain language when the cause matters.
Give one clear primary next step when a next step exists.
Keep the message inside the empty region.
Match tone to stakes.
Do not imply data does not exist when the actual problem is access or delivery.
Then perform the inference test:
After reading this message, what will the user believe about why the content is absent—and is that belief actually justified?
If the answer matches the system state, the empty-state English is doing its job.
The Deeper Idea: Nothing Is Not One Thing
This is the profound lesson of the empty state.
Humans often treat absence as simple.
It is not.
No observation.
No object.
No permission.
No matching condition.
No current alert.
No successful connection.
No remaining work.
These absences are not interchangeable.
A mature information system does not leave the receiver to guess which void they are looking at.
visible emptiness → diagnosed cause → truthful explanation → appropriate next state
That is more than interface writing.
It is epistemic discipline.
English gives absence a cause, a boundary and, when possible, a route forward.
Reader Checklist
- What exactly is absent?
- Why is it absent?
- Is the emptiness normal, user-caused or system-caused?
- Does no visible data actually mean no data exists?
- Are search terms or active filters still visible?
- Does the message identify permission or configuration issues accurately?
- Is there a useful next action?
- If no action is needed, is the interface comfortable saying so?
- Does the tone match the consequence?
- What belief about the world will the reader form from this empty space?
Related eduKateSG Reading
- How English Works | The Filter
- How English Works | The Error Message
- How English Works | The Notification
- How English Works | The Search Query
- How English Works | The Form
Research and Further Reading
Final idea: an empty state is good when a blank space stops being a mystery and becomes an accurate account of what is missing, why it is missing and whether anything should happen next.