Under pressure, actively strip extraneous load from the interface and give the freed capacity to task load

What it is

Since time pressure consumes part of a shared processing-resource pool and that consumption crowds out capacity the task itself needs, a directly actionable design response follows: in scenarios known to produce high pressure, actively minimize the extraneous load the interface itself creates — the burden from presentation, operational steps, and unnecessary information, as distinct from the load the task inherently requires — so the resource budget tightened by pressure goes as much as possible to the processing the task actually needs, rather than continuing to be spent on the interface's own presentation cost.

Why it happens

Pressure is already consuming part of the shared resource pool; if the interface maintains its usual amount of extraneous load at the same time — requiring users to organize information themselves, compare across screens, hold multiple steps in mind — task load and extraneous load are now competing with pressure for the same already-shrunken capacity, and the three compounding together most readily trigger strategy degradation or an outright performance collapse. Extraneous load is the one component among the three load types that design can eliminate unilaterally, without changing the task's own difficulty. Cutting it first under pressure is a near-zero-cost lever that indirectly frees up more capacity for task load — equivalent to pulling the entire pressure–load curve's optimal point back toward safer territory.

Where it stops holding

This strategy assumes high-pressure scenarios can be identified in advance — if pressure arrives suddenly and unpredictably, the interface won't have time to make a targeted adjustment, and the fallback has to be a baseline design that keeps extraneous load low at all times, rather than relying on adapting on the fly. Cutting extraneous load also must not spill over into task load: simplifying the interface to the point where users lose necessary context, or auto-hiding a key step that the user was supposed to actively verify, cuts away part of the task load along with it — that looks like a load reduction but actually sacrifices rigor the task genuinely required, which is not the outcome this recommendation is after.

Applying it

• Identify in advance which scenarios in the product carry a clear deadline or high consequences (payment confirmation, incident response, timed assessments), and design a separate, simplified presentation just for those scenarios, stripping out non-essential information, decorative elements, and redundant confirmation steps first.
• Consolidate key information that would otherwise be spread across multiple screens or clicks into a single view for high-pressure scenarios, reducing the burden of cross-screen comparison and holding things in short-term memory.
• Distinguish between "verification the task itself requires" and "extra steps the interface imposes," and cut only the latter: confirmation for an irreversible action should not be simplified away even under high pressure.
• How to verify it: under simulated high-pressure conditions, compare task completion rate and error rate before and after simplification, while also collecting users' subjective reports on whether they felt they had enough information at the time. If completion rate rises without a drop in reported sufficiency of information, that confirms what was cut was extraneous load, not task load.

Related

• Same group: A9.15.1 moderate time pressure raises alertness and engagement, but excessive pressure crowds out processing capacity · A9.15.2 pressure and load interact in an inverted-U, and the optimal point shifts with task difficulty · A9.15.3 high-load tasks are more prone to strategy degradation under time pressure
• Nearby: A9.01 The three types of load
• Search terms: extraneous load reduction · load shedding · high-stakes interface design