Skip to content

Progressive Disclosure of Risky Options

Interface disclosure control — instantiates Misuse-Resistant Affordance Design

Keeps risky options out of the ordinary path and reveals them only to users who deliberately seek them out.

Progressive disclosure of risky options shapes visibility: the dangerous controls exist and remain fully usable, but they are kept off the ordinary path — tucked behind an "advanced" panel, a hidden menu, a deliberate reveal — so a casual user never stumbles into them, while a user who genuinely wants them can find them by seeking. Its defining idea is that it separates the ordinary action space from the expert one by layering, not by locking: it changes what is encountered by default, not what is permitted. The novice is protected by never meeting the risky option; the expert is unhindered because the option is one deliberate step away, not forbidden.

Example

A mobile operating system contains settings that ordinary users should almost never touch — options that let apps be installed from anywhere, that expose low-level debugging, that turn off protections. Exposing these on the main settings screen would invite millions of casual users to flip something they don't understand at the prompting of a scam "tech support" call. Instead the OS uses progressive disclosure: the developer options[1] are simply not present in the ordinary settings list. A user who genuinely needs them must go to the build-number entry and tap it seven times to reveal a new menu.

Setup to outcome: a typical user scrolls settings for a year and never encounters the risky controls — they are not in the path they walk. A developer who needs USB debugging performs the deliberate seven-tap ritual, the advanced menu appears, and every option is fully available. The dangerous controls were never removed or permission-gated; they were simply kept out of the ordinary field of view so that reaching them takes intent, and that intent is the filter.

How it works

  • Sort options by who legitimately needs them. Separate the controls of ordinary use from those only experts or special cases require — the split is the design's core judgment.
  • Default the ordinary, defer the risky. The common path shows only what ordinary use needs; risky controls live behind a deliberate reveal, one intentional step off the main flow.
  • Make the reveal a signal of intent, not a lock. The gesture that surfaces the advanced layer (a menu, a toggle, a ritual tap) filters by deliberateness, not by authority — anyone willing to seek can find it.
  • Keep the revealed layer fully capable. Once disclosed, the expert options work without further nagging; disclosure delays encounter, it does not add ongoing friction to use.

Tuning parameters

  • Disclosure depth — how many deliberate steps stand between the ordinary path and the risky option. Deeper burial protects more novices but slows the experts who need it repeatedly.
  • Reveal obviousness — whether the path to advanced options is discoverable-if-sought or genuinely obscure. Too obscure and legitimate experts can't find it; too obvious and it stops filtering casual users.
  • Layer boundary — where the line between "ordinary" and "advanced" is drawn. Misplace it and either novices meet danger or experts are constantly digging.
  • Persistence of reveal — whether the advanced layer stays open once found or must be re-revealed each session. Sticky is convenient; resetting re-protects shared devices.
  • Warning at the boundary — whether crossing into the advanced layer carries an explanatory caution.

When it helps, and when it misleads

Its strength is that it serves novices and experts with one interface: the majority are protected by never encountering the risky option, and the minority who need it lose only a moment of seeking, not the capability itself. It is the gentlest way to keep a powerful, flexible system from ambushing its casual users — friction of encounter, not of use.

Its failure mode is that deliberate obscurity is a weak barrier against the motivated wrong actor: a scammer coaching a victim over the phone, or a malware install script, can walk a user straight to the hidden menu, because the reveal filters for deliberateness and a manipulated user is being made deliberate on someone else's behalf. The classic misuse is hiding an option to reduce support tickets or complaints rather than risk — burying a setting users legitimately need so they can't find it, which manufactures a desire path of frustrated workarounds. The guarding discipline is to reserve disclosure for options whose danger is stumbling into them unaware, and to pair it with a stronger mechanism (confirmation, permission scope) wherever a socially-engineered or coerced reveal is a real threat.

How it implements the components

  • asymmetric_affordance_map — it builds a visibility asymmetry: ordinary options sit on the default path while risky ones are reachable only by a deliberate reveal, so danger is harder to encounter than routine use.
  • legitimate_use_model — the layering rests on an explicit account of which options ordinary users need versus which only experts or special cases do; that model draws the line between the surfaced and the deferred.
  • legitimate_path_preservation_criterion — the risky options remain fully available and unhindered once revealed, so the expert's legitimate path is preserved at the cost of only a deliberate step.

It does not set the shipped value of any option or its default_state_and_permission_posture — that is Safe Default Setting, which biases what value a control holds rather than whether the control is on the ordinary path; disclosure hides the control, a safe default pre-sets it.

Editorial Notes

Form Classification

Form family: Interface, Display & Cue

Rationale: Progressive Disclosure of Risky Options operates as a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use because it keeps risky options out of the ordinary path and reveals them only to users who deliberately seek them out.

Independent corroboration: The frozen evidence defines Progressive Disclosure of Risky Options as 'Keeps risky options out of the ordinary path and reveals them only to users who deliberately seek them out', so its operative form is Interface, Display & Cue.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution

Primary origin: Human-Computer Interaction

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: Keeping hazardous controls out of the default path while retaining deliberate access extends canonical HCI progressive disclosure.

Related originating lineages:

  • Computer Science & Software Engineering — Capability and privilege separation contributes gating of advanced operations.
  • Security Studies & Intelligence Analysis — The security_intelligence tradition materially shaped Progressive Disclosure of Risky Options through its own practice of access control, threat containment, privileged operation, and verifiable trust.
  • Ethics of Technology & AI Governance — The tech_ethics_ai_governance tradition materially shaped Progressive Disclosure of Risky Options through its own practice of technology-specific privacy, accountability, and misuse governance.

Review resolution: Both blind reviewers agree that human computer interaction is the primary origin. Explicit reconciliation resolves reported ambiguity, alternate origin disagreement, domain reach disagreement. Formative alternate lineages are retained as security_intelligence, tech_ethics_ai_governance, computer_science; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.

Attribution caveat: The exact encyclopedia label appears to synthesize established practices; the primary domain identifies the strongest formative lineage, while the alternates record material ingredients rather than downstream uses.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.

Review outcome: Reconciled after independent review; medium confidence.

References

[1] Google Inc. Android 7.0 Compatibility Definition. Android Open Source Project, updated April 18, 2017. Requires Developer Options to be hidden by default and revealed only through a deliberate enabling action. registry