Counting the elements on a screen tells you little about how much thinking it demands

What it is

Cognitive load depends on how many judgments a task requires, how much information must be held in mind, and how effortful retrieval is — the number of countable elements on a screen is only one possible contributor, and often not the dominant one. A dashboard with a dozen independent, instantly readable small cards can demand almost no extra thought, while a form with only three or four fields can carry far more load if those fields depend on each other in complicated ways (filling in A changes what B can be, and C has to be checked to decide what to enter). The number you can count and the mental resources a user actually has to spend are two quantities that don't necessarily move together.

Why it happens

The size of cognitive load is set by the processing steps a task requires: whether things must be compared, whether intermediate results must be held in mind, whether information must be retrieved from memory or elsewhere on the interface to make a judgment. Element count only tracks load when these processing steps happen to scale with element count — checking off items on a list, say, really does take more glances as the list grows. But once a task calls for integrated judgment rather than item-by-item checking, load is set by how many variables and branching conditions that judgment involves, and has little to do with how many visual elements are shown: three mutually constraining fields can be more taxing than fifteen unrelated independent ones, because the fifteen judgments are independent of each other while the three require going back and forth between them.

Studying it

Judging load can't rely on counting elements or eyeballing how "simple" something looks; it needs methods that reflect actual processing investment. Having users perform an unrelated secondary task alongside the primary one (the dual-task method) works because higher primary-task load produces a larger drop in secondary-task performance. A direct cognitive task analysis of the task itself is another route — breaking down how many judgment steps completing it actually requires and how many pieces of information each step must reference, and using step count and information dependencies as the operational measure of load instead of counting visual elements.

Common independent variables: the number of judgment steps and information dependencies a task requires, the number of elements displayed on the interface (as a control variable). Common dependent variables: the magnitude of secondary-task performance decline, primary-task completion time and error rate.

This approach is often used in HCI to correct the reviewing habit of equating "looks complex" with "hard to use" and "looks simple" with "easy to use," replacing a visual impression with an actual measurement.

Methodological note: element count is still worth recording, but only as one of many inputs to load — it should not be used alone as a proxy to draw conclusions from. Conflating the two lets "we removed a few elements" get mistaken for evidence that load was reduced.

Where it stops holding

• When a task genuinely consists of independent item-by-item checking (a checklist-style review), element count correlates fairly well with load, and counting elements is an acceptable rough estimate in that case.
• Once a task involves comparison, dependency, or reasoning across elements, element count and load clearly decouple, and counting can no longer be used to estimate load.
• This entry addresses the failure of the "quantity" dimension specifically; it does not cover how visual presentation (grouping, hierarchy, consistency) affects load — those are other dimensions of complexity that need to be handled separately.

Applying it

• When reviewing an interface, don't accept "this version has fewer elements, so it's lower load" as a passing criterion. Do a task analysis first to confirm the change actually reduced the judgment steps a task requires, rather than just reducing the number of visible elements.
• For tasks involving multiple interdependent fields (forms, configuration options), prioritize reducing the number of dependencies between fields, or making those dependencies explicit, rather than simply cutting the number of fields.
• Verification: compare actual load before and after a change using secondary-task performance or task completion time, not just the increase or decrease in element count. If elements decreased but secondary-task performance didn't improve — or got worse — that "simplification" didn't genuinely reduce load.

Related

• Same group: A9.05.2 A dense but well-structured interface can beat a sparse but chaotic one · A9.05.3 Hiding structure behind a simplified appearance raises load · A9.05.4 Objective structural complexity and subjective perceived complexity don't always track together, and can vary independently · A9.05.5 Visual complexity metrics correlate weakly with actual cognitive load · A9.05.6 Inconsistency across screens compounds complexity beyond the simple sum of each screen's own complexity · A9.05.7 A more aesthetically pleasing interface is often misjudged as easier to use, masking real differences in load
• Nearby: A2.12 Minimalism and the tendency toward reduction · A9.02 Measuring cognitive load
• Search terms: cognitive load · cognitive task analysis · dual-task method · element count