Dashboards get a bad reputation in IoT, and mostly unfairly. The problem is rarely the dashboard itself — it is that building one is treated as the finish line, and that the dashboard is designed as though more information is always better.
A well-designed operational dashboard is genuinely valuable. A badly designed one gets opened twice and then never again, taking the credibility of the whole programme with it.
This guide is about designing the dashboard properly: what belongs on it, what belongs in automation instead, and the design decisions that determine whether anybody still uses it after a month.
Why Most IoT Dashboards Stop Being Used
A dashboard is used when it answers a question somebody already had. It is abandoned when it presents information somebody must find a use for.
Designing Around Decisions, Not Data
Start from the questions, written down
Interview the actual users and list the questions they ask during a shift. “Which machines need attention today?” “Did last night run normally?” “Is this site worse than the others?” Each question becomes a view; anything not answering a listed question does not belong.
Lead with status, not with charts
The top of the screen should answer “is anything wrong?” in one glance — a short list of assets needing attention, ordered by urgency. Charts are for investigating after the answer is yes, not for discovering it.
Show normal alongside current
A reading is meaningless without a reference. Display the expected range, the asset’s own recent baseline, or how peers are performing, so interpretation does not depend on the viewer’s memory.
Make data age and gaps explicit
Timestamp every value, grey out stale ones, and draw gaps as gaps. Never interpolate across an outage — a system that looks healthiest when it is least reliable is worse than no system.
Put the next action on the screen
If an asset needs attention, the dashboard should offer the thing the user would do next: raise a work order, acknowledge, view the procedure. Requiring the user to leave and re-enter the information elsewhere is where most workflows break.
Design for the device it is used on
Operations staff are frequently on a phone in a plant, not at a desk. A dense multi-panel layout that requires a large screen will not be consulted where decisions are actually made.
What Should Not Be on a Dashboard At All
Some things look like dashboard content and are better handled another way.
| If the information is… | It belongs in… |
|---|---|
| Urgent and requires immediate response | An alert with escalation, not a screen someone must be watching |
| A repeated judgement with a clear rule | Automation, with the dashboard showing what was done |
| Reviewed weekly or monthly | A scheduled report, not a live view |
| Needed by another system | An API or integration, not a human copying numbers |
| Interesting but never acted on | Nowhere — remove it |
The second row is the one that matters most as systems grow. Any judgement a person makes the same way every time is a candidate for automation, and moving it off the dashboard is how a system scales beyond the attention available — the distinction explored in autonomous systems versus dashboards.
Keeping a Dashboard Useful Over Time
Frequently Asked Questions
Conclusion
Dashboards do not make a system intelligent, but a good one makes a system usable — and most IoT dashboards are built from the data available rather than the decisions required.
Design from the questions people actually ask, lead with status, always show what normal looks like, be honest about data age, and put the next action within reach. Then keep moving repeated judgements into automation, so the dashboard shrinks as the system matures instead of growing until nobody opens it.