Color is the most misused tool on an operator screen. Used carelessly, it turns a display into visual noise; used with discipline, it directs the operator's eye straight to what matters. This guide explains the color-coding conventions of high-performance HMI - why saturated color is rationed, why color alone is never trusted, and how color maps to alarm priority - as a set of practical rules an integrator applies when building screens.
HMI Color Coding in one line: An HMI color-coding convention is the set of rules governing how color is used on operator displays. In high-performance HMI, saturated colors are reserved almost entirely for abnormal conditions and mapped to alarm priority, while normal operation uses muted grays. Color is never the only way information is conveyed - it is backed up by shape, position, and text so the display remains readable to colorblind operators and under poor lighting. The aim is that any bright color on the screen carries real meaning.
The founding rule of high-performance color coding is that saturated color is scarce and meaningful. On a well-designed screen the normal state is rendered in low-contrast grays, and bright colors - red, amber, sometimes magenta or other high-priority hues - appear only when something is abnormal. Because they are rare, they are salient: when one red element shows up on an otherwise gray screen, the operator's eye finds it in a fraction of a second. The moment a designer starts using bright color decoratively - green running pumps, blue water, colored pipes everywhere - that salience is destroyed, and a genuinely abnormal red has to compete with a dozen equally loud colors.
This is the single biggest departure from traditional graphics, and the one integrators most often resist because a gray screen looks less impressive than a colorful one. But the discipline pays off precisely when it matters, during an upset, when the operator must locate the abnormal elements fast. A useful test when building a screen is to ask, of every colored element: does this color mean the operator needs to act? If not, the element should be gray. Reserving color this way is what makes an abnormal condition pop rather than hide.
A significant fraction of people have some form of color vision deficiency, most commonly difficulty distinguishing red from green - which are exactly the colors a naive design uses for alarm and normal. For this reason high-performance HMI treats color as one channel among several, never the sole carrier of information. Alarm state is shown redundantly: a high-priority alarm might be indicated by a red element and a distinct shape or symbol and a text label or a number showing priority, so an operator who cannot distinguish the color still gets the message from the shape and text.
Redundant coding protects against more than colorblindness. Screen calibration drifts, control rooms have glare and varying light, and a value in a small indicator may be hard to judge by hue alone - so backing color with shape, position, blink, and text makes the display robust to all of these. The practical rule for an integrator is straightforward: whenever color communicates something important, encode the same information a second way. This also means avoiding red and green as the only distinction between two states, and choosing palettes that remain distinguishable to colorblind operators.
The colors that do appear should map consistently to alarm priority, so an operator learns one scheme and applies it everywhere. Typically the highest-priority, most urgent alarms use the most attention-grabbing treatment - a saturated red, often flashing until acknowledged - with lower priorities using progressively less urgent colors and steady rather than flashing indication. The exact palette is defined once in the HMI style guide, under the ISA-101 framework, and then applied identically across every screen so a color always means the same thing regardless of which display the operator is looking at.
In a cloud SCADA such as Merobix, this consistency is easier to guarantee because screens are built from a shared library and served centrally, so a priority color defined once appears the same on every well-pad, separator, and pipeline screen and on every operator's browser. As Merobix reads tags over Modbus, DNP3, OPC UA, and MQTT and evaluates alarm conditions, mapping those conditions to a disciplined, priority-based color scheme - backed by shape and text - is what lets an operator watching a wide field of sites instantly rank what needs attention first. Consistent color-priority mapping across many remote sites turns a scattered operation into one an operator can triage at a glance.
Because saturated color only works as an attention signal if it is rare. When bright colors are used decoratively for pipes, running equipment, and background elements, a genuinely abnormal value has nothing to distinguish it. Reserving color almost entirely for abnormal conditions keeps it meaningful, so any bright element on an otherwise gray screen immediately draws the operator's eye to something that needs action.
Because a meaningful fraction of operators have some color vision deficiency, and because glare, screen calibration, and small indicators can all make a color hard to read. High-performance design encodes important information - especially alarm state - redundantly through shape, position, and text as well as color, so the message gets through even when the color cannot be reliably distinguished.
Colors should map consistently to alarm priority, with the most urgent alarms getting the most attention-grabbing treatment, often a saturated flashing red, and lower priorities using progressively less urgent, steady indication. The exact palette is defined once in the HMI style guide and applied identically across every screen so a given color always carries the same priority meaning.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.