Design patterns
Empty state design: first use, no results and failed loading
Write empty states that explain why a screen is empty and offer the right next action. Includes examples for projects, filters and permissions.
An empty area can mean several things
Design an empty state by identifying why the content is absent. A new account with no projects needs a different response from a filtered list with no matches. A failed request is not an empty list, and a lack of permission is not evidence that the workspace has no data.
Start with these causes before writing the illustration brief. If the UI uses the same cheerful “Nothing here yet” message for every case, it can hide failures and send users toward actions they cannot complete.
| State | What it means | Useful response |
|---|---|---|
| First use | No projects exist yet | Explain the object and offer its first creation. |
| No matches | Filters exclude all items | Keep filters visible and offer adjustment. |
| Request failure | The result is unknown | Explain the failure and offer supported recovery. |
| No permission | This person cannot view the data | Explain access and the available next step. |
Match the action to the cause
For a first project, a short explanation and a Create project action may be enough. For a filtered list, keep the active filters visible and offer to clear or adjust them. For unavailable data, explain the failure and provide a retry when the system supports it.
A permission restriction may need a route to the administrator or an explanation of the user’s role. Do not invite a person to create a new record merely because they cannot see existing records. The message should reflect what the application knows, including uncertainty.
Show the shape of the next useful result
An empty project library can explain what a project holds without fabricating existing customer activity. If you include a sample, label it as a sample and make clear whether it is interactive. Avoid realistic counters or recent-activity items that imply real data.
Save references in Taste that demonstrate useful explanations and recovery actions. Note whether a reference is for first use, search or a failure. That label keeps an agent from applying an attractive onboarding treatment to a broken data request.
Ask for separate states in the implementation
Use this prompt for a list that already exists in your app.
Review this project list. Implement distinct states for first use with no projects, active filters with no matches, loading, request failure and insufficient permission. Use the existing API responses and do not infer one cause from another. Inspect my Taste references for concise explanations and next actions. Preserve filters on failure. Label any demonstration content as sample data. Test the transition from each state to a populated list.
Check transitions, not just screenshots
Try creating the first item, clearing a filter and retrying a failed request. The empty state should disappear when its reason no longer applies. Keep a search field usable when the results area is empty so the user can change the query.
If a status message changes without moving focus, make that update available to assistive technology. Do not announce every decorative change. The useful information is the result of the action, such as no matches or a successful retry.