Designing Dashboards Operators Actually Act On

Picture a new line dashboard with 46 tiles, live trends for every sensor, a 3D model of the machine and a color for each product. The operators glance at it at the start of the shift and then go back to the old panel, because when something goes wrong the new screen doesn’t tell them what to do. Designing dashboards operators act on starts from a different question than “what data do we have?” It starts from “what does the operator need to notice, understand and decide, and how fast?” This guide walks through seven steps, drawing on the ISA standards for process HMIs and alarm management and on research into situation awareness and automation.

Key Takeaways

• Design from decisions. Endsley’s model of situation awareness has three levels (perceiving the elements, understanding what they mean, and projecting what will happen next), and a good display supports all three, not only the first.
• Show values against their normal range or target. A number without context makes the operator do the comparison in their head, every time.
• Use color sparingly and consistently, mostly for abnormal conditions. When everything is colorful, nothing stands out.
• Budget alarms. ISA-18.2 guidance cited in industry practice gives about 150 alarms per day (about one per ten minutes) as very likely acceptable and about 300 per day as the maximum manageable.
• Design for the abnormal situation. Bainbridge’s “Ironies of Automation” (1983) pointed out that automation leaves people the job of taking over when things go wrong, which is exactly when the display matters most.

The core problem: dashboards built from the data, not the decision

Most industrial dashboards are built bottom-up: the data platform exposes every tag, and the dashboard shows as many as fit. The result is easy to build and impressive in a demo. It’s also hard to use, because the operator has to search the screen for what matters, compare each number with a remembered normal value, and work out what a combination of readings means.

Normal operation hides the problem. When the process is stable, any display looks fine. The test of a dashboard is the abnormal situation: a pump trips, a temperature drifts, an upstream line stops. In those moments the operator needs the screen to answer what’s wrong, how bad it is, and what to do first.

Step 1: List the decisions operators make

Sit with operators for a shift and write down the decisions they make and the information each one needs. Typical decisions are whether the line is running as expected, which unit needs attention first, whether a deviation needs action now or can wait, and what action to take.

Endsley’s 1995 paper in Human Factors, “Toward a Theory of Situation Awareness in Dynamic Systems,” described situation awareness at three levels: perceiving the relevant elements of the environment, comprehending what they mean together, and projecting their status in the near future. Each decision on your list needs support at one or more of those levels. A raw value supports perception. A value against its limits supports comprehension. A trend with a projected time to limit supports projection.

Step 2: Show values against normal, not just values

For each value an operator uses, show it with its context: the normal operating range, the target or setpoint, and the alarm limits. An analog indicator or a small bar with the normal band marked lets the operator see at a glance whether the value is where it should be, without reading digits.

Trends work the same way. A short trend with the normal band shaded shows whether a value is stable, drifting or oscillating, which a number alone can’t. Choose time spans that match the process: minutes for a fast loop, hours for a tank level.

Step 3: Keep color for what needs attention

Use a muted, consistent palette for normal conditions and reserve strong colors for abnormal ones, especially alarm states. ISA-101.01-2015, the standard for human-machine interfaces in process automation, lists consistency and situational awareness among its key principles, and a consistent, restrained use of color is one of the most direct ways to apply them.

Avoid using color to distinguish categories that don’t need attention, such as product types or machine names, and don’t rely on color alone: add shape, position or text, because some operators have color vision deficiencies and some screens wash out in bright light.

Step 4: Build a hierarchy from overview to detail

Organize displays in levels: an overview of the whole area the operator is responsible for, a display per unit or line, a detail display per piece of equipment, and diagnostic displays for troubleshooting. The overview should show the state of everything in one view, with abnormal areas standing out; one click should take the operator to the unit, and another to the detail.

The overview is not a summary of every tag. It shows the few values per unit that tell whether the unit is healthy, against their normal ranges, and the alarm state of each unit.

Step 5: Design alarms as a system with a budget

An alarm, in ISA-18.2’s definition as summarized by Marcus Tennant in Control Engineering (2013), is an audible or visible indication to the operator of a condition requiring a response. Anything that doesn’t require a response is an event or a message, not an alarm.

The same article cites the performance targets associated with ISA-18.2: about 150 alarms per day, six per hour or one per ten minutes on average, as very likely acceptable, and about 300 per day, twelve per hour or two per ten minutes, as the maximum manageable. These are described as practical limits of human capability. A dashboard that fires more alarms than that teaches operators to ignore them.

