A useful SaaS empty state explains what belongs on the screen and gives the user one clear next step. First check why the screen is empty. A new account, a search with no matches, and a failed request need different messages and actions.
Treat the empty state as part of the first task. Its job is to help someone create a real result they can come back to.
Name the state before writing the message
Imagine a small app for collecting customer interview notes. A blank list might mean the account has no interviews yet. It might also mean a filter hides every saved note, or that the app could not load the list.
Carbon's empty-state guidance separates first-use, user-action, and error situations. Use that distinction in your rendering logic before polishing the copy.
Keep the loading state separate too. Showing “No interviews yet” while a request is still running tells the user something you have not established.
Give the first screen one useful action
For a new account, try a heading such as “Your interview notes will appear here.” Add a sentence explaining the result: “Create an interview to keep its notes and follow-up questions together.”
The primary action could be “Create an interview.” That label tells the user what will happen. “Get started” leaves more guessing to do.
Do not put five setup tasks into this one panel. If creating an interview needs a project first, make the next action create the project and explain that dependency. The right button is the first step a new user can actually complete.
Make each recovery action fit the problem
When a filter returns no matches, preserve the user's search and offer a way to clear the filter. Sending them to the create form would answer the wrong question.
When loading fails, say that the notes could not be loaded. Offer a retry if retrying is supported. Keep any data the user already entered while they recover.
For a permission problem, explain who can grant access if your product has that information. Do not show a create button that the current role cannot use.
A short set of named states can make these choices easy to review:
- Loading: wait for the current request.
- Load failed: retry the same request.
- No saved interviews: create the first interview.
- No matching interviews: adjust the current filter.
- Access unavailable: use the supported access process.
These are example product states. Adapt them to your app's real behavior instead of adding branches that cannot occur.
Continue the task after the click
Test the whole path with a new account. Click the action, complete the smallest valid form, save, and return to the list. Check that the new item appears and can be opened.
Then cancel halfway through. The app should return to a state that still makes sense. Try a failed save as well; a friendly first screen cannot compensate for losing the user's first set of notes.
Use a sample item only when it teaches something that the empty screen cannot. Label it as sample content, and make the difference from saved customer work clear.
Review the screen without its illustration
Temporarily ignore the artwork and read only the heading, explanation, and action. You should still understand what is missing and what to do next.
Check the screen with keyboard navigation, long button labels, a narrow window, and the roles your product supports. Record whether the user completed the first task, rather than only whether they clicked the button.
The useful test is simple: can a new user turn this empty space into one saved result, and find that result again?
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)