An empty screen does not always mean “nothing here yet.” It can mean the user has not created anything, a search returned no matches, filters exclude every result, content is still syncing, permissions hide the data, or an upstream request failed. Reusing one friendly illustration and “Get started” button across those states creates misleading copy and broken actions.
An empty-state audit starts by identifying why the interface is empty. Only then can the team write the right explanation and next step.
Build an empty-state inventory by cause
Search the Figma file for screens, components, and variants containing terms such as “no results,” “nothing here,” “empty,” “create your first,” and “try again.” Also inspect list, table, dashboard, search, inbox, and library components even when they currently contain sample data.
For each state, record:
- product area and screen;
- triggering condition;
- audience and permission level;
- whether the condition is expected or exceptional;
- what the user was trying to do;
- actions the product can genuinely offer;
- current heading, body, CTA, and help link;
- implementation or analytics identifier, if one exists.
Group the inventory by cause rather than visual similarity. Two states may use the same illustration but need completely different language.
Distinguish the six common empty states
First-use state
The user has no content because they have not created or imported it. Explain the object in plain language and offer the smallest meaningful first action. “Create project” is appropriate only if the person has permission to create one.
Cleared or completed state
The user deliberately processed everything, such as reaching inbox zero. Confirm success rather than suggesting setup. A calm “You’re all caught up” can be enough; do not add a CTA simply to fill space.
No search results
Repeat or summarize the query, suggest how to broaden it, and preserve the input so the user can edit it. Do not claim that the underlying content does not exist. The dedicated search and filter copy audit helps when queries, result counts, and filter combinations need a deeper review.
Filtered state
Show which filters caused the empty result and provide a clear way to remove or change them. “No data” is especially misleading here because the system may contain plenty of data outside the current view.
Restricted state
If content exists but the viewer lacks access, explain the boundary without revealing confidential names or counts. Offer “Request access” only if a real request path exists and the recipient is known. Otherwise direct the user to an appropriate administrator or policy.
Failure or unavailable state
A failed request is not an empty collection. State that the content could not be loaded, preserve the user’s work, and provide a retry or support route that can work. Avoid blaming the user’s connection unless the product has evidence.
Write from what the user knows
Good empty-state copy answers three questions in order:
- What is happening?
- Why, if the product can know and safely explain it?
- What can I do next?
Do not expose internal object names or error codes as the main message. “No entities found for tenant” may be technically precise but useless to the reader. Conversely, avoid vague personality that hides the problem: “It’s quiet in here!” does not explain whether the user needs to create, search, wait, or ask for access.
Match the CTA to the actual action. Use “Clear filters” rather than “Try again” when filters are the cause. Use “Create report” rather than “Get started” when the user already understands the product. If there is no useful next action, omit the button.
Audit permissions and role variants
Review every state as an owner, editor, contributor, and viewer where those roles exist. A viewer should not see a primary “Create” button that leads to a permission error. An administrator may need a setup action while a member needs an explanation that setup is pending.
Account for shared and personal scopes. “You haven’t created any dashboards” differs from “This workspace has no dashboards.” The subject matters because it tells the user whether someone else’s action could change the state.
Use realistic fixture names and content during review, but keep personal or customer data out of the design file. Test singular and plural forms, long translated strings, and states where only one secondary action is available.
Use CopyDoc to review strings as a system
CopyDoc helps teams export, review, and synchronize text content in Figma rather than checking each screen manually. Give each empty-state string a stable key that includes its surface and condition, such as:
reports.empty.first_use.heading
reports.empty.filtered.body
reports.empty.load_failure.action
Do not use one generic empty.title key across unrelated causes. Stable, specific keys make review comments and implementation reconciliation easier.
Export the relevant strings to the team’s approved review format, add columns for state, role, source screen, owner, status, and implementation key, then bring approved changes back into the Figma designs. The broader copy approval workflow is useful when legal, support, localization, and product owners all need to sign off.
Verify copy in the rendered product
Figma review proves that the intended copy fits the intended design. It does not prove that the application selects the right state. Create deterministic test fixtures for first use, cleared content, zero search results, active filters, restricted access, loading failure, and offline behavior.
For each fixture, check:
- the correct heading and body appear;
- the action is available to that role;
- the action leads to the promised destination;
- filters or queries remain visible when relevant;
- assistive technology announces the state change;
- the message does not flash briefly during normal loading;
- localized text fits without hiding the action.
Finally, compare implementation keys with the approved inventory. Any unmatched state is either missing from the audit or implemented under an ambiguous condition.
The best empty-state copy is not the cleverest line in the interface. It is the message that accurately names the current condition and gives this user the next action they can actually take.
Read as Markdown Related resource index Site index for AI agents