Navigation: getting to the right screen in one action
An operator diagnosing an upset should not be searching a menu. Most navigation schemes are designed by people who already know where everything is.
Navigation is the part of display design that is evaluated least and used most. Every operator action begins with getting to the right screen, and a scheme that takes three steps instead of one imposes that cost on every task, permanently.
It is also the element most obviously designed by people with complete knowledge of the display set. An engineer who built the graphics knows which screen a given pump lives on. An operator covering a second console at three in the morning does not.
Three routes, all of which should exist
Hierarchical navigation moves up and down the display structure: from an overview to a unit, from a unit to a piece of equipment. It should be available from a consistent position on every screen and should never require more than one action to move one level.
Remote-work controls may need to distinguish genuine activity from artificial presence signals. A related reference is available at https://www.monitask.com/mouse-jiggler-detection-software/.
Additional industry context is available in the ISA-101 HMI standards.
Direct navigation goes from an object to its detail. Selecting a pump on a unit display should open the pump's detail display. This is the most frequently used route and the one most often missing, leaving operators to navigate hierarchically to reach something they can already see.
Alarm-driven navigation goes from an alarm to the relevant display, with the alarmed item indicated. Under upset conditions this is the route that matters, and it should be a single action from the alarm summary.
If reaching the relevant graphic from an alarm requires the operator to know which display it lives on, the navigation has failed at the moment it matters most.
Consistency of position
Navigation controls should be in the same place on every display, in the same order, with the same labels. This sounds trivial and is routinely violated when displays are built by different people or inherited from different projects.
The cost of inconsistency is small per instance and large in aggregate: every screen change requires a moment of reorientation, and under pressure those moments are where errors happen.
Favourites and recall
Operators develop working sets: the six or eight displays they use during a particular operation. A mechanism for reaching those quickly — assignable buttons, a recent-displays list, a per-operator favourites set — removes a large share of routine navigation.
The recent-displays list is particularly valuable during an upset, when the operator is moving repeatedly between the same two or three screens and would otherwise navigate the full route each time.
Multiple screens change the problem
A console with four monitors is not a console with one monitor four times. It permits a spatial arrangement — alarm summary permanently on one, overview on another, working display on a third, trends on the fourth — that removes navigation entirely for the most common combinations.
Making that arrangement the default, and designing displays with a known screen assignment in mind, is more effective than any navigation improvement. It is also frequently undermined by operators using all four screens for whatever they were last looking at, which is a training and convention question rather than a technical one.
Search as a fallback
A tag search that opens the display containing a given tag is a useful backstop, particularly for infrequent tasks and for staff covering unfamiliar areas.
It should not be the primary route, because it requires the operator to know the tag. Searching by equipment description is considerably more useful and is rarely implemented.
Measuring navigation cost
The way to evaluate a navigation scheme is to count actions for realistic tasks. Take ten common operator activities and count the steps from the display where the operator would normally be sitting.
Anything above two or three steps for a routine task is a candidate for a direct route. Anything above one step for an alarm response is a defect.
This exercise takes an afternoon and produces a concrete list of navigation shortcuts to add, which is a much cheaper improvement than redesigning displays.
Navigation during degraded operation
Where a console screen fails, or an operator has to work from a different position, the navigation scheme is the thing that determines whether they can function.
Worth testing explicitly: can an operator reach everything they need from a single screen, if the other three are unavailable? The answer is frequently no, because the design assumed a four-screen layout without providing a fallback.
Naming displays so they can be found
Display names are frequently derived from drawing numbers or internal identifiers, which makes any navigation list unreadable to anyone who does not know the numbering.
Names in process language — the equipment or area the display covers — allow a menu to be scanned. Where a numbering scheme is required for other reasons, the number can accompany the name rather than replacing it.
Breadcrumbs and knowing where you are
In a deep hierarchy an operator can lose track of their position, particularly after navigating directly to a detail display from an alarm.
A consistent indication of the current display's position in the hierarchy — the area, the unit, the equipment — occupies a small strip and removes a category of disorientation. It also gives the route back up without requiring the operator to work out where up is.
Navigation and the alarm workflow
The complete alarm workflow is: notice the alarm, read it, reach the relevant display, assess, act, return. Navigation appears twice in that sequence and both should be single actions.
The return step is the one usually neglected. An operator who navigated from the alarm summary to a detail display needs to get back to the summary immediately, and a back function or a permanently visible summary provides it.
Navigation under alarm load
Navigation designs are evaluated in normal conditions and used most heavily during floods, when the operator is moving repeatedly between the alarm summary and several process displays.
The pattern that emerges under load is rapid alternation between two screens, and a design that supports it — a direct toggle, or a permanently visible summary — removes a large amount of repeated work at the moment it is most expensive.
Observing an operator during a simulated flood, and counting navigation actions, identifies these opportunities more reliably than any review of the display structure.
Consistency with other systems on the console
Operators typically use several systems: the control system, an alarm management package, a historian client, a maintenance system, a permit system.
Each has its own navigation conventions, and switching between them imposes a cost the console designer usually does not consider.
Where the systems cannot be made consistent, the practical mitigations are consistent screen assignment so that each application appears in a known place, and single sign-on so that switching does not require re-authentication.