# High-performance HMI: 8 rules for a web supervision screen

Source : https://consignestudio.fr/en/guides/high-performance-hmi-rules/ · published 2026-10-27 · Antoine Despres, Consigne

A high-performance HMI is calm when everything is fine, so that an abnormal situation stands out in a second. In practice: a grey background, colour reserved for alarms, every measurement shown against its normal range, four levels of displays, and two-step commands. Here are the eight rules and how they translate into web code.

## Why supervision screens wear operators out

A supervision screen is watched for eight to twelve hours at a stretch by someone whose job is to notice what changes. Anything that catches the eye for no reason uses up some of that attention: green and red pumps, permanently animated pipes, round gauges with no reference, a navy background. After a few weeks the operator no longer sees colour, because it means nothing. The day it signals a real problem, it goes unnoticed.

Web developers often reproduce these flaws in good faith. They apply reflexes that are right elsewhere: the marketing dashboard that must impress, the consumer design system where green means "success", responsive layouts that rearrange the screen, the charting library that rescales on its own. In a control room, each of these reflexes does harm.

The "high-performance" approach was set out in the *High Performance HMI Handbook* (2008), then framed by ANSI/ISA-101.01-2015. Its central idea fits in one sentence: **in normal operation the screen must be calm, so that the abnormal shows the moment it appears.**

## The 8 rules and their translation into code

| Rule | What it means | Web translation |
|---|---|---|
| 1. Calm by default | Grey background, neutral elements, almost no bright colour in normal operation | a light grey `--hmi-bg` token, equipment in dark grey |
| 2. One colour, one meaning | Each bright colour has a single use: an alarm priority, or data quality | four `--hmi-alarm-1…4` tokens, one quality token, nothing else |
| 3. Information, not data | The value is shown with its position relative to normal | an analog bar with normal range and L, H, LL, HH limits |
| 4. Time as context | A short trend next to key measurements shows drift before the limit | a 15 to 60 minute mini-trend on a fixed scale |
| 5. Display hierarchy | Four levels, from the site to diagnostics | routes `/site`, `/unit/:id`, `/equipment/:id`, `/diagnostic/:id` |
| 6. Redundant coding | Shape, colour and text say the same thing | triangle, diamond, square or circle badge with a number and an `aria-label` |
| 7. Honest data | A doubtful, forced, simulated or frozen value is flagged as such | every measurement carries `{ value, quality, sourceTime }` |
| 8. Safe commands | Every action takes two steps, and the screen shows the returned state, not the command sent | select, then confirm; display the PLC feedback |

## Rules 1 and 2: grey first, colour second

A light grey background has two solid justifications: it dazzles less than pure white over long periods, and it leaves room in both directions (dark text, a lighter surface and a darker symbol all remain distinguishable).

A common claim is that grey makes alarm colours stand out better than a black background. Contrast calculations do not bear this out. On a well-chosen dark background, an alarm red often contrasts better than on light grey. The case for grey is about comfort and consistency with the control-room lighting, not contrast.

What really matters is scarcity. If the running pump is green, the open valve green and the full tank blue, an alarm's red has to fight the whole screen. If everything is grey, it wins without effort.

In code, the rule holds through CSS tokens. Bright colours exist only under alarm names: a developer who wants to colour a button "to make it look nice" simply finds no token to do it with.

> Colours must also meet contrast thresholds. WCAG criterion 1.4.11 asks for 3:1 for a graphical object. A yellow light enough to be perceived as yellow does not reach it on grey: the yellow badge then gets a dark outline, and its shape carries the information.

## Rule 3: show information, not a number

"72.4 °C" does not say whether that is good. The high-performance analog bar does: a grey bar, a subtly marked normal zone, limit marks and a pointer. While the pointer is inside the normal zone, nothing stands out. As soon as it crosses a limit, the value takes the colour of the alarm priority.

Lining up several bars vertically has a powerful effect: the eye instantly spots the pointer that is out of line with the others. That is why high-performance displays look like rows of small bars rather than round gauges.

## Rule 4: time as context

