UX in the control room: trust before action

A control room works under conditions an office never sees: shift work, alarms that can come at any moment, plants whose state has to be grasped in seconds. An ordinary interface is not built for that. UX in a control room is about safety first and comfort second. An interface that looks good in normal operation and turns unclear during a fault is of no use here.

This piece looks at why an operator has to trust the system before acting on it, and what UX contributes to that trust.

The control room as a high-load environment

If you only know quiet work with clear tasks and room for interruptions, you will underestimate the control room. The load is distributed differently there: long phases of observation, broken by short, dense phases. In those moments the operator has to recognise, decide and act, often all at once and often with consequences that cannot be rolled back.

Under that load, “maybe” is no help. An operator who does not trust the interface to show the state correctly starts hedging: they call a colleague, check a second display, or go back to their notes. It looks like diligence, but mostly it shows that the interface has not earned their trust.

Alarm flood and screens that show everything

Two typical symptoms of a control room designed without UX in mind are alarm flood and completeness optics. In an alarm flood, many annunciators fire at once during a fault, and it is unclear which one is the originating alarm and which are only consequences. The operator ends up with less usable information, because they first have to filter out what actually calls for action.

Completeness optics means a screen shows everything because no one dared to leave anything out. On an interface like that, the important can no longer be told apart from the unimportant. In a control room, reduction decides whether the operator can still act.

What the guidelines say

UX in the control room does not have to start from zero. There are established guidelines built on decades of practice, and three of them are particularly relevant.

ISA-101 (International Society of Automation) covers the design of operator interfaces in the process industries, from display hierarchy and alarm handling to legibility under a control room’s lighting conditions. The guideline is available directly from ISA: https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa101 .

VDI/VDE 3699 (Association of German Engineers) defines how process control systems and visualisations are to be designed and is the established reference in the German-speaking world. The guideline is available via VDI: https://www.vdi.de/richtlinien/details/vdivde-3699 .

EEMUA 191 (Engineering Equipment and Materials Users Association) is the international standard for alarm management. It deals with alarm flood and prioritisation, and with the question of what should count as an alarm at all. Available via EEMUA: https://www.eemua.org/Products/Publications/EEMUA-191 .

All three sources grew out of many accidents and observations. Designing control room UX without knowing them means repeating mistakes that others have already made and documented.

Observe before you draw

The most common mistake in control room projects is starting at the desk. If you design an interface for a control room without ever having sat in one, you are designing for an environment you only imagine, and that picture is usually wrong.

Observing the workplace across several shifts, different load phases, day and night, changes the result. You see which display the operator actually uses and which they skip, where they take notes and why, and how experienced colleagues explain to newcomers what the interface does not tell them. That material is what an interface that holds up in operation is built from.

Skip this step and you get an interface that is formally correct and ignored in practice. At that point it adds risk instead of reducing it.

Modernise without replacing everything

Many control rooms need modernisation, not a rebuild. Replacing everything also throws away the operators’ implicit knowledge, which is the most expensive thing a control room has. A good modernisation keeps what works and replaces only what does not hold up.

Three levers have proven useful without rethinking the plant from the ground up.

• Clean up the alarm structure: separate originating alarms from consequential ones, check prioritisation, take non-genuine alarms out of the alarm list.
• Lay out the display hierarchy clearly: one overview that shows the state, and detail views called up only when needed, instead of everything on one level.
• Set trust points: wherever the operator hesitates today, shape the display so the state is unambiguous and no “maybe” is left.

With these levers you can modernise a control room without devaluing what the operators know. The aim is an interface people trust during a fault, whether or not it looks new.

What the experienced operator explains to the newcomer

What experienced operators explain to newcomers is a good guide to where an interface falls short. The induction often starts with the workarounds rather than with operation: “On this screen you have to watch out, the value at the bottom is not current.” “If more than three alarms come up here, ignore the lower two.” “You see the real state better in the trend view, not in the overview.” Each of these sentences marks a place where the interface does not earn trust on its own.

Collect these sentences and you get a map of the weak points, with no survey or analysis, just by listening during the shift. That material is worth more than any requirements list, because it comes from real work rather than from an idea of it.

It also sets the order for modernisation. Clean up the places the experienced operator explains first, and you gain trust quickly. Modernise the interface for looks and leave those places as they are, and you lose it. The operator notices that nobody understood the spots they have been working around for years, and their trust in the project drops before it has really begun.

That makes trust in the control room something you can measure: by how many of these workarounds are still needed after a modernisation. If the number falls, the interface holds up. If it stays the same, only the looks have changed.

What we learn from this

UX in the control room is a matter of operational safety. The operator has to trust the system before acting, and that trust comes from an interface that shows the state reliably, even when things get difficult. Good looks alone do not get you there.

If you are modernising or redesigning a control room, start with observation and pick up the tools afterwards. The guidelines set the frame and observation supplies the concrete case. Taking both seriously gives you interfaces that hold up during a fault.

If you are planning to modernise a control room or build a new visualisation, a first conversation is worthwhile. We look at where today’s interface loses the operator’s trust and what it takes for them to act at the decisive moment.