Packing more into a display should speed up finding the answer, not just fill the space
Aliases: task-relevant information density · control-room interface
What it is
Task-relevant density is about whether the objects, relations, and states needed for one judgment fit within the operator's useful field of view, so that density buys faster localization rather than more visual polish. It is measured by how short the search path is and whether the information a decision needs is fully covered, not by how many elements sit on screen — a sparse display can still be slow to search if its relationships are scattered, while a dense one can be scanned quickly if its structure is clear.
Why it happens
Placing variables that are usually viewed together or in sequence next to each other directly cuts down on page-switching and on holding intermediate state in working memory; borders, gradients, and repeated unit labels that carry no decision value instead create extra visual features that compete with the real target for attention, spending search capacity on noise that should have gone to the actual signal. What really determines whether dense content can be read quickly is whether clear hierarchy and alignment let grouping happen pre-attentively — the visual system segments a scene into groups by boundary, alignment, and spacing before conscious search even starts. When that grouping is intact, dense content can still be scanned as a whole in one pass; when it is broken, even a modest number of elements forces a serial, item-by-item search to reconstruct the relationships, which is slower. Density and scan time are therefore not monotonically related — the variable that matters is whether the structure supports grouping. Removing decoration without fixing structure does not help; fixing structure without removing decoration only solves half the problem. Both have to happen together.
Where it stops holding
Rare but high-consequence information cannot be trimmed just because it usually looks irrelevant — being rare is exactly why the operator has no chunked memory for it, and when it is needed it must be directly visible rather than recalled from memory. What counts as relevant has to be re-checked against the operating phase: the set of variables that need to be viewed together during startup, steady state, and fault diagnosis is not the same, so "task-relevant" is not a label applied once and left alone. The opposite extreme is just as real: pushing relationships onto separate pages or levels to make an interface look cleaner reduces apparent density while forcing the operator to hold those relationships in working memory across screens instead of comparing them at a glance — density goes down while cognitive load goes up.
Applying it
Derive, from actual operating logs or task records and separately for each operating phase, which variables are typically viewed together and which are viewed in a fixed sequence, and arrange spatial relationships from that evidence rather than design intuition. Audit every piece of visual ink that plays no decision role — extra borders, decorative gradients, redundant unit labels — and remove anything whose absence would not change any judgment. How to check: use timed localization tasks, deliberately planted distractor targets, and counts of page or screen switches to verify the effect, rather than comparing before-and-after screenshots for tidiness — looking neat and being fast to use are not the same thing.