A dashboard screenshot usually shows the happiest moment: enough data, a wide viewport and no failed requests. Building the UltraFit360 frontends taught me to treat that picture as one state rather than the product. The coach-portal audit later made the gaps explicit: empty data and failed loading could look alike, mobile navigation did not expose the full workspace, and some interactive controls needed better keyboard behaviour. This article is about the review process that follows the first polished design. The figures use actual website components with fictional records, not real clients or a claim that every protected route has passed live testing.
Empty is a successful answer
“No templates yet” can mean the request succeeded and the account has no templates. That is a valid state with a useful next action. “Could not load templates” means the application cannot establish the current result. Showing the same blank panel for both hides information the user needs.
I would write the state model before choosing the illustration. Loading, first-use empty, filtered-empty, failed initial load and failed refresh are different conditions. Their calls to action differ too: create something, reset a filter, retry or continue using the previous result. The words should describe what the application actually knows.
Scroll the table horizontally to see all columns.
| State | What the UI knows | Useful next action |
|---|---|---|
| First-use empty | Load succeeded, no records | Create first record |
| Filtered empty | No match in current filter | Reset filter |
| Initial failure | Current data unknown | Retry |
| Refresh failure | Previous result exists | Keep context and retry |
Preserve useful context during a failed refresh
A previously loaded roster may remain useful when a background refresh fails. Replacing it with an empty screen makes a temporary network problem look like lost data. Keeping it without any indication can also mislead the user into treating it as newly verified.
The interface should preserve context while communicating the refresh state appropriately. A retry action and a clear message can be more useful than a dramatic error page. Decide whether stale data is safe for the current task; viewing a roster is different from committing a sensitive edit based on an outdated record.
Render the state the interface actually knows
These compact wireframe specifications describe evidence and actions, rather than pretending to be product screenshots.
View-state contract
- Loading first result
Show progress without asserting that records are absent.
- Successful empty result
Explain first use or a restrictive filter; offer create or reset.
- Initial load failed
The data is unknown. Offer retry rather than an empty-state claim.
- Refresh failed; old result exists
Keep safe context, label it as stale and offer retry.
Do not make a network error look like deleted data. Whether stale records remain safe depends on the action.
The first viewport should support the main job
A dashboard can spend its entire first screen on a greeting, decorative charts and summary counters. The person may actually need to review an overdue check-in or follow up with a client. The later portal direction puts current work closer to the top instead of making every metric equally prominent.
This is an information-hierarchy decision, not a claim that decoration is always wrong. Motion and visual character can help orientation. They become a problem when the user must search past them to find the next action. I want the first screen to answer “what needs my attention?” before asking the reader to admire the component system.
A dialog includes its focus journey
A modal needs a label, a meaningful reading order, contained focus where appropriate and a predictable return point when it closes. Giving a div a dialog role does not implement the full interaction. The portal audit’s move toward established primitives is a useful example of using existing tools rather than rebuilding every behaviour.
Test opening with a keyboard, moving through controls, closing with the expected key and returning to the trigger. Also inspect the theme of portaled content. A dialog can inherit different tokens from the page beneath it. Accessibility and theme integration meet at exactly the places a static screenshot tends to hide.
Charts need an alternative way to read the data
A sparkline can show direction at a glance, but it should not be the only way to understand a meaningful value. Provide a clear summary and, where useful, a table or disclosure with the underlying numbers. Decorative graphics can remain hidden from assistive technology when the information is supplied elsewhere.
Do not invent a trend merely because a metric card looks unfinished without one. The source components themselves distinguish available history from absent history. A flat or missing data series is not a design defect to repair with fictional growth. The same honesty should carry through screenshots and editorial examples.
Long content is a design input
A short name and three rows will not expose the same layout problems as a long label and a large roster. The audit used synthetic preview cases with different roster sizes. That is a useful way to inspect density and overflow without bringing customer data into a public article.
The test should check the actual document width, not merely whether a screenshot looks cropped neatly. Tables may need their own scroll region. Filters need clear labels and keyboard behaviour. A component that fits at one width can still create a page-level horizontal scroll at an intermediate viewport, so review representative sizes rather than only the endpoints.
Automated checks establish a bounded result
The portal implementation record reports automated accessibility and browser checks. It also explicitly leaves authenticated deep flows, real hardware, screen-reader work and moderated usability open. I want to preserve those limits rather than turn a clean axe run into a blanket conformance claim.
Automation is most useful when it catches a repeatable regression and makes the next review cheaper. Human testing answers other questions: is the next action understandable, does the language fit the task, can a real coach find the relevant client? Both forms of evidence matter, and neither should impersonate the other.
Questions worth asking
Should I design every state in Figma? You need enough explicit state decisions to prevent accidental behaviour. Some can be documented through a component gallery or a small interaction specification rather than a separate full-page frame.
Is an empty-state illustration necessary? Only if it helps. A clear explanation and useful action can be sufficient. Decorative friendliness should not hide a request failure.
When is the dashboard finished? When its important tasks remain understandable across the states and input methods the product supports. The ideal screenshot is a starting point for that review, not the final acceptance criterion.
Sources
Technical references checked .
