UX in the control room: trust before action

A control room is not an office. Whoever sits here works under conditions that an ordinary interface does not foresee: shift work, alarms that can come at any time, plants whose state must be grasped in seconds. Anyone designing UX here designs not for comfort but for safety. An interface that looks good in the normal case but is unclear in a fault is not a good interface in the control room.

This piece describes why trust between operator and system is the precondition for action, and what UX contributes so that trust can emerge.

The control room as a high-load environment

Anyone who knows a normal work environment — quiet, interruptible, with clear tasks — underestimates the control room. Here the load is distributed differently: long phases of observation, interrupted by short phases of high density. In these short phases the operator has to recognise, decide and act — often in parallel, often with consequences that cannot be rolled back.

Under this load, “maybe” does not work. An operator who does not trust that the interface shows the state correctly starts to secure themselves. They call a colleague, look at a second display, fall back on notes. That is not a sign of diligence, but a sign that the interface does not carry the trust.

Alarm flood and screens that show everything

Two classic symptoms of a control room whose UX was not thought through are alarm flood and completeness optics. Alarm flood means: during a fault, many annunciators fire at once, without it being clear which is the originating alarm and which are merely consequential. The result is not more information, but less — the operator first has to laboriously filter out what is actually action-relevant.

Completeness optics means: a screen that shows everything because no one dared to leave anything out. The result is an interface in which the important cannot be told from the unimportant. Whoever shows everything shows nothing. In the control room, reduction is not a design question but a question of the ability to act.

What the guidelines say

Fortunately, UX in the control room does not have to start from zero. There are established guidelines that grew out of decades of practice. Three are particularly relevant.

ISA-101 (International Society of Automation) covers the design of operator interfaces in the process industries — from display hierarchy to 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 — that is, for dealing with alarm flood, prioritisation, and the question of what should be an alarm at all. Available via EEMUA: https://www.eemua.org/Products/Publications/EEMUA-191 .

These three sources are not a matter of taste. They are the result of many accidents and many observations. Anyone designing UX in a control room without knowing them repeats mistakes that others have already made and documented.

Observe before you draw

The most common mistake in control room projects is to start at the desk. Anyone who draws an interface for a control room without ever having sat in one draws for an environment they only imagine. The imagination is usually wrong.

Observation at the workplace — several shifts, different load phases, day and night — changes the result. You see which display the operator actually uses and which they skip. You see where they make notes and why. You see how experienced colleagues explain to newcomers what the interface does not provide. All of that is material for an interface that carries.

Anyone who skips this step builds an interface that is formally correct and ignored in practice. But an interface that is ignored is not an interface — it is decoration with risk.

Modernise without replacing everything

Many control rooms need modernisation, not a rebuild. Whoever replaces everything also replaces the operators’ implicit knowledge — and that is the most expensive thing a control room has. A good modernisation preserves what works and replaces only what does not carry.

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 — not everything on one level.
• Set trust points: at the points where the operator hesitates today, shape the display so the state is unambiguous — not ambiguous, not “maybe”.

Anyone who applies these levers modernises a control room without devaluing the operators’ knowledge. The goal is not a new interface, but an interface that is trusted in a fault.

What the experienced operator explains to the newcomer

A good indicator of where an interface does not carry is what experienced operators explain to newcomers. Often the induction does not start with operation but with the workarounds: “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 is a place where the interface does not provide the trust itself.

Anyone who collects these sentences gets a map of the weak points — without a survey, without evaluation, simply by listening during the shift. The material is more valuable than any requirements list, because it comes from real work and not from the imagination of it.

From this follows a clear priority for modernisation: anyone who first cleans up the places the experienced operator explains gains trust quickly. Anyone who instead modernises the interface for looks and leaves the explained places untouched loses it. The operator notices that the places they have been bypassing for years were not understood — and trust in the project drops before it has really begun.

Trust in the control room is therefore not a soft value but a concrete one: it is measured by how many of these workarounds are still necessary after a modernisation. If the number falls, the interface carries. If it stays the same, only the looks have changed.

What we learn from this

UX in the control room is not a question of looks but of operational safety. Trust between operator and system is the precondition for action — and trust does not arise through design but through an interface that shows the state reliably, even when it gets difficult.

Anyone modernising or newly designing a control room should start with observation, not with the tool. The guidelines give the frame, the observation gives the concrete case. Anyone who takes both seriously builds interfaces that carry in a fault.

If you are facing the modernisation of a control room — or the build of a new visualisation — a first conversation is worthwhile. We look at where today’s interface does not carry the trust and what it takes so the operator can act in the decisive moment.