← Back to home

HMI design mistakes: 10 common errors and how to fix them

Design guide · Review checklist · ~9 min

Most poor HMI screens fail in the same ten ways: too much colour, screens that copy the P&ID, 3D graphics, text nobody can read from the panel, a missing “no feedback” state, alarms without priority, decoration that moves, navigation that is too deep, the same object drawn differently on every screen, and interlocks the operator cannot see. None of them needs new software to fix. Each has a plain cause and a plain remedy, listed below with the guide that goes deeper.

In short

The ten mistakes at a glance

Each row is explained further down. The right-hand column gives the one-line fix and the guide that covers the topic in depth.

MistakeThe fix · Go deeper
1. Too much colourGrey by default; colour for state and alarm only
Calm palette →
2. Screens that copy the P&IDOne job per screen; leave out what nobody operates
Screen hierarchy →
3. 3D, gradients, photo-realismFlat 2D shapes with solid fills
Calm palette →
4. Text too small for the distanceAt least 14 px, sized for the real viewing distance
Screen hierarchy →
5. No “no feedback” stateCompare command and feedback; show the disagreement
9 motor states →
6. Alarms without priorityPriority from rationalisation; colour plus a second cue
Alarm management →
7. Decorative animationMovement only when it carries information
Calm palette →
8. Navigation that is too deepTwo clicks to anything that matters
Screen hierarchy →
9. Same object, different looksOne symbol and one faceplate per object type
Faceplate design →
10. Interlocks the operator cannot seeList the missing permissive next to the command
Faceplate design →

Colour and graphics (mistakes 1 to 4)

These four are about what the eye has to filter out before it can read the screen. The drawing below shows the same equipment and the same values twice.

The same equipment drawn two ways Two small process screens side by side. The left one colours every item and shows extra instruments. The right one is grey, shows the pump in green because it is running and one red P1 alarm badge on a valve. 47.2 6.1 88 P1 47.2 6.1 88 Everything coloured, every instrument Grey by default, colour for state only
  1. Colour. On the left every item has its own colour, so none of them means anything. On the right the equipment is grey and colour appears twice: a green pump that is running and a red P1 badge on the valve that has the alarm.
  2. Content. The small instrument circles on the left exist on the P&ID, but nobody on shift operates them. The right keeps the equipment and the three values the operator watches.
  3. Position. Everything sits in the same place in both drawings. Calm does not mean empty: it means the eye finds the one thing that is different.

1. Too much colour

Why it fails. If a pump is blue because it is a pump and a tank is yellow because it holds product, colour carries no information. When something really goes wrong, the red has to compete with everything else on the screen, and operators learn to filter colour out.

What to do. Draw all equipment, pipes and labels in greys. Keep colour for what changes: running, no feedback, manual, fault and alarm priority, with one fixed meaning per colour across the whole project. The calm palette guide has the values.

2. Screens that copy the P&ID

Why it fails. A P&ID documents the process for engineers: every line, manual valve, drain, vent and instrument. An operator screen has to answer “what is happening, and what can I do about it?”. Put the whole drawing on a screen and nothing stands out, the text shrinks, and the only way to find an object is to know where the engineer drew it.

What to do. Give each screen one job. Show the main flow, the equipment the operator starts, stops or watches, and the few values that matter. Leave manual valves, drains and spare instruments on the P&ID, and keep the tags identical to the drawing so people can cross-reference. The screen hierarchy guide describes the levels, and HMI symbols explains why an HMI symbol is not a P&ID symbol.

3. 3D, gradients and photo-realism

Why it fails. Shading, bevels and rendered vessels add shapes the eye has to ignore before it can read the one that matters. They also spend colour on decoration, and they look dated within a few years, while flat fills do not.

What to do. Use flat, two-dimensional outlines with solid fills. If a client asks for a realistic overview, keep it out of the operator's working screens.

4. Text too small for the distance

Why it fails. Screens are drawn at a desk and used at a panel, standing, often with gloves and poor light. Text that looks fine at 60 cm is a smudge at 2 m, and a button that is easy to hit with a mouse is hard to hit with a finger.

What to do. Never go below 14 px for body text, use larger text for what the operator must read at a glance, and check against the real pixel pitch and viewing distance of the panel, not the monitor you draw on. Leave a gap between buttons that do different things. The sizing table is in the screen hierarchy guide.

State and alarms (mistakes 5 to 7)

These three are about what the screen says when something is not normal, which is the moment it matters most.

5. No “no feedback” state

Why it fails. If the screen only follows the command, a motor that was told to start but never reported running looks exactly like a running motor. The operator believes the process is moving when it is not, or the other way round.

What to do. Compare the command with the feedback and give the disagreement its own state, yellow in the calm palette. The symbol shows what the equipment is doing, not what someone asked it to do. The 9 motor states guide lists all nine states and the PLC mapping.

6. Alarms without priority

Why it fails. If every alarm looks the same, or most of them are red, the operator cannot tell which one to deal with first. A list where everything is critical carries no information, and it is often a sign that the alarms were never rationalised.

