Home › Guides › HMI Design Guide

HMI Design Guide: Interfaces Operators Can Actually Use

Walk into two control rooms and the difference is obvious before anyone explains it. In one, every screen is a riot of colour: bright green pipes, animated pumps, flashing numbers, red and yellow everywhere, even when the plant is running perfectly. In the other, the screens are calm and mostly grey, with a few quiet numbers — until something goes wrong, when one valve turns red and the operator's eye goes straight to it. The second room is practising high-performance HMI, and study after study of real incidents shows it is not a cosmetic preference: operators detect abnormal situations faster, and respond correctly more often, on calm screens than on busy ones. This guide explains the principles behind that difference — the ISA 101 lifecycle, colour discipline, alarm management, navigation and layout — so you can judge any HMI you meet, and design better ones yourself. It pairs with our guides to PLC basics and industrial networks, which cover what sits behind the screen.

The operator's real job — and what the screen is for

An HMI is not a process mimic diagram for visitors, and it is not a data dump. Its job is to support one person — the operator — in three tasks: monitoring the process in normal operation, detecting abnormal situations early, and responding correctly under time pressure. Everything on the screen should be judged against those three tasks. A value that no operator decision depends on does not belong on an overview screen, however interesting it is to an engineer. A graphic that looks impressive in a sales demonstration but slows down fault-finding at 3 a.m. is a liability, not a feature.

The design standard that formalised this thinking is ISA 101, which treats HMI design as a lifecycle: define the operator's tasks and the philosophy, design the displays, build them, test them with real operators, and keep improving them from operating experience. The single most useful habit from ISA 101 is to involve operators early. The people who will live with the screens know which information they actually check, which alarms they ignore, and which navigation path wastes their time — and they will tell you, if you ask before the design is frozen rather than after commissioning.

High-performance HMI: calm screens, loud abnormalities

The core idea of high-performance HMI is simple: the screen should be quiet when the process is normal, so that it can be loud when the process is not. In practice that means a muted palette — greys and dark blues for pipes, vessels and background — with bright colour reserved strictly for abnormal states: red for a stopped pump that should be running, yellow for a value approaching a limit, flashing for an unacknowledged alarm. Animation follows the same rule: a pump symbol should not spin merrily forever, because a spinning symbol carries no information when it always spins. Instead, show state changes — a pump that has stopped when it should be running changes colour and shape, and that change is the message.

The same discipline applies to numbers. An overview screen should show the handful of values that define the health of a unit — key flows, levels, pressures, temperatures — with clear units and sensible precision. A temperature shown to three decimal places implies a precision the instrument does not have and clutters the operator's view; one decimal place, with a trend available one click away, is usually right. Trends deserve emphasis: operators think in trends, not snapshots. A level that is steady at 60 percent is a different situation from a level falling through 60 percent, and only a trend shows the difference. Put small trend sparklines beside critical values on overview screens, and full trends on detail screens.

Colour discipline: a small palette, used consistently

Colour only works as an alarm channel if it is used consistently and sparingly. That means a written colour standard for the whole site, applied to every screen: one colour for running, one for stopped, one for alarm, one for warning, and the same meaning everywhere. The moment one screen uses red for "running" and another uses red for "alarm", the operator has to stop and think about which screen they are looking at — exactly when they can least afford to. Avoid relying on colour alone: pair it with shape or text (a stopped pump shown as a hollow outline as well as a colour change) so that the information survives colour-vision deficiency and poor lighting.

There are two classic mistakes to avoid. The first is the "Christmas tree" screen, where every pipe is bright green, every valve is coloured, and alarms are invisible because everything already shouts. The second is using red and green as the only distinction between states, which fails for the significant minority of operators with red-green colour-vision deficiency. Test every screen in greyscale: if the abnormal states are still obvious from shape, text and position, the design is sound; if they vanish, colour was doing work that shape should have been doing.

Alarm management: fewer, better alarms

The worst HMI failure is alarm flooding: a single process upset triggers dozens or hundreds of alarms in a few minutes, and the operator, overwhelmed, acknowledges them in bulk without reading them — including the one alarm that mattered. The alarm management standard ISA 18.2 exists because this pattern has contributed to real disasters. Its core principles are: every alarm must require an operator response, every alarm must be meaningful, and the steady alarm rate in normal operation should be very low — the commonly cited target is around one alarm per operator per ten minutes, with clear guidance for upset conditions.

Getting there takes work, and it is mostly about removing alarms rather than adding them. Common fixes include: deleting alarms that nobody acts on (they are status indications, not alarms, and belong on a display, not in an alarm list); adding deadbands and delays so a value hovering on a limit does not chatter; suppressing consequential alarms during a known state, such as a planned shutdown, so the operator sees the root cause rather than fifty consequences; and prioritising honestly, with only a few alarms ever marked critical. Alarm rationalisation — reviewing every alarm with the operators who receive it — is unglamorous work, and it is the highest-value HMI work most plants can do.

Navigation and layout: three clicks to anywhere that matters

Navigation should follow the process, not the PLC's memory map. The standard structure is a hierarchy: a plant overview at the top, then unit overviews, then equipment detail screens, then the lowest level of loop and device detail. From any screen, the operator should reach any other important screen in no more than about three clicks, and the navigation path should be visible — breadcrumbs, a consistent menu, and a clear indication of where they are. Every screen needs a consistent layout too: the same place for the title, the same place for navigation, the same place for the alarm banner, so the operator never has to hunt for the basics.

Detail screens deserve the same care as overviews. A pump detail screen should show everything needed to operate that pump — its state, its mode (auto, manual, local), its speed or current, its trips and permissives, and its start/stop controls — in one place, without forcing the operator to open three other screens. Controls need confirmation for consequential actions: starting a large motor or opening a major valve should require a deliberate confirmation step, and the screen should show the result of the action clearly. Finally, test the whole design with real operators doing realistic tasks, including upset scenarios, before it goes live. A screen that passes a design review but confuses an operator under time pressure has failed its only real test.

Frequently asked questions

← Back to all guides · PLC basics · PLC languages · Industrial networks · SIL & safety systems