Insight

Real-time manufacturing dashboards: when clarity matters more than detail

8 Feb 2026

• Manufacturing
• HMI
• Real-time

A factory can collect thousands of values and still leave the shift team unsure why output has fallen. A useful manufacturing dashboard selects the few signals that explain the current condition, then keeps the supporting history close enough for investigation.

The first design question is not which chart library to use. It is who will look at the screen and what decision they are expected to make.

Match the view to the time horizon

Different roles work at different speeds.

An operator may need to know what changed in the last minute and which action is permitted. A shift leader may compare the current hour with the plan and coordinate help across stations. A process engineer may inspect events around a repeated loss. Management may compare lines, products or weeks.

These users can share definitions and source data without sharing one overloaded screen. Define the time horizon and decisions for each view. A real-time display should concentrate on the present process. Longer analysis belongs in a view that supports filtering and comparison.

Give every prominent element a question

Write the operational question beside each proposed chart during design. Examples include:

• Is the line running now?
• Are we on pace for the current plan?
• Which OEE component is responsible for the current loss?
• Where is material waiting?
• Which stop reason has repeated during this shift?
• Is the displayed state current enough to act on?

If the team cannot name the decision or action connected to a chart, reduce its prominence or move it to analysis. A metric may still matter for reporting without belonging on the main production view.

Show state before explanation

The top level should make current line state and important deviation visible at a glance. Use stable positions and labels. Avoid moving the status panel when an alarm appears or rearranging charts according to rank; people learn where to look during a busy shift.

Once a deviation is visible, provide a direct route into its context. Selecting a performance loss can open the relevant time range, stop reasons and events. Keep the user’s original line, product and period when the detail opens. Making them rebuild the filter context slows investigation and increases mistakes.

For OEE, the headline percentage rarely gives enough guidance on its own. Availability, performance and quality need separate visibility because each points to different work. The next level can then show the events and counts behind the affected component.

Treat freshness as part of the data

Real-time screens are only useful when users can tell how current they are. Network interruptions, delayed collectors and stopped devices can leave a convincing dashboard showing old values.

Display the last successful update where freshness affects action. Distinguish a measured zero from missing data. Decide how long a value remains valid and what the screen shows after that limit. A stale-state treatment should be noticeable without imitating a machine alarm.

Update frequency should follow the decision. A state indicator may need sub-second or event-driven updates. A cumulative production target may change less frequently. Refreshing every element at the highest rate adds load and visual movement without improving the work.

Use alerts for conditions that need attention

A dashboard and an alarm system have different responsibilities. Colouring every imperfect metric red creates a wall of warnings and teaches users to ignore them.

Define alert thresholds with the people responsible for responding. Include persistence where a brief fluctuation is normal. Show consequence and ownership: a blocked station needing immediate intervention is different from a trend that should be reviewed after the shift.

Do not rely on colour alone. Use labels, icons or shape, and keep normal, warning, stopped and unknown states distinct. Confirm that the palette remains legible on the actual display and under factory lighting.

Build from trusted events

Dashboard credibility falls quickly when totals do not match the production record. Agree on event definitions before polishing the interface. Decide what counts as planned time, a stop, a good unit, scrap and changeover. Record which system supplies each fact and how late or corrected events are handled.

Traceability should reach far enough to explain the headline. If a chart shows 37 minutes of downtime, the user should be able to see the events included in that figure. The calculation and its time boundary need to be consistent across the operator, engineering and management views.

Test during ordinary disruption

Use realistic production data and failure conditions. Test shift changes, changeovers, short stops, missing reason codes, late events and a disconnected data source. Observe whether users can answer the target questions without opening another system or calculating values manually.

A wall-mounted screen must be tested from its viewing distance. A tablet interface needs touch targets suitable for the environment. An operator station must remain stable while live values change. The same information hierarchy will not suit every device.

Our Manufacturing HMI case study shows a view that connects current OEE losses with the line events behind them. The Robotic Digital Twin addresses a related problem at equipment level: making live state understandable away from the cell while keeping observed and commanded state distinct.

The strongest manufacturing dashboards reduce the time between a change and an informed response. They do that through disciplined definitions, visible freshness and a clear path from the current state to the events that explain it.