An empty dashboard can mean no records, no permission, a loading delay or a failed request. Giving all four states the same “nothing here” message makes the product harder to trust and support. Design the states around what the system actually knows and what the user can do next.
The contract to define first
Model data availability and request status separately. A successful empty response can offer a first action, while denied access should explain the boundary without revealing protected details. A loading state should not flash false zero totals. Errors need a recovery action that is appropriate to the failed operation and preserves entered work where possible.
A worked scenario
A synthetic new coach has no assigned clients. That screen should differ from an established coach whose client request failed. The former needs onboarding or assignment guidance; the latter needs a retry or support path, not a suggestion to create duplicate records.
An implementation and review sequence
- Define no-data no-access loading and failure independently
- Give each state an accurate next action
- Test transitions without false zero or stale success displays
Failure cases worth testing
| Condition or input | Expected behavior |
|---|---|
| Request fails after previous data loaded | The state does not imply records were deleted |
| User lacks permission | Protected counts are not exposed |
| New account has no records | The screen offers the relevant first action |
Download the illustrative acceptance checklist (JSON)
Tradeoffs and limits
Too many distinct messages can feel inconsistent. Use a small shared state vocabulary while tailoring the primary action to the actual task.
Use the result to make a decision
The practical output is straightforward: design no-data no-permission loading and failure states separately. Keep the assumptions with the artifact so a product owner, implementer or prospective partner can review the same decision. A useful handoff states the supported scope, the evidence collected and the remaining dependency instead of treating a successful demonstration as proof of every operating condition.
Continue with related implementation detail
Related guide: Design a coach portal as an account-scoped product workspace.
Accessible charts for health dashboards
Figma prototype versus production MVP
References and current platform requirements
Figma: MCP server documentation
Figma: connecting React components
The linked references provide platform or process context. The worked scenario and acceptance matrix are original examples; adapt them to the actual product, supported environment and documented responsibilities.
Discuss the workflow
Bring a representative Figma flow and its component states to scope a design-to-code engagement.
Explore the relevant AptixLabs service
How should no-data and failed-request states differ?
An empty dashboard can mean no records, no permission, a loading delay or a failed request. Too many distinct messages can feel inconsistent.
Which failure cases should be included in the review?
Include these explicit cases: Request fails after previous data loaded: the state does not imply records were deleted; User lacks permission: protected counts are not exposed; New account has no records: the screen offers the relevant first action.