What to do. Decide the priorities first (consequence and time to respond), then map each one to a colour and a second cue, such as the number in the badge. Put the badge on the equipment and keep the equipment's own state visible underneath. Alarm management covers the priorities and the ISA-18.2 lifecycle.

7. Decorative animation

Why it fails. Spinning fans, flowing pipes and blinking labels spend the operator's attention on things that need none. If half the screen moves, a real change goes unnoticed, and blinking is the strongest signal a screen has.

What to do. Animate only when movement carries information, for example a new alarm nobody has acknowledged or a motor that is starting. Write the list of animated meanings into the style guide and keep it short. Everything else stays still. The calm palette guide covers permanent blink.

Structure and consistency (mistakes 8 to 10)

These three are about how the screens fit together, and they are the ones that grow worse as a project gets bigger.

8. Navigation that is too deep

Why it fails. If reaching the pump that is alarming takes five clicks through menus, every extra click costs time exactly when there is none to lose. A path that is hard to remember is a path nobody takes.

What to do. Aim for two clicks to anything that matters. Put the navigation in one fixed area, always show which screen you are on, avoid dead ends and do not navigate from inside popups. See the screen hierarchy guide.

9. Same object, different looks

Why it fails. If one screen draws a pump as a circle and the next as a photo, or one unit uses green for running and another uses green for available, the operator has to re-learn every screen. Different colours for the same meaning is the dangerous version.

What to do. Keep one symbol set and one faceplate per object type, built from templates rather than copies, so a change is made in one place. The faceplate design guide shows the layout, and the Symbol Builder exports one image per state from a single drawing.

10. Interlocks the operator cannot see

Why it fails. A Start button that does nothing and gives no reason is the worst kind of dead end. The operator presses it again, then goes looking for the cause in the field or in the PLC program. The reason is almost always a missing permissive that the PLC knows and the screen hides.

What to do. Show the permissives next to the command, each with its own status, and grey the button while it is blocked. The operator then sees both the state and the reason. The layout is in the faceplate design guide.

Where the mistakes come from

They are rarely carelessness. Four habits produce most of them:

The remedy for all four is the same: write a short HMI style guide before drawing, and review against it. The ISA-101 guide explains how the standard frames that, and ISA-101 vs ISA-18.2 vs ISA-5.1 shows where the alarm and instrument standards fit around it.

A 15-minute review you can run on any HMI

Run these on a simulator or a test bench, never by forcing signals on a running plant.

  1. Squint test. Step back and squint at each screen. Does the eye land on the one thing that is abnormal? If not, look at mistakes 1, 2 and 7.
  2. Count the colours. List every colour used in normal operation. Anything beyond grey and the running state is a candidate for removal.
  3. Distance test. View the screen from the real operator distance. Can you read the tags and values? Could you hit the smallest button with a gloved finger?
  4. Fault walk. Take one motor and make it stop, lose its feedback and trip its overload. Does each case look different on the screen?
  5. Alarm walk. Raise one alarm of each priority. Can you tell them apart without relying on colour alone, and is the equipment state still visible?
  6. Click count. From the overview, count the clicks to reach three random pieces of equipment. More than two is worth fixing.
  7. Consistency check. Open the same type of object in three places. Same symbol, same faceplate, same colours?
  8. Blocked-command check. Find a command that is blocked right now. Can you tell why without leaving the screen?

Fix the symbols first

One consistent symbol set removes mistakes 1, 3 and 9 at once. Draw a motor, valve or pump once in the Symbol Builder and export every state as PNG or SVG. The builder is free to use, no account needed to draw; downloads need a free account, 5 a month on Free.

Open the builder → Read the calm palette guide →

Frequently asked questions

What are the most common HMI design mistakes?

Too much colour, screens that copy the P&ID, 3D graphics, text that is too small for the viewing distance, no “no feedback” state, alarms without priority, decorative animation, navigation that is too deep, the same object drawn differently on different screens, and interlocks the operator cannot see. The table at the top of this guide gives the fix for each.

Why should an HMI be mostly grey?

Because colour is the fastest way to catch an operator’s eye, and it only works while it is rare. With grey as the default, a green running motor, a yellow no-feedback state or a red alarm stands out at once. When everything is coloured, nothing is. The calm palette guide has the values.

Should an HMI screen look like the P&ID?

No. The P&ID documents the process for engineers; the screen supports an operator who monitors and acts. Keep the process flow and the equipment the operator works with, leave out manual valves, drains and unused instruments, and let the P&ID remain the reference drawing. Tags should still match the P&ID so people can cross-reference.

Is animation bad on an HMI?

Not when it carries information. A blink for a new unacknowledged alarm, or for a motor that is starting, tells the operator something. Spinning fans, flowing pipes or blinking labels that tell nothing compete with the signals that matter, so leave them out.

How do I fix an existing HMI without redrawing everything?

Start with the changes that touch the most screens for the least work: one palette, one image per state for each symbol, and a minimum text size. Then add the missing states and the alarm priority, and simplify the navigation last. Do one unit first, agree it with the operators, and copy the result to the rest.

Keep reading