Each alarm should have a defined cause, a defined response and a priority. Review the most frequent alarms regularly, remove those that don’t need a response, and fix chattering alarms with deadbands or delays.

Step 6: Design for the abnormal situation and the takeover

Lisanne Bainbridge’s 1983 paper “Ironies of Automation” in Automatica observed that the more a process is automated, the more the human’s role becomes monitoring and taking over when the automation fails, and that those are tasks people find hard: monitoring a stable process for long periods is tiring, and manual skills fade when they’re rarely used.

For dashboards, that means the critical design case is the moment of takeover. Test what the operator sees when a key piece of equipment trips: whether the first alarm points to the cause or to a consequence, whether the display shows what the automation was doing, and whether the operator can find the relevant controls and procedures quickly.

Step 7: Test with operators and keep improving

Show prototypes to operators early, with realistic data, including recorded or simulated abnormal situations. Ask them to find a problem and decide what to do, and measure how long it takes and where they look. ISA-101 frames HMI work as a lifecycle, from design through ongoing management, and that includes changing displays when the process changes and when operators find something confusing.

Data dashboard vs decision dashboard

Aspect	Data-first dashboard	Decision-first dashboard
Starting point	Every available tag	The decisions operators make
Values	Numbers and gauges	Values against normal range, target and limits
Color	Decorative and categorical	Muted for normal; strong colors reserved for abnormal
Structure	One crowded screen	Overview, unit, detail and diagnostic levels
Alarms	Every limit is an alarm	Each alarm needs a response; rate within budget
Trends	Long, everywhere	Short, with normal band, where projection matters
Tested with	Normal operation demo	Operators during recorded or simulated abnormal events

How to put it to work

If you have an hour

Pick one display and, for each value on it, write whether it has a visible normal range. Count how many colors are used for things that don’t need attention.

If you have a sprint

Shadow operators for a shift, list their decisions, then redesign one overview display around them with values against normal ranges and restrained color. Test it with a simulated trip.

If you want it to last the product’s lifetime

Measure alarm rates per operator against the ISA-18.2 targets every month, review the top ten alarms, and keep a change log for displays so operators know what moved and why.

The question to ask yourself: “When something goes wrong on this line, how many seconds does it take an operator to find what and where, and what do they look at first?”

Frequently asked questions

What makes a good industrial dashboard for operators?

It’s built around the decisions operators make, shows each value against its normal range, uses color mainly for abnormal conditions, lets the operator move from overview to detail quickly, and keeps alarms to a manageable rate.

How many alarms per hour can an operator handle?

Guidance associated with ISA-18.2 gives about six per hour (one per ten minutes) on average as very likely acceptable and about twelve per hour as the maximum manageable, as practical limits of human capability.

What is ISA-101?

ANSI/ISA-101.01-2015 is a standard for human-machine interfaces in process automation. It provides a lifecycle framework for HMI design and management, with principles that include situational awareness, consistency and clear navigation.

Should operator dashboards use a lot of color?

No. Using muted colors for normal conditions and reserving strong colors for abnormal states makes problems stand out. Color shouldn’t be the only cue, because of color vision differences and screen conditions.

What is situation awareness in HMI design?

It’s the operator’s perception of the relevant elements, understanding of what they mean, and projection of what will happen next, as described by Endsley. Displays should support all three, for example by showing values against limits and trends toward them.

Related reading: edge vs cloud processing for industrial data, vibration data for predictive maintenance and explaining an industrial automation product.

Sources

1. Endsley, M. R. (1995). “Toward a Theory of Situation Awareness in Dynamic Systems.” Human Factors, 37(1), 32–64. https://doi.org/10.1518/001872095779049543
2. Bainbridge, L. (1983). “Ironies of Automation.” Automatica, 19(6), 775–779. https://doi.org/10.1016/0005-1098(83)90046-8
3. ISA. ANSI/ISA-101.01-2015, Human Machine Interfaces for Process Automation Systems. https://www.isa.org/products/isa-101-01-2015-human-machine-interfaces-for
4. ANSI (n.d.). “ANSI/ISA 101.01-2015: HMI for Process Automation.” The ANSI Blog. https://blog.ansi.org/ansi/ansi-isa-101-01-2015-hmi-for-process-automation/
5. Tennant, M. (2013). “Implementing Alarm Management per the ANSI/ISA-18.2 Standard.” Control Engineering, republished by Yokogawa. https://www.yokogawa.com/uk/library/resources/media-publications/implementing-alarm-management-per-the-ansi-isa-182-standard-control-engineering