You install a nice HMI with alarm banners, pop-ups, and flashing lights. Six months later, the operators have taped over the tower light and click through every popup without reading them. The screen works. The operators don’t trust it.
Alarm fatigue is a design problem
An HMI that alarms on every out-of-spec condition trains operators to ignore all alarms. If the screen shows 40 alarms during a normal shift, the operator learns that most of them clear themselves and none of them matter. When a real fault happens, it sits in a list of 39 other messages and nobody notices.
The ISA 18.2 standard defines an alarm as a signal that requires immediate operator response. If an alarm doesn’t require immediate action, it’s not an alarm. It’s an event. Log it, don’t flash it. This distinction is where most HMIs go wrong.
The three alarm tiers
Every message on an HMI should fall into one of three buckets. A critical alarm stops the machine or triggers a safety function. It needs a dedicated popup, an audible horn, and operator acknowledgment. These should happen a handful of times per shift, not 40.
A warning indicates a trend moving toward a limit. It changes the color of a parameter on the overview screen. No popup, no horn. The operator sees it during the normal scan of the screen.
An event is informational: a recipe loaded, a shift change, a part counted. It goes to a log. It never appears as a popup.
If your HMI treats all three the same, you’ve built an operator who clicks through popups reflexively.
Screen layout people actually use
The main overview screen should show the whole process at a glance: the machine, the material flow, and the few parameters that matter. A good overview fits on one screen without scrolling. If you need three tabs to see the state of one machine, the layout is wrong.
Put the critical parameters where the operator looks first: the top-left corner, in large digits. Temperature, pressure, speed, part count. Don’t bury a critical temperature inside three levels of menus. If the operator has to navigate to find it, it’s not useful during a fault.
Color is not decoration. Red means stop or fault. Yellow means warning. Green means running. Don’t use blue, purple, or orange for anything operational. If every color means something, no color means anything.
The 10-second rule
When the machine faults, the operator should be able to look at the overview screen and understand what happened within 10 seconds. If the fault screen requires navigating to a diagnostic page, reading a code, and looking up a manual, you’ve already lost the first 10 seconds of downtime.
Show the active fault prominently on the overview. Show the cause, not just the code. “Air pressure below 4 bar” is better than “Fault 4021”. If the operator needs to look up the code, the HMI is documenting itself, not helping the operator.
What operators actually want
Watch an operator use your HMI during a normal shift. They look at the overview for two seconds, check the part count, and go back to what they were doing. They don’t study trends or read historical logs on the floor. Design for that glance, not for the training manual.
If the operator needs to enter a value, make the field large. If they need to start or stop a machine, make the button a physical mushroom, not a soft button buried three screens deep. The HMI is for monitoring and diagnosis; physical controls are for action.
Bottom line
A good HMI doesn’t show the operator everything. It shows them what matters right now. If your alarm list is longer than your to-do list, you’re not communicating; you’re generating noise. Design the screen for the glance, the fault, and the 10-second diagnosis, and the operators will actually look at it.
