HMI Screen Design Principles: 10 Rules for Better Screens
HMI screen design principles — layout, navigation, color, alarms, fonts, and consistency rules that make operator screens clearer, faster, and safer to use.
HMI screen design principles are the human-factors rules that determine whether an operator can act quickly and correctly under pressure — or gets confused, misreads a value, and causes a process upset. Good screen design is not about making interfaces look polished. It is about reducing cognitive load at 2 a.m. during an alarm flood.
This guide covers the ten principles that matter most in practice, grounded in ISA-101.01-2015 and the high-performance HMI methodology, with specific guidance on faceplate standardization, alarm color discipline, and navigation that maps to your process.
For a deeper foundation before working through these rules, our HMI design best practices guide covers the full ISA-101 display hierarchy and the grayscale graphics philosophy that underpins the principles below. If you are new to operator interface programming, the HMI programming tutorial walks through the implementation side step by step.
Rule 1: Design for the Operator's Task, Not the Engineer's Model
The single most common mistake in HMI screen design is building screens that mirror the PLC program — or worse, the P&ID — rather than the tasks operators actually perform.
An engineer thinks in tags, function blocks, and signal paths. An operator thinks in process states: is this unit running normally, starting up, or in trouble? Those are completely different mental models, and the screen must match the operator's model.
What task-centered design looks like in practice:
- Group information by what an operator needs to make one decision, not by which PLC rack the data comes from.
- Put the most-used controls within the primary viewing zone (center third of the screen), not scattered based on where equipment sits on the P&ID.
- Surface the status an operator checks first — running / stopped / faulted — in the largest, most visible element on a unit's overview screen.
- Reserve detail screens (valve positions, individual sensor readings, PID tuning) for when an operator drills down intentionally. Do not flood the overview screen with data that is only needed during commissioning.
The key question to ask about every screen: "What decision does an operator make here, and what is the minimum information needed to make it correctly?" If elements on the screen do not answer that question, they are visual noise.
Rule 2: Consistent Layout and Navigation
An operator who has to think about where to find a button is an operator who is not thinking about the process. Layout and navigation consistency is the single best cognitive-load reducer available to a screen designer.
Navigation structure: Map your screen hierarchy to your process hierarchy, not to your project folder structure.
| Process level | Screen type | Access method |
|---|---|---|
| Whole plant / site overview | Level 1 — Area overview | Always available from global nav bar |
| Process unit (e.g., Reactor 1) | Level 2 — Unit overview | Click unit on area overview |
| Individual loop or device | Level 3 — Detail / faceplate | Click equipment on unit overview |
| Trend, report, historian | Level 4 — Diagnostic | Dedicated menu item, not inline |
Layout rules to enforce across all screens:
- Fix the global navigation bar position — always top or always left, never alternating.
- Put the alarm banner in the same position on every screen (top of content area is standard).
- Place the clock, operator name, and server status in the same corner on every screen.
- Use the same screen template for the same screen type. Every unit overview uses template A; every detail screen uses template B.
Operators build spatial memory for frequently used screens. Changing a button's position between screens destroys that memory and forces conscious search — which is expensive under stress.
Rule 3: Use Color Meaningfully — Not for Decoration
Color is one of the most powerful tools in HMI screen design and one of the most commonly misused. The ISA-101 high-performance HMI philosophy makes color use explicit: the background and most screen elements should be neutral (gray scale), and color is reserved for process state information that requires attention.
The core color discipline:
| Color | Reserved for | Must NOT be used for |
|---|---|---|
| Red | Alarms — critical / emergency state | Equipment labels, branding, pipe identification |
| Amber / Yellow | Alarms — high priority / warning state | Decorative highlights, headers |
| Green | Running / normal state (use sparingly) | General positive indicators, logos |
| Gray (varied tones) | All background, equipment outlines, inactive state | — |
| White | Key values that need to stand out | General body text |
Why gray backgrounds matter: A gray background means that red and amber alarm states pop immediately against the display. On a dark-blue or high-contrast decorative background, alarm colors compete with the interface itself and operators miss annunciations.
Practical implementation: Start your template with a mid-gray background (HSL approximately 0°, 0%, 30–40%). Apply color only to dynamic elements — equipment state indicators, valve position symbols, alarm banners. Run your completed screen through a color-blindness simulator (deuteranopia is most common in industrial populations, affecting approximately 6% of men). Red/green combinations must always have a secondary differentiator — shape, label, or position.
For a more detailed treatment of alarm color discipline, see our alarm management best practices guide.
Rule 4: Make Alarms Stand Out — and Only Alarms
If everything is alarming, nothing is. This principle is the intersection of alarm management and screen design, and getting it wrong causes alarm floods that operators cannot respond to effectively.
Three screen-design rules for alarms:
1. Use color exclusively for alarm state. If red appears anywhere on your screen that is not an active alarm — in a logo, a pipe label, a section header — operators will habituate to red and slow their alarm response. Reserve it absolutely.
2. Animate only active alarms. Flashing or blinking is the highest-attention draw available on a static screen. Use it only for unacknowledged Priority 1 (critical) alarms. Never animate decorative elements. When operators see a flashing element, they must know it is a P1 alarm, unconditionally.
3. Surface alarm counts, not alarm lists, on overview screens. An overview screen should show "Reactor 1: 3 active alarms" with a color-coded indicator — not a scrolling alarm list. The alarm list belongs on a dedicated alarm display that the operator navigates to. Embedding a live alarm table in an overview screen competes with process data for attention and makes both harder to read.
Alarm banner minimum content:
| Element | Detail |
|---|---|
| Alarm count by priority | P1: 2 |
| Oldest unacknowledged alarm | Tag, description, time |
| Navigate-to alarm display | One click |
| Shelved alarm indicator | Visible count when > 0 |
Rule 5: Readable Fonts and Sizing
Typography is one of the most underspecified aspects of HMI screen design standards. Operators read process values at varying distances — from directly in front of a workstation to several meters away at a panel — under varying lighting conditions including direct sunlight, plant lighting, and emergency lighting.
Font selection rules:
- Use a single sans-serif typeface throughout. Sans-serif fonts (Arial, Verdana, Open Sans, or a platform-default equivalent) are significantly more legible at small sizes and at distance than serif fonts.
- Do not use more than two weights (regular and bold) and two sizes (body and label/header) per screen type.
- Avoid decorative, condensed, or italic variants. Process values displayed in italic are harder to read quickly.
Minimum font sizes for process displays:
| Element type | Minimum size | Recommended for distance reading |
|---|---|---|
| Primary process values (PV, SP, output) | 14 pt | 18–24 pt |
| Equipment labels and tag names | 10 pt | 12–14 pt |
| Navigation labels, button text | 10 pt | 12 pt |
| Alarm description text | 11 pt | 13 pt |
| Timestamp / secondary data | 9 pt | 11 pt |
Contrast: White text on a mid-gray background meets WCAG AA contrast requirements and is legible under most industrial lighting. Avoid gray text on gray backgrounds — a common accident when designers use low-contrast labels to "de-emphasize" secondary data. If the data is on the screen, it must be readable.
Rule 6: Group Related Information
Proximity is the most immediate signal the human visual system uses to infer relationship. Elements placed near each other are assumed to be related. Use this deliberately.
How to apply grouping in HMI screen design:
- Control loop groupings: Place the process variable (PV), setpoint (SP), output percentage, and mode (AUTO/MAN/CAS) for a PID loop within a clearly bounded region — a faceplate panel or a bordered group box. An operator should never need to scan the screen to assemble a complete picture of a loop's state.
- Equipment groupings: Place the motor start/stop button, running indicator, fault indicator, current reading, and hours-run counter for a motor in one region, not distributed across the screen.
- Separator discipline: Use whitespace and subtle separator lines to distinguish groups. Do not use heavy boxes or colored backgrounds for every group — that creates visual noise. Reserve heavy borders for safety-critical controls.
The faceplate pattern: Standardized faceplates are the most practical implementation of grouping. A faceplate is a template that displays all the information and controls for one device type (analog valve, motor, PID controller, VFD) in a consistent, fixed layout. Every valve of the same type uses the same faceplate. Operators learn the faceplate once and apply that knowledge to every instance. This is the most significant maintainability and usability benefit available in HMI screen design.
Rule 7: Show Context and Trends
A process value read in isolation tells an operator very little. A process value read in context — against its setpoint, its normal operating band, its recent trend, and its alarm limits — tells an operator everything needed to decide whether to act.
Context requirements for primary process variables:
Every displayed PV on a unit overview or detail screen should show — either inline or one click away:
- Current value and engineering units
- Setpoint (for controlled variables)
- Alarm limits (visually, not just numerically)
- Trend direction (rising, stable, falling) — even a simple arrow indicator is more useful than no trend information
Trend displays: Every detail screen for a controlled loop should include an inline trend — typically a 1-hour rolling window at minimum. Operators use trend shape (oscillating, drifting, spiking) to diagnose the process far faster than they can from a single current value. Embedding a compact trend within a faceplate, rather than requiring navigation to a separate historian screen, reduces response time significantly.
Normal operating band visualization: On analog bar graphs and meter displays, shade the normal operating band in a contrasting (but not alarm-colored) tone. Operators can see at a glance whether a value is within range without reading the number. This is especially valuable on overview screens where many values are displayed simultaneously.
Rule 8: Minimize Clicks and Screen Depth
Every extra click between an operator and a control is a decision they have to make under cognitive load. Navigation depth should be proportional to task frequency — the controls used most often should require the fewest clicks.
ISA-101 recommends a maximum four-level display hierarchy. In practice, the rule is simpler: an operator should never need more than three clicks to reach any control they use during normal operations. Emergency controls must require one click or less from any screen.
Common violations of click-depth discipline:
- Burying motor start/stop controls three levels deep because the equipment is "not often used" — ignoring that when it is needed urgently, depth is a problem.
- Requiring navigation to a separate screen to acknowledge an alarm on the device that generated it, instead of allowing acknowledgement from the alarm banner.
- Separating a valve's position indicator (on the overview screen) from its control popup (only accessible from a different detail screen) so operators cannot see the result of their action without switching screens.
Click-reduction techniques:
- Implement right-click or long-press context menus on equipment symbols that expose the most common controls without full navigation.
- Allow alarm acknowledgement from the alarm banner without navigating to the full alarm display.
- Provide a "return to previous screen" button that is consistent across all display levels — do not rely on browser-style back navigation, which may not be available or familiar in all HMI platforms.
Rule 9: Standardize Symbols and Faceplates
Symbol and faceplate standardization is the most impactful long-term investment in HMI screen design quality. Without it, every new screen built by a different engineer introduces new symbol shapes, new color conventions, and new faceplate layouts. The cumulative effect is a system where operators have to re-learn controls as they move between screens.
What to standardize:
| Element | What to define |
|---|---|
| Equipment symbols | One symbol shape per device type (pump, valve, motor, heat exchanger) — no variations |
| State colors | Running, stopped, fault, maintenance, unknown — consistent color + shape encoding |
| Faceplates | One faceplate template per device class — layout, element positions, button labels, all fixed |
| Pipe / line styles | Line weight, color, and direction conventions for different fluid types |
| Label format | Tag name position, engineering unit format, decimal places — consistent everywhere |
Symbol state encoding: Because color alone is not sufficient (color-blindness, ambient lighting), encode equipment state using both color and symbol position or shape. A pump that is running is green AND shows a rotating symbol. A pump that is stopped is gray AND shows a static symbol. A faulted pump is red AND shows an "X" or fault overlay. This dual encoding means operators can read state correctly even when color discrimination is impaired.
Faceplate standardization and ISA-101: ISA-101 explicitly recommends developing a HMI Style Guide before any screen development begins. The style guide defines all the elements above and becomes the governing document that every screen must comply with. On greenfield projects, write the style guide during FEED (Front-End Engineering Design). On brownfield projects, survey existing screens to identify de facto standards and formalize them before extending the system.
For implementation guidance on building and applying faceplates in common HMI platforms, the high performance HMI methodology provides the complete framework.
Rule 10: Test with Operators
All of the rules above are engineering principles derived from human factors research. But the only way to know whether your specific screen design works for your specific operators in your specific plant is to test it with real operators before deployment.
What operator testing reveals:
- Navigation paths that seem logical to the engineer but are unintuitive to the operator.
- Labels that are technically accurate but ambiguous in context.
- Groupings that do not match how operators mentally model the process.
- Font sizes that look fine on a design workstation but are unreadable on the control room display at operating distance.
- Missing context — data the operator always wants but the designer did not think to include.
Minimum viable operator testing process:
- Walkthroughs with experienced operators — show the screen and ask them to narrate what they see and what they would do. Do not prompt or correct. Note anything they misinterpret or miss.
- Task scenarios — define 5–10 realistic operating scenarios (normal startup, alarm response, equipment changeover, emergency shutdown). Ask operators to perform each task on the screen prototype. Measure task completion time and error rate.
- Distance and lighting checks — view the screen from the actual operator standing position in the actual control room, under actual lighting. What looked readable on a 27-inch design monitor may be too small on a 55-inch panel display at four meters.
- Iterate before deployment — change what the testing reveals, then test again. One round of testing after deployment is ten times more expensive than testing during design.
The difference between an HMI that operators trust and one they work around is almost always discovered in operator testing — not in the design review.
For the broader context of how screen design integrates with the full operator interface system, see our HMI vs SCADA comparison, which clarifies the scope of each layer and how design decisions at the HMI level interact with SCADA-level configuration.
Frequently Asked Questions
What are HMI design principles?
HMI design principles are the human-factors rules that govern how operator screens should be structured to maximize situational awareness and minimize errors. The core principles are: design screens around operator tasks (not engineering models); use consistent layout and navigation across all screens; reserve color for process state information only; make alarms immediately distinguishable from normal display elements; use readable fonts at appropriate sizes; group related information together; show context and trends alongside current values; minimize the number of clicks to reach frequently used controls; standardize symbols and faceplates across the system; and validate the design with real operators before deployment. These principles are grounded in ISA-101.01-2015 and the high-performance HMI methodology.
How should color be used on an HMI?
Color on an HMI screen should be reserved exclusively for communicating process state — not for decoration, branding, or visual variety. The standard convention, aligned with ISA-101, is: red for critical alarm / emergency state; amber or yellow for high-priority warning alarms; green for running or normal state (used sparingly); and gray tones for all background, inactive equipment, and non-alert information. The reason for this restriction is that operators build an immediate association between color and urgency. If red appears in a logo or a pipe label, operators habituate to it and their alarm response time increases. Color should also always be paired with a secondary encoding (shape, label, or position) to support operators with color vision deficiency.
How many alarms should be on a screen?
An overview screen should not display a live alarm list at all. It should show an alarm count by priority (e.g., P1: 2 | P2: 7) with a color-coded indicator, and a one-click link to the dedicated alarm display. Embedding a full alarm table in an overview screen competes with process data for attention and makes both harder to read. The dedicated alarm display should show all active alarms with sufficient detail for response (tag, description, priority, time, acknowledgement status). EEMUA Publication 191 recommends that operators face fewer than one new alarm per ten minutes in steady-state operation — if your alarm rate is higher than that, the screen design problem is upstream: the alarm system needs rationalization before the display can be optimized.
What font size for an HMI?
The minimum recommended font size for primary process values (PV, SP, output) on an HMI is 14 point, with 18–24 point recommended for values that operators read at distance. Equipment labels and tag names should be no smaller than 10 point. These minimums assume a standard monitor at a standard workstation distance. For large-format panel displays viewed from several meters, proportionally larger sizes are required — test at actual viewing distance in actual lighting conditions. Use a single sans-serif typeface throughout and avoid italic, condensed, or decorative variants, which reduce legibility at smaller sizes and under poor lighting.
Last updated: June 2026. Standards referenced: ISA-101.01-2015, EEMUA Publication 191 (3rd edition).
