ISA-101 HMI Design Standard: A Practical Guide

ISA-101.01 — “Human-Machine Interfaces for Process Automation Systems” is the standard that ended the era of rainbow-colored HMIs full of blinking gauges. Published by the International Society of Automation, it codifies what experienced operators and human-factors researchers have known for decades: a good HMI is mostly gray, and color means something is wrong.

This guide walks through the parts of the standard you actually need on a project: the lifecycle model, situation awareness, the hierarchy of displays, color and font usage, and the alarm priority scheme. It is written for engineers who design or buy HMI screens, not for compliance auditors.

1. Scope of the standard

ISA-101 governs the design, implementation, operation, and maintenance of HMIs used in process automation — DCS consoles, SCADA workstations, and modern web-based supervisory dashboards. It is intentionally agnostic about the platform: the same rules apply whether your operator stares at a Siemens WinCC console, a Rockwell FactoryTalk View ME panel, or an Ignition Perspective screen on a tablet.

The standard does not define every pixel of every symbol — it defines the system of constraints a designer should work within. That is where ISA-5.1 (instrumentation symbols) and a consistent project symbol set come in, complementing ISA-101 with concrete, drawable shapes. Whether you draw that set yourself or start from what other engineers have published, the constraints below are what make it ISA-101.

2. The HMI lifecycle

One of the quiet wins of ISA-101 is forcing teams to think of the HMI as a product with a lifecycle, not a one-shot deliverable scribbled into the engineering schedule. The standard defines five phases:

1. Standards & Style guide — the project freezes a palette, fonts, symbol library, alarm priorities, and naming convention before a single screen is drawn.
2. Design — display hierarchy is laid out (overview → unit → detail → diagnostic), task analysis identifies what the operator needs to see, and console layout is documented.
3. Implementation — screens are built using the style guide and library; SAT/FAT validates them.
4. Operation — the HMI is in production. Operator feedback is captured.
5. Maintenance & MoC — changes go through Management of Change with documented review.

3. Situation awareness — the core idea

Endsley's three-level model of situation awareness is the spine of ISA-101: an operator is effective only if they can perceive what is happening, comprehend what it means, and project what will happen next. Every design decision in the standard maps back to one of those three levels.

If two screens have the same information density and one helps the operator project the future state of the plant while the other does not, the second screen is failing — even if it looks prettier.

Practically, this means designing for trends and rates of change as much as for instantaneous values, and making it visually obvious which loops are about to alarm — not just which ones already have.

4. Color: the most-violated rule

ISA-101's color philosophy is the part teams break first. The rule, stripped to its essence:

• Normal operation should be drawn in muted gray and white. Process lines, equipment, vessels, labels, and most numbers stay neutral.
• Color is reserved for abnormal conditions and operator state changes. Red, orange, yellow, blue — these signal alarms or running/stopped/disabled state, never decoration.
• Match alarm color to alarm priority, with a colorblind-safe combination of color + shape + position so a red-green colorblind operator can still distinguish P1 from P3.

The palette HMI Library applies everywhere — the Symbol Builder defaults, the generic icon library, and the automatic ISA-101 check that community symbols go through before they earn the “ISA-101 compliant” mark (Inter for labels, JetBrains Mono for tags):

5. Alarm priorities

ISA-101 defers alarm management proper to ISA-18.2, but it inherits the same priority scheme that the alarm rationalization process produces:

Suppressed and shelved alarms get their own neutral icon — they are not absent, just deliberately hidden.

6. Display hierarchy

ISA-101 prescribes four levels of display, and good HMIs make the level you are on instantly obvious:

1. Level 1 — Overview: the whole site or process area on one screen. KPIs, alarm counts, abnormal-condition indicators. Designed for the supervisor or shift lead glancing at it from across the room.
2. Level 2 — Unit/Area: one process unit or area. The screen the panel operator works from for routine monitoring.
3. Level 3 — Detail: a specific equipment item (a reactor, a compressor train, a pump skid) with all its loops, interlocks, and operational controls. This is where the operator does things.
4. Level 4 — Diagnostic/maintenance: deep instrument diagnostics, valve travel, maintenance metadata. Often hidden from the panel operator role.

7. Typography

Sans-serif, 14 px or larger for primary readouts, monospaced font for tag IDs and numbers (so columns of numeric values align). HMI Library standardizes on Inter and JetBrains Mono — both free on Google Fonts. The Symbol Builder uses them by default and falls back to Helvetica/Arial, so a symbol keeps its proportions on an HMI runtime that cannot embed web fonts.

8. Common pitfalls

• Decorative color. A green pump because “green is nice” trains operators to ignore green when it actually means something.
• 3D and gradients. Photorealism slows scanning. Flat 2D wins every usability test.
• Static blink animation on non-alarm objects. If half the screen blinks, none of it does.
• Mismatched symbols across screens. A pump must look the same on every screen of the system. This is the #1 reason to fix one symbol set per project and stick to it — draw it once, reuse it everywhere.
• No “normal” state design. Teams design alarm states first and forget that 99% of the time the screen is showing normal — and that normal must be readable too.

9. How HMI Library helps you apply it

HMI Library is one automation technician's toolset plus what the community publishes on top of it. Three pieces map onto the rules above:

• Symbol Builder — a free, in-browser editor that starts you on the ISA-101 palette (gray body, color only for state and alarm badges), the 14 px minimum and the 9-state convention for motorized elements (see the 9-state guide). It exports transparent PNG for Weintek EasyBuilder Pro and clean SVG for WinCC Unified, FactoryTalk, Ignition, Citect and AVEVA. No account needed to draw.
• Community library — motors, valves, pumps, tanks, conveyors and process equipment drawn by other engineers and published under CC BY 4.0. Each published symbol runs through an automatic ISA-101 check (palette, stroke, structure); the ones that pass carry an “ISA-101 compliant” mark, so you can filter for them. Found one that is nearly right? Open it in the Builder, adjust, republish with credit.
• Generic icon library — the small official set that every screen needs regardless of industry: arrows, state badges, alarm priority icons, indicators, ISA-5.1 instrument bubbles and signal lines, hazard pictograms (ISO 7010), and HMI navigation/system icons. All on the palette above, with tags and labels toggleable so you can leave them off when the HMI handles tagging through text objects.

Both the catalog and the Builder let you change palette and font live and watch the icons re-render — useful when a client insists on a slightly off-white background or a different tag font. Downloads are metered per account (Free plan: 5 a month; Starter 50; Studio unlimited); exporting symbols you publish yourself is always free.

10. References

• ISA-101.01-2015 — “Human Machine Interfaces for Process Automation Systems”
• ISA-18.2-2016 — “Management of Alarm Systems for the Process Industries”
• ISA-5.1-2009 — “Instrumentation Symbols and Identification” (see our companion guide)
• Endsley, M. R. (1995). “Toward a theory of situation awareness in dynamic systems”
• Bill Hollifield et al. — “The High Performance HMI Handbook”