Progressive-Disclosure Failure¶

Diagnose an interface's usability breakdowns as a single mistuning between its staging schedule and the readiness of the users and tasks it actually meets, read off by whether too much is hidden or too much exposed.

Core Idea¶

Progressive-disclosure failure is the interaction-design pathology in which an interface's staging schedule — the rule that determines which information or controls are visible at each point in a user's engagement — is mistuned to the actual distribution of users and tasks it must serve. Progressive disclosure as a design principle is correct: exposing complexity gradually, reserving advanced controls for experienced users, matching what is shown to what the user can act on at each step. The failure is in the fit between that schedule and the heterogeneous population it meets: too much is hidden (a user who needs a capability cannot find it, or cannot diagnose a system state because the relevant indicator is buried), or too much is exposed too early (a user who needs only one path is overwhelmed by optionality they cannot yet interpret, makes a misconfiguration, or abandons).

The defining structural signature is a mismatch between the disclosure schedule and the user-readiness distribution. The schedule is designed once, against a modal task path and an imagined typical user; the real population spans emergency operators who need the buried control immediately, novices who need less than the schedule shows, and advanced users who need more than the schedule ever surfaces. A multi-mode infusion pump designed for routine dose-programming hides the bolus-override control three menu levels down — correctly for the modal case, fatally for the code-blue case. A benefits-application wizard hides an eligibility branch until step 7 — invisible to the user who needs it at step 2 and who has already spent the effort to get there. In each case the schedule fit the imagined scenario and broke the long-tail one, and the breakage was not detectable until the long-tail task was attempted. The remediation pattern is not to expose everything (which degrades the modal case) but to redesign the schedule against actual task-flow data, or to add escape hatches — search-as-disclosure, emergency-mode overrides, dual-mode novice/expert views — that allow the schedule to be bypassed by the tasks it cannot serve.

Structural Signature¶

Sig role-phrases:

the staged interface — an interface or layered system with hidden and exposed elements
the disclosure schedule — the explicit or implicit rule staging which elements appear at each point of engagement, designed once against a modal task and an imagined typical user
the user-readiness distribution — the heterogeneous population and the range of tasks it brings, from novices needing less to experts and emergency operators needing the buried control
the schedule-readiness gap — the mismatch between the schedule and the distribution it meets, the single parameter the whole family of complaints reads off
the sign of the gap — too-hidden (capability cannot be found) versus too-exposed (optionality overwhelms), the two signs of one mistuning that select opposite remedies
the diagnostic telemetry — task-flow data showing which disclosures are found too late, mis-found early, or end in abandonment, making the gap inspectable
the long-tail trap — a schedule locally optimal on the modal case yet fatal on the unusual one, undetectable until the long-tail task is attempted
the escape-hatch remedy — bypass mechanisms sized to the un-served tasks (emergency override, dual novice/expert views, search-as-disclosure) rather than a flat unhide that would sacrifice the modal case

What It Is Not¶

Not a verdict against progressive disclosure. Staging complexity gradually is a sound principle; the failure is the mistuning of the schedule to the population it meets, not the practice of staging. A correctly fitted disclosure schedule is exactly what the concept prescribes — the pathology is the gap between schedule and readiness, not disclosure as such.
Not just "too much exposed too early." The overwhelm-and-misconfiguration case is only one sign of the gap; the equally common too-hidden case — a needed capability that cannot be found, a buried control unreachable in an emergency — is the opposite sign of the same mistuning. Reading the failure as overload alone misses half its range and invites a fix (hide more) that worsens the other half.
Not attentional overload. The processing overload a too-exposed interface can cause is a consequence of one branch of the failure, not the failure itself. One can have a perfectly mistuned schedule (too-hidden) with no overload at all; the defect is the schedule-readiness gap, not the load on attention.
Not scaffolding. Scaffolding is a support technique whose fading is intended; progressive-disclosure failure is the mistuning of any such staging, scaffolding's included. The concept names a defect in the fit of a schedule, not the staged-support technique that, done right, is what one is trying to achieve.
Not feature creep. Feature creep is the accumulation of capabilities; this failure can occur at constant feature count, purely from how existing capabilities are staged. The problem is the visibility schedule, not the size of the feature set.
Not "expose everything." The fix for a too-hidden failure is rarely to unhide wholesale — that sacrifices the modal case the schedule was right to serve and recreates the too-exposed failure. The remedy is escape hatches sized to the un-served tasks (emergency override, dual novice/expert views, search-as-disclosure) that bypass the schedule without dismantling it.