An instantaneous value hides its trend. A temperature at 85 % of its high limit and steady calls for no action; the same value rising for twenty minutes does. A short trend next to each key measurement makes drift visible before the alarm.

Two pitfalls specific to web libraries: autoscaling (which turns measurement noise into an apparent disaster) and animated transitions (which make the screen move for no reason). A process trend has a fixed scale, set by engineering, and does not animate.

## Rule 5: four levels of displays

| Level | Question | Typical content |
|---|---|---|
| 1. Overview | Is everything fine on site? | key indicators, unit status, alarm counts by priority |
| 2. Unit | How is this unit behaving? | simplified process graphic, analog bars, short trends |
| 3. Detail | What is happening on this equipment? | faceplate, setpoints, modes, interlocks |
| 4. Diagnostic | Why, and what to do? | raw data, I/O, procedures |

Level 2 is the working display: design it first and test it with operators. A good acceptance criterion: from any display the operator reaches level 1 in one click, and any equipment in alarm in two clicks at most from the alarm list.

One consequence for the web: **no responsive layout**. The operator finds each measurement in the same place every day; position is part of the information. Design a fixed grid per monitor format, not a layout that rearranges itself.

## Rule 6: code every alarm three times

About 8 % of men of European descent have some form of red-green colour blindness. In a team of forty operators, two or three are probably affected, and for them red and orange merge. Each priority is therefore carried by its colour, its shape and its number, and described in text for screen readers.

The distribution of priorities matters as much as their number. A commonly quoted order of magnitude for three priorities is about 80 % low, 15 % medium and 5 % high. If half of a site's alarms are "high", priority no longer sorts anything.

## Rule 7: never lie about the data

A web HMI adds sources of lies that a classic SCADA handles on its own: a dropped WebSocket that leaves the last value displayed, a `null` turned into 0, a `NaN` displayed as is. A value frozen by a lost link looks exactly like a stable value.

The defence: every measurement carries its quality and source timestamp, and the link is monitored by a heartbeat, not only by the age of the last value. Doubtful data takes the colour reserved for quality, different from every alarm colour, so a sensor problem is never mistaken for a process problem.

## Rule 8: two-step commands

A click does not start a pump. You select the equipment, then confirm the action in a panel that states what will happen. The screen then shows the state **returned by the PLC**, not the command sent: if the pump has not started, the operator must see it. When a command is impossible (interlock, local mode), the screen says why instead of greying the button without explanation.

## Check a screen in 5 minutes

1. **Five-second test**: show the screen for five seconds to someone who does not know it, hide it, ask "is there a problem, and where?".
2. Count the bright colours in normal operation. More than zero or one is too many.
3. Look for a measurement displayed with no reference to normal.
4. Print the screen in greyscale: can you still tell the alarm priorities apart?
5. Cut the link: does the screen show it within a few seconds?

> These rules are neither a style guide nor a certification. Each site adjusts them to its lighting and alarm philosophy, then writes them into an HMI style guide that every display follows. For a contractual commitment, the text of the standard prevails.

## Going further

The [High-Performance HMI guide for web developers](https://consignestudio.fr/en/high-performance-hmi-guide/) covers each of these rules over 55 pages, with tested code and a 40-point audit checklist (a 10-point extract is free). The [hmi-kit components](https://consignestudio.fr/en/hmi-web-components/) apply these rules as Web Components for Angular, React or plain HTML, and the [SVG process graphic](https://consignestudio.fr/en/svg-process-graphic/) assembles them into an animated unit display.

## Sources

- Bill Hollifield, Dana Oliver, Ian Nimmo, Eddie Habibi, The High Performance HMI Handbook, PAS, 2008
- ANSI/ISA-101.01-2015, Human Machine Interfaces for Process Automation Systems
- ANSI/ISA-18.2 and IEC 62682, management of alarm systems
- EEMUA Publication 191, Alarm systems, a guide to design, management and procurement
- [W3C, WCAG 2.2, success criterion 1.4.11 Non-text Contrast](https://www.w3.org/TR/WCAG22/#non-text-contrast)