Product design / Practical notes
Empty States in SaaS Dashboards Should Explain the Next Step
Before writing an empty-state message, decide what caused it and who can change the situation. That small distinction keeps a component system from saying the wrong thing.
Use two axes: cause and agency
I use two questions: why is the content absent, and can this person do anything about it? A new course lets its author create content. A person waiting for approval may need someone else to act.
Those causes deserve different words and actions, even when both layouts have space for an illustration and a button.
Create a small taxonomy
| Cause | What needs explanation | Agency |
|---|---|---|
| First use | What belongs here and how it arrives | Creator or administrator |
| Filtered result | Which conditions produced no matches | Current user |
| Incomplete setup | What prerequisite is missing | Setup owner |
| Permission | What may safely be disclosed | Access owner |
| Synchronization | Whether the result is still pending | System or integration |
| Failure | What is known and what remains intact | User, support or system |
Make classification part of the component API
A reusable component needs enough inputs to express a meaningful state: title, explanation, optional context and an appropriate action. It should not force every cause into the same primary button or celebratory visual.
Keep authorization and data fetching outside the presentational component. A UI variant can represent a permission state, but it cannot decide whether a person is entitled to see a record. That decision belongs to the product's actual access model.
Compare different causes side by side
Masteriyo’s first-content view asks the author to begin. Yarsha’s no-contact result asks the searcher to recover. Both are empty, but they belong to different points in a task.
Keep those distinctions in the component’s inputs and in the examples people use to design new screens. The piHub access-denied example later in this article is a third cause, not another name for zero results.
Keep an inventory with named owners
For each module, record the cause, role, source of truth, recovery action and open question. This exposes places where a visually shared pattern masks different business rules. It also helps the team identify which parts of the model can be reused and which need an exception.
This is a product-wide classification exercise, not the short copywriting task covered by the focused empty-state guide. A consistent taxonomy makes the component useful because the team understands what each variant means.
Keep access denial out of the no-results bucket
The piHub source gives access denial its own screen. That distinction matters: no matching products and no permission to view a page can both remove records from sight, but they need different explanations and different recovery.
The artifact supports a taxonomy discussion. It does not prove who should receive the state or that the server applies the rule correctly.