Scope of Application¶

Progressive-disclosure failure lives across the interface-design subfields of human-computer interaction — wherever an interface stages visibility against a heterogeneous user-and-task population. Its reach is bounded by that domain; the looser "this API exposes too much surface area" or "we onboard new hires badly" uses reach toward the parent scaffolding, not this entry, and stay off the map below.

Medical-device interfaces. Infusion pumps, ventilators, and anaesthesia workstations where emergency-mode controls are buried under menus designed for routine use, while routine displays crowd in parameters the emergency operator does not need.
Public-service wizards. Benefits applications, tax filing, and immigration flows where early disclosure decisions hide eligibility branches that later turn out to apply, and users abandon mid-process because the path forward is staged out of sight.
Education platforms and tutoring systems. Mastery gates and fading scaffolds that unlock too late for fast learners (boredom) and too early for slow ones (failure) — staged visibility mistuned to the learner's readiness.
Control-room HMIs. Process plants, air-traffic, and network ops where alarm filtering and information layering bury the secondary signals an experienced operator needs to diagnose an abnormal situation, or flood normal mode with indicators that drown the abnormal signal.
Consumer-software onboarding. Feature tours and progressive reveals that expose too much too early (and get dismissed) or hide capabilities so long that users never discover them, across consumer and enterprise applications alike.

Clarity¶

Naming progressive-disclosure failure separates two corrective directions that the surface complaints constantly blur into one. "I couldn't find it" and "there's too much going on" arrive in the same bug queue as generic usability problems, yet they call for opposite fixes: a too-hidden failure wants capabilities surfaced — search, global views, escape hatches, an "I know what I want, show me everything" affordance — while a too-exposed failure wants the reverse — default suppression, mode-based visibility, disclosure contextual to the current task state. A team that does not distinguish them oscillates, fixing one user's overwhelm by hiding a control the next user then cannot find. The frame forces the designer to ask which mistuning a given report is, before reaching for a remedy that, applied in the wrong direction, simply relocates the failure.

The deeper move is treating the disclosure schedule as a first-class, measurable design parameter rather than an invisible byproduct of menu structure. Once named, the schedule can be interrogated with task-flow telemetry — which disclosures are found too late, which are mis-found early, which sequences end in abandonment — so the question shifts from the unfalsifiable "is this interface intuitive?" to the inspectable "where does the schedule diverge from the user-readiness distribution it actually meets?" That reframing also exposes the characteristic trap of the discipline: a schedule tuned to the modal task and the imagined typical user can be locally optimal and still fatal on the long tail — the buried bolus override, the late-surfacing eligibility branch — and the failure is invisible until the long-tail task is attempted. So the remedy the frame points to is rarely "expose everything" (which sacrifices the modal case the schedule was right to serve) but escape hatches that let the tasks the schedule cannot serve bypass it: emergency-mode overrides, dual novice/expert views, search-as-disclosure. The label also draws the boundary against neighbors a designer would otherwise conflate it with — it is not scaffolding (a support technique whose fading is intended) but the mistuning of any such staging, and the attentional overload it can cause is a consequence of the too-exposed branch, not the failure itself.

Manages Complexity¶

