How Could You Create a Dashboard No-Data Demo?
From the earlier reference collection. Read the current software blog.
Small local fixtures can exercise empty, stale, unavailable, and valid dashboard states without depending on live services.
List states before designing screens
A dashboard should communicate more than its successful-data appearance. Users also need to understand when no records exist, when displayed data are old, and when a source cannot be reached. These are different conditions. An empty result can be a valid response; an unavailable source means the system could not obtain a usable response; stale data may still be available but old.
Write down the states the application can actually determine. For example: valid observations within an agreed freshness window, an empty valid response, valid but stale observations, and a failed retrieval with or without previously saved data. Avoid inventing a precise status if the system has no timestamp or health signal to support it.
Create small local fixtures
Make each state reproducible with a tiny fixture that contains only the fields the interface needs. A valid fixture can contain two readings and their timestamps. An empty fixture can contain a valid response with no records. A stale fixture can use a fixed timestamp deliberately outside the chosen threshold. An unavailable fixture can represent a transport or parsing failure without making a real network request.
Use a fixed clock in the demo so “stale” does not unexpectedly become “current” or vice versa during a presentation. For example, set the simulated current time to 12:00 and provide an observation from the previous day. Label the demo as simulated, especially if the dashboard normally displays live public data.
Show distinct, useful messages
An empty state might say that the source responded successfully but reported no observations for the selected period. A stale state can show the last known observation time and explain that newer data were not available. An unavailable state should state that retrieval failed and, when appropriate, identify the last successful time. These messages help users decide whether to change a filter, wait, or consult another source.
Keep the underlying chart or table legible where possible. If saved data remain available during an outage, show them with a visible age indicator rather than replacing them with a blank screen. If no usable data exist, explain what is missing and offer a practical next step, such as retrying or changing the date range, only when the interface supports that action.
Use the demo as a design check
For every fixture, check the page title, status text, timestamps, units, and accessible labels. Confirm that an empty result is not rendered as an error and that an error does not look like a valid zero. Test narrow screens and keyboard access as well as the ordinary desktop view; status information should not depend on color alone.
A no-data demo is most valuable when it can be rerun by another developer without credentials or external services. Keep the fixtures close to the view logic and document how to switch among them. The result makes edge states reviewable before a real outage occurs, while preserving a clear distinction between simulated conditions and actual source health.