Fazley RabbiA useful IoT dashboard answers one question within a few seconds: is everything all right, and if not, what needs attention now? It shows the current status of each machine, room or pond in plain names, puts problems at the top, makes silent or failing devices obvious, and gives a short trend for context. Everything else, such as decorative gauges, every raw reading and numbers nobody acts on, belongs in a report or nowhere at all.
What a dashboard is for, and what it is not
A dashboard is for looking. Alerts are for when nobody is looking. No one watches a screen at three in the morning, so a dashboard should never be the only way you learn that a freezer has failed. Good systems pair the two: alerts that reach the right person, and a dashboard that helps that person understand what happened and what to do next.
A dashboard is also not a trophy. It is tempting to fill a large screen with moving charts because it looks impressive in the office. If a number on the screen never changes anyone's decision, it is decoration.
Five things a useful dashboard shows
- Status at a glance. One tile or row per unit, with a clear colour for normal, needs watching, and problem. Use names people already say, like "Pharmacy fridge 2" or "Pond 3", not "Node_07".
- Problems first. Out-of-range items should rise to the top, so a manager with twenty units does not scroll to find the one that matters.
- Device health. Show when each device last reported, and its battery and signal where relevant. A sensor that has gone silent can look perfectly normal if the screen just keeps showing its last value.
- Short trends with limits drawn. A line for the last day or week, with the allowed range shaded, shows whether something is drifting slowly or jumped suddenly. That difference often points to the cause.
- An alert log. What triggered, when, who acknowledged it and what they did. This turns alarms into a record you can learn from.
For a full example, see how this works in temperature alerts for cold rooms and pharmacy fridges.
What to leave out
- Speedometer-style gauges. They take a lot of space to show one number. A plain value with a coloured background does the same job.
- Every raw reading. Keep the history in the database and show a summary on the screen.
- False precision. Showing more decimal places than the sensor can measure makes readings look more exact than they are.
- Numbers with no owner. If nobody is responsible for a measurement, nobody will act on it.
- Unrelated business data. Sales and stock figures have their place on an owner's KPI dashboard; mixing them into equipment monitoring makes both harder to read.
A good test: cover any element with your hand and ask whether anyone would miss it.
Different screens for different people
| Person | What they need to see | What they rarely need |
|---|---|---|
| Owner | Overall status of each site, open problems, weekly summary | Minute-by-minute charts |
| Manager or supervisor | Live status of their area, alerts to handle, who is on duty | Other branches' details |
| Technician | Device health, battery, signal, detailed history of one unit | Business summaries |
One dashboard can offer these as separate views or user roles. What matters is that each person lands on the screen that fits their job.
Designing for phones and patchy data
In Bangladesh most people will check the dashboard on a phone, often on mobile data, and sometimes from a district town with a weak signal. So:
- Design for the phone first. Large tiles, few charts, readable without zooming.
- Keep pages light so they load on a slow connection.
- Show "last updated" clearly. During a power cut or network drop, people must know whether they are looking at live data or an old snapshot.
- Offer Bangla labels where staff are more comfortable with them.
- Make actions simple: acknowledging an alert should take one tap, and noting what was done should take a line of text.
Questions to settle before anything is built
- Who will look at this dashboard, and what decision does each person make from it?
- Which units matter most, and what are their names on the floor?
- What counts as normal, watch and problem for each one? Take limits from equipment makers, your own procedures and qualified people, not from guesswork.
- How should a silent device appear?
- What summary would help in a weekly review?
Answer these on paper first; the screen design follows naturally. To go further, read about turning sensor readings into decisions. If you want a dashboard designed around your own sites, my IoT device development service includes it.