The complexity this frame tames is a wide, motley family of usability complaints that arrive in the bug queue with no common handle — "I couldn't find it," "I didn't know it was there," "there's too much going on," "I clicked the wrong thing because everything was visible," a nurse who could not reach an override in a code-blue, an applicant who abandoned a wizard at step 7. Treated as independent reports, each invites its own ad hoc menu tweak, and a team fixing them one at a time oscillates — hiding a control to calm one user's overwhelm, then fielding the next user's report that it can no longer be found. Progressive-disclosure failure collapses that sprawl onto a single design parameter, the disclosure schedule, and the analyst tracks one quantity against it: the gap between that schedule and the user-readiness distribution it actually meets. Every complaint in the family is a reading of that one gap, made inspectable with task-flow telemetry (which disclosures are found too late, which mis-found early, which sequences end in abandonment), so the unfalsifiable "is this interface intuitive?" becomes the measurable "where does the schedule diverge from the population it serves?" The branch structure is then carried by a single sign on that gap. A too-hidden divergence and a too-exposed one are not two unrelated bug classes but the two signs of one mistuning, and the sign selects the remedy directly: too-hidden wants capability surfaced (search, global views, escape hatches, an "show me everything" affordance); too-exposed wants the reverse (default suppression, mode-based visibility, task-contextual disclosure). One further branch is read off the same parameter: because a schedule can be locally optimal on the modal task and still fatal on the long tail, the remedy is rarely "expose everything" — which sacrifices the modal case the schedule was right to serve — but escape hatches that let the un-served tasks bypass the schedule (emergency-mode override, dual novice/expert views, search-as-disclosure). So a high-dimensional "why are all these different users unhappy with this interface?" reduces to one parameter, one measured gap, and the sign of that gap — from which both the diagnosis and the direction of the fix follow.

Abstract Reasoning¶

Progressive-disclosure failure licenses an interaction-design reasoning kit organized around one parameter — the disclosure schedule — and the sign of its mismatch with the population.

Diagnostic — classify a complaint by the sign of the schedule-readiness gap. The signature move reasons FROM a usability report TO which of two opposite mistunings produced it. "I couldn't find it" and "I didn't know it was there" indicate a too-hidden divergence; "there's too much going on" and "I clicked the wrong thing because everything was visible" indicate a too-exposed one. These are not two unrelated bug classes but the two signs of one parameter being off, and the move's value is that the sign selects the remedy: too-hidden wants capability surfaced (search, global views, escape hatches, a "show me everything" affordance); too-exposed wants the reverse (default suppression, mode-based visibility, task-contextual disclosure). Reasoning FROM the sign TO the direction of the fix is what keeps a team from oscillating — hiding a control to calm one user's overwhelm, then fielding the next user's report that it cannot be found.

Diagnostic — make the schedule a measurable parameter and locate its divergence. The move treats the disclosure schedule as a first-class design parameter rather than an invisible byproduct of menu structure, and interrogates it with task-flow telemetry: which disclosures are found too late, which mis-found early, which sequences end in abandonment. Reason FROM that telemetry TO where the schedule diverges from the user-readiness distribution it actually meets, converting the unfalsifiable "is this interface intuitive?" into the inspectable "where does the schedule diverge from the population it serves?" The gap is the single quantity tracked, and every complaint in the family is read as one reading of it.

Predictive — anticipate long-tail failure from a modal-tuned schedule. The characteristic trap is read off the same parameter: a schedule designed once against a modal task path and an imagined typical user can be locally optimal and still fatal on the long tail. Reason FROM "this schedule fits the modal case" TO the prediction that it will break the unusual one — the buried bolus override in the code-blue, the late-surfacing eligibility branch needed at step 2 — and that the breakage will be undetectable until the long-tail task is attempted. The move tells the analyst to probe the tails proactively rather than trust that a schedule which serves routine use is safe.

