Why most HMIs are bad
The default HMI in most factories looks like a 1998 P&ID diagram with thirty motor symbols, twelve numeric readouts, and a pop-up alarm window that the operator dismisses without reading. It's not bad because the engineers were lazy — it's bad because the priorities at design time were "show everything" rather than "support the decision the operator is making right now".The principles below are what we apply to every new HMI screen we build.
One screen, one decision
Every screen exists to support exactly one decision. "Is the line healthy?" is one screen. "Why is station 4 in fault?" is a different screen. Mixing them creates a cluttered, ignored interface.The hierarchy that works:
- Level 1 — overview. Line status. Throughput. Active alarms count. Fits on a single 1080p panel, glanceable from across the room.
- Level 2 — station detail. Drilled into when something at Level 1 demands attention. Shows status, recent events, current set-points, last-cycle data.
- Level 3 — diagnostic. Trend graphs, raw I/O, parameter editing. Behind a login.
Most factory HMI sins are conflations of these three levels onto one screen.
Color discipline (high-performance HMI principles)
Greyscale is the default. Color is reserved for things that demand attention. Specifically:- White / black / grey for normal state, equipment, layout
- Red only for alarms requiring immediate action
- Yellow only for warnings or out-of-tolerance values
- Blue / muted for informational accents (selected element, current process step)
A green motor symbol "to show it's running" is exactly the wrong color use — running is normal, normal shouldn't draw the eye. The motor that's not running when it should be is the one that needs to be visible.
Set-points, not raw values
Don't show a temperature of 187 °C and expect the operator to remember the setpoint is 190 °C and the band is ±5. Show the deviation, color-coded against the band. The operator's job is to act on out-of-band; the HMI's job is to make out-of-band obvious.A good rule: every numeric value on the screen is one of:
- Trended graphically with set-point overlay
- Replaced with a deviation indicator (e.g. -3 °C below target, in yellow)
- Hidden behind a click — operators who want the raw value will dig
Alarm philosophy
- Alarms exist for events that require operator action now
- Anything that doesn't require action is a notification, not an alarm
- Maximum 5 active alarms before the system is in a degraded state — the operator can't process more
- Every alarm has a written response procedure, accessible from the alarm itself
- Alarm rate ≤ 1 alarm per 10 minutes during steady operation
If the system can't meet those numbers, the problem isn't operator inattention — it's the alarm design. Audit and rationalise.
One thing operators always ask for and we usually push back on
"Can we have a button to reset all alarms?". No. The reset-all button trains operators to clear alarms without reading them. Acknowledge individually, with a reason where required. Slower, by design.Toolchain
We've shipped HMIs in WinCC Unified, TwinCAT HMI, Inductive Automation Ignition, and a couple of bespoke web stacks (React + WebSocket + OPC UA gateway). Ignition is our default for greenfield where the customer doesn't have a Siemens lock-in. WinCC Unified is the answer when they do.What's your HMI stack? And how do you handle screen-resolution / panel-size variation across multi-line deployments?
