Turning a knob clockwise should raise the value, matching what the operator already expects
Aliases: control-response compatibility · control-room interface
What it is
Control–response compatibility requires that the direction of a manipulation match the operator's existing expectation for how the controlled value or display pointer should move — clockwise to increase, push up for a rise. That expectation is not a trained rule but a direction-of-motion stereotype (also called a population stereotype): most people in a given culture and sector share the same default answer for "which way turns which way." Warrick's principle goes further: a moving display element should move in the same direction as the control that drives it, not merely agree on the direction of the value.
Why it happens
Compatible mapping holds up under load because it needs no translation step: seeing "increase" and turning clockwise is close to a direct stimulus–response link that barely touches working memory. Incompatible mapping requires storing a rule first — "this valve is reversed" — and then executing it. That rule occupies exactly the working-memory capacity that time pressure, gloved operation, or a gaze diverted elsewhere consumes first. When the rule drops, the operator does not err randomly; they revert precisely to the stereotype that was never actually extinguished by training. Counterintuitively, the more urgent and the more skilled the operator, the more likely a textbook direction error becomes on an incompatible control, because load favors the default response over the memorized exception. This is also why training or procedural reminders rarely fix incompatible mapping on their own: training changes whether someone can state the correct direction, not which direction fires under load.
Where it stops holding
A single control sometimes changes several variables at once, so there is no unique variable to align "direction" against. Viewpoint also flips left and right: standing in front of equipment versus behind it reverses the visual direction of the same physical motion. A more consequential boundary is that established sector convention can override the generic stereotype — some valve, rail, and piping conventions run counter-clockwise to open, opposite the generic clockwise-to-increase intuition, yet operators trained in that sector have already internalized the convention as their own default. Redesigning toward the generic stereotype there creates new errors rather than removing old ones. Where no single natural direction exists, consistency, clear labeling, and a preview of the result are more reliable than forcing an invented "natural" direction.
Applying it
List the primary and secondary result direction for every control action, align it to the actual field viewpoint and any confirmed sector convention, and do not override an internalized industry default with a design team's generic intuition. When viewpoint changes (front/rear, local/remote), preserve semantics rather than mechanically swapping left and right. Also check what the display shows under power loss, actuator failure, and reversed viewpoint — most direction mappings are only ever validated under normal power and a front-facing view, and a frozen pointer position in a failure state can easily be misread as the opposite condition. How to check: build a time-pressure-plus-interference task (concurrent verbal counting or a second response channel) and record how often the operator's first-choice direction diverges from correct, specifically comparing the reversal rate on incompatible controls between calm and loaded conditions.