Interventionist — add escape hatches rather than exposing everything. Because exposing everything would sacrifice the modal case the schedule was right to serve, the corrective move reasons FROM the un-served tasks TO bypass mechanisms rather than a flat unhide: emergency-mode overrides that surface time-critical controls when an alarm escalates, dual novice/expert views, search-as-disclosure that lets users pull what they need. Reason FROM which tasks the schedule cannot serve TO an escape hatch sized for exactly those tasks, the predicted effect being that the long tail is accommodated while the modal case is left intact — the remedy direction (surface versus suppress) already fixed by the diagnosed sign of the gap.

Knowledge Transfer¶

Within interaction design the frame transfers as mechanism across every interface substrate, and this is where its leverage concentrates. The disclosure schedule, the schedule-vs-readiness gap, the sign-of-the-gap diagnosis (too-hidden wants surfacing; too-exposed wants suppression), the modal-tuned-but-long-tail-fatal trap, and the escape-hatch remedy all carry without translation from consumer-software onboarding to enterprise applications, to medical-device interfaces (the buried bolus override), to public-service wizards (the late-surfacing eligibility branch), to control-room HMIs (secondary indicators layered out of the abnormal-situation operator's reach), to education platforms (mastery gates that unlock too late for fast learners and too early for slow ones). These are not loose analogies but genuine co-substrate transfer: each has a literal staging schedule, a heterogeneous user-and-task population, and task-flow telemetry against which the gap is measured, so design patterns and the intervention toolkit (dual novice/expert views, search-as-disclosure, mode-based layering, emergency override) move between them as engineering. The vocabulary travels because the thing it names — staged visibility mistuned to readiness — is literally present in all of them.

Beyond interaction design the transfer is the third category rather than mechanism or bare metaphor: a more general pattern recurs, but this entry's own machinery stays home. The general pattern is scaffolding — support (or exposed capability) calibrated to a learner's or user's current state and meant to change as that state changes — and its failure mode, support mistuned to readiness, genuinely recurs wherever something is staged against a developing capacity: a tutor revealing hints, a training regimen ramping load, a regulatory phase-in. Progressive-disclosure failure is the interface-design instance of exactly that, and where the cross-domain lesson is needed it should be carried by the scaffolding prime, not by "progressive-disclosure failure" as named — because the named concept's cargo is HCI furniture (menus, modes, layering, disclosure schedules, search-as-disclosure, telemetry on found-too-late disclosures) that has no referent once there is no interface and no staged visibility. Two related primes pick up the spillover when the structure is only partial: where the consequence of too-exposed is processing overload, that is attentional_capacity, a consequence of one branch rather than the failure itself; where hidden information becomes harder to retrieve over time, that is signal_decay_and_fadeout. The honest reading, then: in any domain that lacks an explicit staging schedule — where information is simply available or not — "progressive-disclosure failure" dissolves into scaffolding (plus attentional_capacity / signal_decay for the side-effects), and to invoke it for, say, an API that "exposes too much surface area" or an organization that "onboards new hires badly" is to borrow the shape while the schedule-and-readiness mechanism stays in HCI. That boundary is drawn precisely in Structural Core vs. Domain Accent.

Examples¶

Canonical¶

The archetypal instance is a multi-mode infusion pump. Its menus are designed once around the modal task — routine, nurse-programmed continuous dosing — so the disclosure schedule places rate and volume on the top screen and buries the bolus-override and rapid-stop controls two or three levels down. That schedule is locally correct: across thousands of routine programmings it keeps the display uncluttered. But in a code-blue the operator who must reach the override immediately cannot, and the delay is the failure. The breakage stays invisible during ordinary testing, because ordinary testing exercises the modal path; only the rare, high-stakes long-tail task reveals it. The corrective is not to surface every control — which would clutter routine use — but an escape hatch: an emergency mode that promotes the time-critical controls once an alarm escalates.

Mapped back: The pump's layered menus are the staged interface, and the rate-on-top / override-buried rule is the disclosure schedule, tuned to the routine nurse rather than the code-blue operator who is part of the user-readiness distribution. The buried override is a too-hidden sign of the gap; its being locally optimal yet fatal on the emergency case is the long-tail trap; and the promote-on-escalation mode is the escape-hatch remedy rather than a flat unhide.

Applied / In Practice¶

Alarm-management practice in process-control rooms is a field deployment of the same frame on its too-exposed side. In the July 1994 explosion at the Texaco refinery in Milford Haven, Wales, the UK Health and Safety Executive found that in the roughly eleven minutes before the blast two operators had to recognize and act on around 275 alarms — a disclosure schedule surfacing far more than an abnormal-situation operator could interpret. The industry response, codified in standards such as EEMUA 191 and later ISA-18.2, was not to hide alarms wholesale but to re-tune the schedule against operator readiness: alarm prioritization, suppression of redundant and standing alarms, and state-based shelving that surfaces only the signals relevant to the current plant state.

Mapped back: The control-room HMI is the staged interface and its alarm presentation is the disclosure schedule; the 275-alarm flood is a too-exposed sign of the gap against the abnormal-situation operator in the user-readiness distribution. The standards-driven fix — prioritize and state-shelve rather than blanket-suppress — is the escape-hatch remedy, re-tuning the schedule instead of sacrificing the signals a diagnosing operator still needs.

Structural Tensions¶

T1: Too-hidden versus too-exposed (one mistuning, opposite remedies, and the oscillation between them). The frame's core insight is that "I couldn't find it" and "there's too much going on" are not two bug classes but the two signs of one parameter being off — and that unification is exactly what makes the concept hazardous to act on. The remedies point in opposite directions: too-hidden wants capability surfaced, too-exposed wants it suppressed, and because both complaints land in the same queue as generic usability problems, a team that fixes them one at a time oscillates, hiding a control to calm one user's overwhelm and burying it from the next who needs it. The single-parameter framing that lets one diagnosis cover the whole family is the same framing that means every fix risks manufacturing the opposite failure. Reading the sign correctly is not a detail but the whole game. Diagnostic: Is this report a too-hidden or a too-exposed reading of the gap — and will the proposed fix relieve that sign without pushing the schedule into the other?

T2: Modal optimality versus long-tail safety (the schedule that fits the common case is what buries the rare-critical control). A disclosure schedule is designed once against a modal task and an imagined typical user, and against that case it can be genuinely, locally optimal — the infusion pump's rate-on-top, override-buried layout keeps thousands of routine programmings uncluttered. The trap is that the same optimization is what makes the schedule fatal on the long tail: the buried bolus override is unreachable in the code-blue precisely because burying it served the routine case well. One schedule cannot be maximally tuned to both the modal and the rare-high-stakes task, so improving fit for the common case can actively worsen it for the critical one. The better a schedule serves routine use, the more confidently a designer may trust it — which is exactly when the tail failure is most silently in place. Diagnostic: Is the control a rare high-stakes task needs buried because burying it optimized the modal case — and has that tail task actually been walked?

T3: Escape hatches versus schedule integrity (the fix for too-hidden edges back toward too-exposed). The frame is careful that the remedy for a too-hidden failure is not "expose everything" — a flat unhide sacrifices the modal case the schedule was right to serve — but escape hatches sized to the un-served tasks: search-as-disclosure, emergency-mode overrides, dual novice/expert views. Yet each escape hatch is itself exposed capability. A search box, a mode toggle, an expert view are all things the modal user now sees, must ignore, or can misfire. Add enough bypasses to cover every long-tail task and the interface reaccumulates the optionality the schedule existed to suppress — the too-hidden repair drifts into a too-exposed failure by another route. The escape-hatch remedy is not free of the very gap it closes; it trades a hidden-capability cost for an added-surface cost. Diagnostic: Does this escape hatch bypass the schedule for the un-served task while staying out of the modal user's way, or is it one more control the common case must now wade through?

T4: Inspectable gap versus telemetry's blind spot (the measurement that rigorizes the frame cannot see its worst failures). Treating the disclosure schedule as a first-class, measurable parameter is the frame's deepest move: task-flow telemetry — disclosures found too late, mis-found early, sequences ending in abandonment — converts the unfalsifiable "is this intuitive?" into an inspectable gap. But telemetry records only what is exercised and instrumented. The long-tail, high-stakes task that defines the worst failures — the code-blue override, the eligibility branch a handful of applicants need at step 2 — is by construction too rare to register, and users who bounce before entering the instrumented flow leave no trace. So the very rigor that makes the schedule measurable is systematically blind to the tail the schedule is most likely to betray, and a clean dashboard can coexist with a latent fatal gap. Diagnostic: Does the telemetry cover the rare, high-stakes tasks, or only the modal traffic that would look healthy even if the tail were broken?

T5: Fixed schedule versus moving readiness (a rule set once meets users whose readiness changes). The schedule is designed once, but the user-readiness distribution it meets is not static: the same person is a novice on first use and an expert weeks later, and readiness shifts within a single session as a task unfolds. A schedule pinned at design time cannot track a readiness that moves, so it is mistuned for someone at almost every moment — too much for the newcomer, too little for the returning expert. The apparent escape, adaptive or personalized disclosure that re-stages as it infers readiness, buys fit at the cost of predictability: an interface that rearranges itself defeats the spatial memory and learnability a stable schedule provides, and surfaces or buries the wrong thing when its inference is wrong. Fitting the schedule tightly to a moving target and keeping it stable enough to learn pull against each other. Diagnostic: Is the mismatch here because a fixed schedule meets varied readiness — and would adapting the schedule fit better, or destroy the stability the user relies on?

T6: Autonomy versus reduction (an HCI failure mode or the interface instance of scaffolding). "Progressive-disclosure failure" is a named interaction-design pathology with its own machinery — disclosure schedules, modes, layering, search-as-disclosure, found-too-late telemetry — and within HCI it transfers as genuine mechanism across pumps, wizards, control-room HMIs, and onboarding, because each literally has a staging schedule met by a heterogeneous population. But beyond interface design the named concept has no referent: strip away the interface and the staged visibility, and what recurs is the parent scaffolding — support calibrated to a developing capacity and mistuned to it — with attentional_capacity picking up the too-exposed consequence and signal_decay_and_fadeout the fading of hidden information. Invoking "progressive-disclosure failure" for an over-broad API or a botched hiring onboarding borrows the shape while the schedule-and-readiness mechanism stays in HCI. Diagnostic: Resolve toward the parent (scaffolding, plus attentional_capacity / signal_decay for side-effects) when the lesson must leave interface design; toward the named failure when diagnosing an actual interface's staged visibility in situ.

Structural–Framed Character¶

Progressive-disclosure failure sits at the framed-leaning end of the spectrum — a practice-constituted design pathology, patterning closely with its HCI sibling the progress indicator and with a named software defect like primitive obsession, and far from any mechanism nature runs. On evaluative_weight it points framed, though diagnostically rather than morally: "failure" and "pathology" flag a defect to be corrected, and the concept exists to route a fix (surface versus suppress) — yet the entry is careful that the defect is a mistuning of a sound practice, a gap between schedule and readiness, not a lapse of anyone's competence, so the charge is "this staging is misfit," not "this designer erred." On human_practice_bound it is strongly framed: the failure requires a made interface that stages visibility against a heterogeneous user-and-task population, and the entry states outright that in any domain lacking an explicit staging schedule the concept "dissolves into scaffolding" — there is no progressive-disclosure failure in observer-free nature, only where a design practice has built a disclosure schedule. On institutional_origin likewise framed: disclosure schedules, modes, layering, search-as-disclosure, and found-too-late telemetry are furniture of interaction design (EEMUA 191, ISA-18.2, HIG-style conventions), artifacts of that discipline.

The remaining two criteria confirm the placement. On vocab_travels it is pinned: disclosure schedule, staged visibility, escape hatch, mode-based layering, novice/expert view, task-flow telemetry are irreducibly interface-design vocabulary that loses its referents off the substrate. On import_vs_recognize the transfer is bimodal as Knowledge Transfer argues — within interaction design (pumps, wizards, control-room HMIs, education platforms, onboarding) it moves as genuine co-substrate mechanism because each literally has a staging schedule met by a heterogeneous population, while beyond it the reach is carried by the parent, so an over-broad API or a botched hiring onboarding is a recognition of scaffolding, not an import of "progressive-disclosure failure."

The portable structural skeleton is scaffolding — support or exposed capability calibrated to a developing capacity and meant to change as that capacity changes, whose failure mode is support mistuned to readiness (with attentional_capacity picking up the too-exposed consequence and signal_decay_and_fadeout the fading of hidden information, both side-effect primes rather than the core). That scaffolding skeleton genuinely recurs wherever something is staged against a developing capacity — a tutor's fading hints, a training ramp, a regulatory phase-in — which is what gives the entry its structural core; but it is precisely what progressive-disclosure failure instantiates from that parent, not what makes "progressive-disclosure failure" itself travel: the cross-domain reach belongs to scaffolding, while the disclosure-schedule apparatus, the too-hidden/too-exposed sign diagnosis, and the escape-hatch remedies stay home in HCI. Its character: a practice-constituted, diagnostically-normative interface pathology whose portable core is the prime scaffolding it instantiates, framed-leaning because it exists only where a design practice stages visibility and everything distinctive about it is interaction-design furniture.

Structural Core vs. Domain Accent¶

This section decides why progressive-disclosure failure is a domain-specific abstraction and not a prime, and carries the case for its domain-specificity.

What is skeletal (could lift toward a cross-domain prime). Strip the interface and a thin relational structure survives: something is staged against a developing or heterogeneous capacity, and the staging is mistuned to that capacity — offering too little where more is needed or too much where less can be handled. The portable pieces are abstract — a support (or exposed capability) that is calibrated to a current state and meant to change as that state changes, a population whose readiness varies, and a gap between the staging rule and the readiness it meets, with two signs (too-little / too-much). That skeleton is genuinely substrate-portable, which is why it is the parent scaffolding — support calibrated to a developing capacity, whose failure mode is support mistuned to readiness. It recurs in a tutor's fading hints, a training ramp, a regulatory phase-in. But this is the core progressive-disclosure failure shares, not what makes it progressive-disclosure failure.

What is domain-bound. What makes the concept this failure in particular is interaction-design furniture that does not survive extraction. Its content is keyed to a made interface that stages visibility: the disclosure schedule as a first-class parameter, the too-hidden / too-exposed sign diagnosis that selects opposite remedies, modes and layering, search-as-disclosure, dual novice/expert views, emergency-mode overrides, and the task-flow telemetry (disclosures found too late, mis-found early, sequences ending in abandonment) that makes the gap inspectable. Its cases — the infusion pump's buried bolus override in a code-blue, the Milford Haven alarm flood re-tuned under EEMUA 191 and ISA-18.2 — are HCI practice. The decisive test, which the entry states outright: in any domain lacking an explicit staging schedule — where information is simply available or not — the concept dissolves into scaffolding (with attentional_capacity and signal_decay_and_fadeout for the side-effects); there is no progressive-disclosure failure in observer-free nature, only where a design practice has built a disclosure schedule.

Why this does not clear the prime bar. A prime's vocabulary travels and its transfer is recognition of the same mechanism, not analogy. Progressive-disclosure failure's transfer is bimodal. Within interaction design it moves intact as genuine co-substrate mechanism — pumps, public-service wizards, control-room HMIs, education platforms, and onboarding each literally have a staging schedule met by a heterogeneous user-and-task population and telemetry against which the gap is measured, so the sign diagnosis and the escape-hatch toolkit port as engineering. Beyond interface design the named concept has no referent: strip the interface and the staged visibility and the machinery (schedules, modes, layering, search-as-disclosure) is gone. And when the bare structural lesson is needed cross-domain — staging mistuned to readiness, in either sign — it is already carried, in more general form, by the parent scaffolding (with attentional_capacity for the too-exposed overload and signal_decay_and_fadeout for fading hidden information). So invoking "progressive-disclosure failure" for an over-broad API or a botched hiring onboarding borrows the shape while the schedule-and-readiness mechanism stays in HCI. The cross-domain reach belongs to scaffolding; "progressive-disclosure failure," as named, carries the disclosure-schedule, sign-diagnosis, escape-hatch baggage that should stay home in interaction design.

Relationships to Other Abstractions¶

Current abstraction Progressive-Disclosure Failure Domain-specific

Parents (1) — more general patterns this builds on

Progressive-Disclosure Failure presupposes Progressive Disclosure Prime

Progressive-Disclosure Failure presupposes an attempted Progressive Disclosure schedule whose layer exposure is mistuned to users and tasks.

Hierarchy path (1) — routes to 1 parentless root

Progressive-Disclosure Failure → Progressive Disclosure → Layering

Not to Be Confused With¶

Progressive disclosure (the principle). The sound design practice of staging complexity gradually — reserving advanced controls for later, matching what is shown to what the user can act on. This entry names its failure: the mistuning of that schedule to the population it meets. Confusing the two invites the wrong conclusion that disclosure itself is the problem. Tell: is the schedule correctly fitted to readiness (progressive disclosure, working) or mismatched, hiding too much or exposing too much (the failure)?
Scaffolding (parent prime). The substrate-neutral pattern of support calibrated to a developing capacity and meant to change as that capacity changes, whose failure mode is support mistuned to readiness. Progressive-disclosure failure is its interface-design instance, keyed to staged visibility; scaffolding is what recurs in tutoring, training ramps, and regulatory phase-ins. Tell: the parent carries the cross-domain reach; progressive-disclosure failure is the HCI special case with a disclosure schedule, treated more fully in the sections above.
Attentional capacity / information overload. The processing-limit prime — a user swamped by more than working memory can handle. It is the consequence of the too-exposed branch, not the failure itself: a perfectly mistuned too-hidden schedule produces no overload at all. Reading the failure as overload alone misses half its range (the too-hidden sign) and prescribes "hide more," which worsens it. Tell: is the defect the load on attention (attentional capacity), or the schedule-readiness gap that may be too-hidden or too-exposed (the failure)?
Signal decay / fadeout. The prime for information becoming harder to retrieve over time. It picks up a side-effect when hidden capabilities grow un-findable through disuse, but it names temporal fading, not a mistuned staging rule met by a heterogeneous population. Tell: is the problem that once-known information faded with time (signal decay), or that a schedule buries or floods capability relative to user readiness at a point in engagement (the failure)?
Feature creep. The accumulation of ever more capabilities in a product. Progressive-disclosure failure can occur at constant feature count, purely from how existing capabilities are staged — the defect is the visibility schedule, not the size of the feature set. Tell: has the capability set grown (feature creep), or is a fixed set simply staged so that users cannot find or are overwhelmed by it (the failure)?
Over-broad API surface / bad hiring onboarding (analogy). Contrast cases where the concept is loosely invoked: an API "exposing too much surface area," an organization that "onboards new hires badly." Lacking an explicit interface staging visibility, these borrow the shape while the schedule-and-readiness mechanism stays in HCI — they are recognitions of scaffolding, not this failure. Tell: is there a designed interface with a disclosure schedule and task-flow telemetry (the failure), or just information that is available-or-not with no staging rule (scaffolding by analogy)?

Neighborhood in Abstraction Space¶

Progressive-Disclosure Failure sits in a crowded region of the domain-specific corpus (37^th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Interface Legibility & Navigability (12 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12