A schematic should follow how operators actually think about the process, not how a database stores it

What it is

A layout compatible with the operator's mental model follows the segmentation, directionality, and causal relationships operators actually rely on to understand the process, rather than the structure of a database table or a software module that is convenient for engineers but unfamiliar to the people running the plant. The goal is not a more polished-looking diagram; it is a layout that supports the operator's expectations and fault reasoning — a beautifully drawn diagram that does not match the mental model in the operator's head adds cognitive load instead of removing it.

Why it happens

Years of training and field experience build stable spatial-functional chunks in an operator's head: a region on the screen maps to a process section, a direction maps to the normal flow of material, and once those chunks form they are hard to relearn. Rearrange the same elements alphabetically by tag, or by a software module boundary, and the operator has to run a mental coordinate transform every time — translating what is on screen back into the functional position they actually know — which just costs a little extra time in routine operation but becomes exactly where seconds are lost when something goes wrong and a fast response is needed. There is a less obvious flip side here too: the operator's familiar mental model can itself be out of date — a process modification changes equipment relationships, but a veteran's mental model does not update automatically, so simply deferring to the mental model in that case locks in a wrong picture. Alignment has to run both ways: the interface should match the operator, and the operator's model should be checked against the real, current plant.

Where it stops holding

Different roles are likely to hold different, each internally valid, mental models: maintenance staff organize around equipment and components, process engineers around material flow, dispatchers around throughput and batch. Trying to satisfy every role's mental model with one diagram usually cannot be done, and a diagram forced to try ends up serving no one well. When a single view cannot cover every role, provide role-differentiated views instead, but keep the same equipment object identified and positioned consistently across those views so operators do not treat it as a different piece of equipment when they switch.

Applying it

Use cognitive task analysis: have operators from different roles sketch, on paper or a whiteboard, the paths, boundaries, and causal relationships as they understand them, then reconcile those sketches item by item against the actual engineering topology to surface where the two diverge, instead of copying the engineering drawing directly. Once a prototype exists, test it with anomaly localization and impact-prediction tasks — give operators a fault signal and see how fast they can trace it to its source on the diagram and predict whether it will spread to other areas — while preserving cross-view object identity and position cues, and check whether judgment speed drops noticeably when a role switches views.

Related

• Same group: Y3.06.1 Physical connectivity in process diagrams · Y3.06.3 Hidden bypasses in simplified topology · Y3.06.4 Dynamic state overlays on stable topology
• Nearby: Y1.01 Three levels of situation awareness · Y3.11 Hierarchical displays and navigation
• Search terms: mental model alignment · ecological interface design · cognitive work analysis · abstraction hierarchy