Discoverability Failure¶

Diagnose why a working feature goes unused: the capability exists and functions perfectly, but no signal on any surface the user samples announces it, so the user's option set is bounded by the visible interface and the feature is operationally nonexistent.

Core Idea¶

Discoverability failure is the interaction-design condition in which a capability genuinely exists in a system — is implemented, tested, and listed in the engineering inventory — but the interface surface presents no signal, label, affordance cue, or contextual prompt that would announce the capability's existence to a user who has not been independently told it is there. The system is complete and correct; the feature is merely invisible. The user's effective option set is bounded by the visible interface surface, not by the underlying supported set, so the undiscoverable capability is operationally nonexistent for that user even though it functions perfectly for any user who already knows to look.

The structural gap has three components: a latent capability in the system; an interface surface on which signals about that capability could be placed but are not; and a user whose option-set construction depends on the surface, not on the implementation. The gap between the supported option set and the user's discovered set is the failure space. The intervention is not documentation or training — it is placing a perceptible cue (menu item, tooltip, autocomplete suggestion, onboarding highlight, command-palette entry) on a surface the user reliably samples during the task flow where the capability is relevant.

The failure is distinct from information-scent failure, which is when the cue exists but mispredicts the destination, and from empty-state failure, which is when the user reaches a view whose content absence goes unscaffolded. Discoverability failure occurs before any attempt: the user never forms the intention to use the capability because no surface signal makes its existence part of the user's model of what the system can do.

Structural Signature¶

Sig role-phrases:

the latent capability — a genuinely supported, implemented, tested operation in the system, present in the engineering inventory
the interface surface — the locations on which a signal about the capability could be placed but is not
the user's sampling pattern — which surfaces the user reliably inspects for capability cues during the relevant task flow
the supported set vs. discovered set split — the system's full capabilities versus the user's experienced option set, which is built from sampled surfaces and the signals placed on them, not from the implementation
the discoverability gap — the difference between supported and discovered set: the failure space, measurable in adoption telemetry, search logs, and usability studies
the before-any-attempt position — the failure occurs before any attempt: no surface signal ever makes the capability part of the user's model, so the intention is never formed
the operational-nonexistence outcome — an unsignaled capability is operationally nonexistent for that user no matter how well it functions for anyone who already knows to look
the place-a-cue intervention — close the gap by putting a perceptible cue (menu item, tooltip, autocomplete, command-palette entry, onboarding highlight) on a sampled surface, or bringing a cued surface into the sampling path — not documentation or training

What It Is Not¶

Not a missing or broken feature. The capability genuinely exists — implemented, tested, in the engineering inventory — and works perfectly for anyone who knows to look. What is absent is the surface signal that would announce it. The system is complete and correct; the feature is merely invisible, so the fault is in the interface's advertising, not in the implementation.
Not a documentation or training problem. The remedy is not a help article, tour, or tutorial. Those teach a feature whose problem is invisibility on the surface and leave the discovered set unchanged for users who never reach the documentation. The fix is to place a perceptible cue on a surface the user already samples in the relevant flow — a design-budget move, not a documentation-budget one.
Not user fault. "They should have explored more" misdiagnoses it. A user's effective option set is built from the surfaces they sample and the signals placed there, not from their diligence; a capability with no cue on a sampled surface is operationally nonexistent regardless of how curious the user is. The complaint "I didn't know I could do that" is evidence about the surface, not the person.
Not information-scent failure. A scent failure has a cue that exists but mispredicts its destination — the user forms an intention and is misled. Discoverability failure has no cue at all: the intention is never formed because nothing made the capability part of the user's model. One fixes the cue's prediction; the other places a signal that was never there.
Not empty-state failure. In an empty-state failure the user has already arrived at a view and finds its content absence unscaffolded. Discoverability failure occurs before any attempt, upstream of arrival — the user never navigates toward the capability because its existence never entered their model. The two sit at different points in the interaction loop and call for different fixes.
Not information asymmetry. This is not a case of parties holding unequal private knowledge. Both the designer and the system fully "know" the capability; nothing is concealed or strategically withheld. The user simply lacks a surface signal, a perceptual gap on a shared, non-secret interface — not an epistemic advantage one party holds over another.

Scope of Application¶

Discoverability failure lives across HCI and interaction design — every interactive substrate where a user builds an option set from the surfaces they sample; its reach is within that domain. The cross-domain cousins (unclaimed welfare benefits, invisible legal rights, low-take-up public services) are co-instances of the parent invisible_affordance / unsignaled_capability, not literal habitats here, and the interface-design apparatus does not travel to them.

GUI applications — hidden menu items, gesture-only operations (right-click, swipe-revealed, long-press on mobile), keyboard shortcuts without menu mirroring, and "secret" settings reachable only through search.
Web applications — features behind hover-only menus on touch devices, never-expanded accordions, and settings pages organized by internal team boundaries rather than user task.
Voice and conversational UIs — a skill or intent exists but no surface prompts the user toward it, so they never learn what the assistant can do beyond what they have tried.
Command-line tools — hidden subcommands, undocumented flags, and behavior gated by environment variables not surfaced in --help.
APIs — endpoints documented in code but absent from the published reference, and rate-limit-relief options offered only on request.

Clarity¶

Naming discoverability failure reframes the recurring user complaint "I didn't know I could do that" away from user blame — they should have read the documentation, taken the tour, explored more — and toward an interface-design diagnosis: the surface failed to advertise a capability that was sitting right there. That reframing moves the intervention out of the training-and-documentation budget and into the design budget, because the fix is not teaching the user about the feature but placing a perceptible cue on a surface the user already samples during the relevant task. A team that has internalized the concept stops shipping a help article to paper over the gap and starts asking where, in the user's actual flow, the capability's existence could become visible.

The concept's sharper work is to make the discovered set a first-class object distinct from the supported set. A practitioner can now hold apart what the system can do (the engineering inventory) from what any given user knows it can do (bounded by the surfaces they sample and the signals placed there), and treat the difference between the two as a measurable failure space — readable in adoption telemetry, search logs, and usability studies — rather than an unfortunate fact about users. Naming it also fixes its position in the interaction loop relative to its near neighbors, which the bare phrase "bad UX" blurs together: discoverability failure happens before any attempt, when the user never forms the intention because no signal made the capability part of their model of the system — upstream of information-scent failure, where a cue exists but points to the wrong destination, and of empty-state failure, where the user has already arrived somewhere and finds it unscaffolded. The diagnostic question becomes precise: not "why did the user fail at this?" but "which surface that the user reliably inspects carries no signal of a capability that lives behind it?"

Manages Complexity¶

An interaction designer otherwise confronts a long, heterogeneous catalogue of "bad UX" complaints, each looking like its own defect: a hover-only menu invisible on touch devices, a gesture no one finds, a keyboard shortcut with no menu mirror, a setting buried three accordions deep, a voice skill the user never invokes, an undocumented CLI flag, an API endpoint absent from the published reference. Treated as separate bugs, each invites its own one-off remedy and its own help article. Discoverability failure compresses the whole catalogue into a single structural relation between three objects — a latent capability, an interface surface where a signal could sit but does not, and a user whose option set is built from the surfaces they sample rather than from the engineering inventory — so the designer reasons about one failure space, the gap between the supported set and the discovered set, instead of re-diagnosing each symptom from scratch. That compression hands the analyst a measurable quantity in place of an anecdote: the supported-minus-discovered gap is readable directly in adoption telemetry, search logs, and usability studies, and every distinct symptom becomes the same gap manifesting on a different surface. The qualitative outcome then reads off a small set of factors — which surfaces the user reliably samples in the relevant task flow, and whether any of them carries a perceptible cue for the capability that lives behind it. If a sampled surface signals the capability, it enters the user's model and the gap closes; if no sampled surface signals it, the capability is operationally nonexistent regardless of how well it is implemented. The intervention family collapses identically: every fix is the same move — place a perceptible cue (menu item, tooltip, autocomplete suggestion, command-palette entry, onboarding highlight) on a surface the user already inspects, or bring a cued surface into the user's sampling path — rather than a bespoke per-feature campaign of documentation and training. Locating the failure precisely in the interaction loop further prunes the branch structure: because discoverability failure sits before any attempt (no intention is ever formed), it is cleanly separable from information-scent failure (a cue exists but points to the wrong destination) and empty-state failure (the user arrived and found nothing scaffolded), so the diagnostic narrows from the open-ended "why did the user fail?" to the sharp, surface-indexed "which surface that the user reliably inspects carries no signal of a capability behind it?"

Abstract Reasoning¶

Discoverability failure licenses a family of design-reasoning moves built on one relation: the user's discovered set is constructed from the surfaces they sample, not from the engineering inventory, so a capability with no signal on a sampled surface is operationally nonexistent regardless of how well it is built. The diagnostic move runs from a surface symptom — low adoption of a shipped feature, a "I didn't know I could do that" report, users laboriously hand-rolling something the system already does — back to a structural cause that is explicitly not user fault: the analyst infers that some surface the user reliably inspects during the relevant task carries no perceptible cue for a capability living behind it, and locates the failure in the gap between the supported set and the discovered set rather than in user diligence. The reasoning is surface-indexed: from the symptom one predicts where the missing signal sits by asking which surfaces the user samples in that flow and checking each for a cue, and the gap itself is treated as a measurable quantity readable in adoption telemetry, search logs, and usability studies — so the diagnosis yields a number, not an anecdote.

The boundary-drawing move fixes the failure's position in the interaction loop, and that position is load-bearing because it separates this diagnosis from look-alikes that demand different fixes. Discoverability failure occurs before any attempt: the user never forms the intention to use the capability, because no surface signal ever made its existence part of their model of what the system can do. Reasoning from this boundary, the analyst distinguishes it from information-scent failure, where a cue does exist but mispredicts its destination (the user forms an intention and is misled), and from empty-state failure, where the user has already arrived somewhere and finds it unscaffolded. The decision procedure is sharp: did the user never form the intention (discoverability failure, place a signal), form it and get pointed wrong (scent failure, fix the cue's prediction), or arrive and find nothing (empty-state failure, scaffold the view)? Mis-locating the failure point predicts the wrong remedy, so getting the boundary right is the first analytic act.

The interventionist move reasons forward from the gap to its closure and rules out an entire class of remedies as misdirected. Because the failure is absence of signal on a sampled surface — not absence of knowledge in the user — the predicted effective intervention is to place a perceptible cue (a menu item, tooltip, autocomplete suggestion, command-palette entry, onboarding highlight) on a surface the user already inspects, or to bring an already-cued surface into the user's sampling path; and the prediction is directional — if a sampled surface comes to signal the capability, it enters the user's model and the gap closes, while if no sampled surface signals it the capability stays operationally nonexistent. The same structure predicts that documentation, help articles, and training are the wrong budget: they attempt to teach a feature whose problem is invisibility on the surface, so they are predicted to leave the discovered set essentially unchanged for users who never reach the documentation, and the move accordingly redirects effort from the documentation budget to the design budget before a single help article is written. The recurring design habit the concept installs is to hold the supported set and the discovered set apart as separate first-class objects and, for any capability, to ask not "why did the user fail?" but "which surface that this user reliably inspects carries no signal of the capability behind it?" — converting an open-ended usability question into a surface-by-surface audit with a measurable target.

Knowledge Transfer¶

Within HCI and interaction design the concept transfers as mechanism, because the three-object relation it names — a latent capability, an interface surface where a signal could sit but does not, and a user whose option set is built from sampled surfaces rather than the engineering inventory — holds across every interactive substrate. The diagnostic move (read low adoption or an "I didn't know I could do that" report back to a missing signal on a sampled surface, not to user diligence), the supported-set-versus-discovered-set framing measured in adoption telemetry and search logs, the before-any-attempt boundary that separates it from information-scent and empty-state failures, and the single intervention family (place a perceptible cue on a surface the user already samples, or bring a cued surface into the sampling path) all carry intact across GUI applications (hidden menu items, gesture-only operations, unmirrored keyboard shortcuts, buried settings), web applications (hover-only menus on touch, never-expanded accordions, team-organized settings pages), voice and conversational UIs (skills the user never invokes), command-line tools (hidden subcommands, undocumented flags), and APIs (endpoints absent from the published reference). The supporting theory transfers with it: Norman's perceived-versus-real affordances (real affordances must be made perceivable), information-foraging's surface-sampling-with-cost (no scent on a sampled surface means unfindable), and CLI discoverability conventions (--help, tab completion, command palettes) generalize to graphical slash menus and global search. Within the domain this is mechanism transfer, not analogy.

Beyond computing interfaces the honest report is (B) shared abstract mechanism: the underlying pattern is genuinely cross-domain, but it travels under a more general name, not under "discoverability failure." The parent is invisible affordance / unsignaled capability (filed as an emergent candidate): a capability, right, service, or opportunity genuinely exists, but no surface signals it to the potential user, so it is operationally nonexistent for everyone not independently told. That pattern recurs as genuine co-instances across domains: unclaimed welfare benefits and legal entitlements people do not know exist; library or archive holdings invisible to non-experts; organizational rights and HR remedies employees discover only when they litigate; public services with low take-up because of invisible-to-the-target-population design; statute-book provisions that go unused; latent reciprocity in a social network (one could ask, but the ask is not signaled as okay); even latent ecological niches signaled to no prospective coloniser. In each, the failure is absence of signal about an existing capability, and the cross-domain lesson — audit which surfaces the potential user samples and whether any signals the capability — is exactly what carries. So when the lesson is wanted outside HCI, carry invisible_affordance / unsignaled_capability, of which discoverability failure is the interface-design instance.

What stays home-bound is the entry's HCI cargo: the interface surface and sampling pattern as design objects, the catalogue of concrete cues (menu item, tooltip, autocomplete, command-palette entry, onboarding highlight), the precise interaction-loop position relative to information-scent and empty-state failures, and the telemetry/usability-study measurement substrate. These presuppose a designed interface and a user navigating it, and they do not survive extraction to a welfare entitlement or a statute. So invoking "discoverability failure" for an unclaimed benefit is (A) analogy in naming — apt, because the mechanism really is the shared parent, but the interface-design apparatus does not come along. Two boundaries keep this exact: discoverability failure is the negative-space counterpart of the positive affordance prime (the fit exists but is perceptually inaccessible), and it is distinct from information_asymmetry (where parties hold unequal private knowledge — here both designer and system "know" the capability and the user merely lacks the surface signal) and from traceability (which is about audit-trail followability, not option-set visibility). When the lesson generalizes, carry invisible_affordance; "discoverability failure" is its interaction-design instance. See Structural Core vs. Domain Accent for why this profile places the entry as a domain-specific instance of that parent rather than a prime.

Examples¶

Canonical¶

The textbook instance is the pull-to-refresh gesture, introduced by Loren Brichter in the Tweetie iPhone client around 2009 and later adopted across mobile applications. Pulling a list downward past its top edge to reload it was fully implemented and worked flawlessly — but in its earliest form nothing on the static screen announced the gesture existed. A user who was never told simply never pulled: the capability was present in the code yet absent from the user's model of what the app could do. The design response was not a tutorial but a perceptible cue placed on the surface the user already touches — a spinner and an appearing "release to refresh" indicator that animate into view as the finger drags, converting an invisible gesture into a signaled one on the exact surface where the action occurs.

Mapped back: The reload gesture is the latent capability; the list view the user drags is the interface surface, and with no animating indicator it carried no cue, so the supported set vs. discovered set split was maximal — a working capability sitting in the operational-nonexistence outcome for anyone not told. Because the user never pulled at all, the failure sat at the before-any-attempt position; the drag-revealed spinner is precisely the place-a-cue intervention on a surface already in the user's sampling pattern.

Applied / In Practice¶

Command palettes are the mature production remedy for discoverability failure across professional software. Editors and collaboration tools — VS Code's Ctrl/Cmd+Shift+P palette, Slack's and Notion's Cmd+K, Linear's keyboard-driven command menu — expose hundreds of deeply nested or menu-less operations through a single searchable overlay: a user types a fragment of intent ("split editor," "archive," "toggle theme") and the matching command surfaces with its shortcut. Rather than teaching each buried feature through documentation, the palette brings a single cued surface into the user's sampling path, so any capability the engineering inventory supports becomes reachable by search from one place. The design bet is that fuzzy-searchable text on a reliably-invoked surface closes far more of the gap than help articles the user never opens.

Mapped back: Each buried operation is a latent capability whose menu location the user never samples; the palette is a new interface surface deliberately inserted into the user's sampling pattern. By making the supported operations searchable from one place, it collapses the discoverability gap between the supported and discovered sets — a place-a-cue intervention (bringing a cued surface into the sampling path) chosen over documentation, which would have left the operationally-nonexistent features unchanged for users who never read it.

Structural Tensions¶

T1: Signal placement versus surface saturation (the cure competes with itself). The prescribed fix is to place a perceptible cue on a surface the user reliably samples — but every such surface has finite perceptual budget, and the sampled surfaces are precisely the crowded ones. Close the gap for one latent capability by adding a menu item, tooltip, or onboarding highlight, and you consume attention that the next capability's cue will also demand; signal every operation and the surface degrades into undifferentiated noise, at which point no single cue is discovered and the sampling pattern itself collapses. The move that closes one discoverability gap can widen the aggregate one. There is no free surface: advertising is rivalrous with the legibility that makes advertising work. Diagnostic: Would adding this cue leave the surface still scannable, or does it push the surface past the point where its cues stop being sampled as signal?

T2: Point cues versus a meta-surface (fix each feature or fix findability). One family of remedies signals a specific capability where it is relevant — the drag-revealed spinner announcing pull-to-refresh. Another abandons per-feature cueing and inserts a single searchable surface — the command palette — into the sampling path, so any supported operation becomes reachable without ever cueing it in place. The first is precise and contextual but must be re-done for every new capability the engineering inventory grows; the second closes the gap wholesale but only for users who learn to invoke the meta-surface, itself a capability that can suffer its own discoverability failure (the palette nobody knows exists). The tension is between exhaustively signaling a fixed feature set and delegating findability to one surface that must first itself be discovered. Diagnostic: Is the capability set stable enough to cue in place, or churning fast enough that only a searchable meta-surface keeps the discovered set from perpetually lagging?

T3: A failure defined by absence versus the evidence it leaves (measuring a non-event). The concept's load-bearing boundary is that discoverability failure occurs before any attempt — the user never forms the intention, never navigates, never acts. But that exact property is what makes it hardest to observe: an attempt that never happens writes no row in the interaction log, whereas information-scent and empty-state failures both leave traces of an intention that was formed and then frustrated. The supported-minus-discovered gap is called measurable in adoption telemetry and search logs, yet what those instruments record is downstream inference — low adoption, users hand-rolling an existing feature, searches for a capability that is already present — never the silence itself. The most upstream failure is the one with the faintest signature. Diagnostic: Does the evidence show an intention that was formed and misled, or must the failure be inferred from the absence of any attempt at all?

T4: The sampled surface versus the relevant moment (two conditions that pull apart). An effective cue must satisfy two things at once: it must sit on a surface the user reliably samples, and it must appear in the task flow where the capability is actually relevant. These conditions routinely conflict. An onboarding highlight lands on a surface everyone sees but does so before the user has any task-context to attach the capability to, so the cue is sampled and forgotten. A contextual prompt fires at the exact moment of relevance but on a surface the user may not be inspecting then. Optimizing for reliable sampling drifts the cue away from the moment of need; optimizing for relevance risks placing it where no one is looking. The place-a-cue intervention is underdetermined until both axes are satisfied together. Diagnostic: Is this cue on a surface the user actually samples and present at the moment the capability becomes relevant — or has it traded one for the other?

T5: Invisibility as failure versus invisibility as design (progressive disclosure cuts both ways). Not every unsignaled capability is a defect. Keyboard shortcuts without menu mirrors, hidden CLI flags, and power-user gestures are often deliberately kept off the primary surface so beginners meet an uncluttered interface while experts reach past it — the same absence-of-signal that defines the failure is here a designed layering. The concept insists the discovered set is the designer's responsibility, yet a system that signaled every capability to every user would drown novices in options they will never use. The boundary between a discoverability failure to be repaired and intentional progressive disclosure to be preserved is not readable from the surface alone; it depends on whether the target user for that capability samples a surface that signals it. Treat all hiddenness as failure and you flatten the expertise gradient; treat none as failure and you excuse genuine invisibility. Diagnostic: Is this capability hidden from a user who needs it and samples a surface that should carry it, or deliberately layered away from a user for whom it is not yet relevant?

T6: Autonomy versus reduction (interface diagnosis or the interface instance of an unsignaled capability). "Discoverability failure" is a sharply specified HCI object, with its own apparatus — the interface surface and sampling pattern as design objects, the concrete cue catalogue (menu item, tooltip, autocomplete, command-palette entry), the precise interaction-loop position against information-scent and empty-state failures, and a telemetry measurement substrate. Yet its portable core is not proprietary: the pattern travels under the more general parent invisible_affordance / unsignaled_capability — a capability, right, service, or opportunity genuinely exists but no surface signals it, so it is operationally nonexistent for everyone not independently told. Unclaimed welfare benefits, invisible legal entitlements, low-take-up public services, and unused statute provisions are genuine co-instances of that parent, not habitats of this entry, and the interface apparatus does not follow them. The tension is between a standalone interaction-design concept that earns its own audit procedure and the recognition that its cross-domain cargo already belongs to its parent. Diagnostic: Resolve toward invisible_affordance / unsignaled_capability when the lesson must reach a benefit, a right, or a service; toward discoverability failure when diagnosing a user's option set on a designed interface in situ.

Structural–Framed Character¶

Discoverability failure sits at mixed on the structural–framed spectrum — a genuine unsignaled-capability structure at its core, but framed as an interface-design failure mode bound to designed artifacts and goal-driven human users. On evaluative_weight it leans framed: "failure" is a defect diagnosis, not a neutral mechanism-name; even as the concept analytically relocates blame from user to artifact, it does so precisely to identify something to be fixed (a "gap," a "debt" in the sampled surface), so it carries a normative charge heavier than an evaluatively silent structure. On human_practice_bound it is framed: the three-object relation (latent capability, interface surface, sampling user) presupposes a designed interface and a human building an option set from the surfaces they sample; remove the interface-and-user situation and there is no failure, only the abstract unsignaled-capability shape. Institutional_origin is framed: it is an HCI concept resting on Norman's affordance/signifier theory and a telemetry/usability-study measurement substrate — an artifact of a design discipline, not a structure found observer-free. Vocab_travels is bounded: the interface surface, sampling pattern, concrete cue catalogue (tooltip, command-palette entry, onboarding highlight), and interaction-loop position are pinned to designed interfaces and do not survive extraction to a welfare entitlement or a statute. Import_vs_recognize: within HCI the mechanism is recognized intact across GUI, web, voice, CLI, and API substrates, but beyond computing interfaces only the parent pattern recurs — unclaimed benefits, invisible legal rights, low-take-up services are genuine co-instances of the parent under a different name, reached by analogy in naming.

The portable structural skeleton is invisible_affordance / unsignaled_capability — a capability, right, service, or opportunity genuinely exists, but no surface signals it to the potential user, so it is operationally nonexistent for everyone not independently told — and it is not proprietary to the HCI concept: it is what discoverability failure instantiates from that umbrella pattern (itself the negative-space counterpart of the positive affordance prime, distinct from information_asymmetry and traceability). That parent carries the audit-the-signals lesson cross-domain as genuine co-instances; the interface surface and sampling pattern as design objects, the concrete cue catalogue, the precise interaction-loop position against scent- and empty-state failures, and the telemetry measurement substrate are the domain accent that stays home and keeps the entry a domain-specific instance rather than a prime. The cross-domain reach belongs to invisible_affordance, not to "discoverability failure." Its character: a genuinely structural unsignaled-capability pattern packaged as a normative interface-design failure diagnosis, structural in the invisible-affordance skeleton it instantiates and held at mixed by the defect framing and designed-interface practice that constitute it.

Structural Core vs. Domain Accent¶

This section decides why discoverability failure is a domain-specific abstraction and not a prime, and it carries the case for its domain-specificity — there is no separate section for that.

What is skeletal (could lift toward a cross-domain prime). Strip the interface design and a thin relational structure survives: a capability, right, service, or opportunity genuinely exists, but no surface signals it to the potential user, so it is operationally nonexistent for everyone not independently told, and the effective option set is bounded by what is signaled rather than by what is supported. The portable pieces are abstract — a latent capability, a set of surfaces the agent samples, an absence of signal on those surfaces, and an option set built from signals rather than from the underlying inventory. That structure is genuinely substrate-portable, which is exactly why discoverability failure instantiates the catalog pattern invisible_affordance / unsignaled_capability — itself the negative-space counterpart of the positive affordance prime (the fit exists but is perceptually inaccessible). This unsignaled-capability idea is the core the concept shares — and it is what genuinely recurs, as co-instances not metaphors, in unclaimed welfare benefits, invisible legal entitlements, low-take-up public services, and unused statute provisions — but it is not what makes discoverability failure distinctive.

What is domain-bound. Almost all the distinctive content is HCI furniture and none of it survives extraction intact: the interface surface and the user's sampling pattern as design objects; the supported-set-versus-discovered-set split measured in adoption telemetry, search logs, and usability studies; the concrete cue catalogue (menu item, tooltip, autocomplete suggestion, command-palette entry, onboarding highlight); the precise interaction-loop position — before-any-attempt — that separates it from information-scent failure (a cue exists but mispredicts) and empty-state failure (the user arrived and found nothing scaffolded); and the design-budget-not-documentation-budget prescription. These are the worked vocabulary, the diagnostic, and the canonical cases (pull-to-refresh invisible until the drag-revealed spinner; the command palette bringing a searchable surface into the sampling path) the discipline actually studies — all specific to a designed interface and a user navigating it. The decisive test: remove the designed interface and its sampling user — an unclaimed benefit, an invisible legal right, a low-take-up service — and the interface surface, the cue catalogue, the interaction-loop position, and the telemetry substrate have no referent; invoking "discoverability failure" there is apt only by analogy in naming, because the interface-design apparatus does not travel, which is the tell that the crossing content is the parent pattern, not this named failure mode.

Why this does not clear the prime bar. A prime is a relational structure whose vocabulary travels and whose cross-domain transfer is recognition of the same mechanism, not analogy. Discoverability failure's transfer is bimodal. Within HCI and interaction design it travels intact as mechanism: the three-object relation, the diagnostic (read low adoption or "I didn't know I could do that" back to a missing signal on a sampled surface, not user diligence), the supported-versus-discovered framing, the before-any-attempt boundary, and the single intervention family (place a perceptible cue on a sampled surface, or bring a cued surface into the sampling path) all carry without translation across GUI, web, voice, CLI, and API substrates, with the supporting theory (Norman's perceivable affordances, information-foraging's surface-sampling-with-cost) generalizing with them. Beyond computing interfaces the named failure mode does not travel as such: its cross-domain instances are genuine co-instances of a more general pattern than "discoverability failure," so what carries to a welfare office, a statute book, or an HR department is not the interface concept but the underlying pattern under each domain's own vocabulary. And when that bare structural lesson is needed cross-domain — a wanted capability goes unreached because no surface the potential user samples signals it; audit the surfaces and place a signal, don't blame the user — it is already carried, in more general form, by the pattern discoverability failure instantiates: invisible_affordance / unsignaled_capability, the negative-space counterpart of affordance (and distinct from information_asymmetry, where parties hold unequal private knowledge, and from traceability, which is audit-trail followability). The cross-domain reach belongs to that parent; "discoverability failure," as named, carries the interface surface and sampling pattern, the concrete cue catalogue, the interaction-loop position, and the telemetry measurement substrate that stay home and should.

Relationships to Other Abstractions¶

Current abstraction Discoverability Failure Domain-specific

Parents (2) — more general patterns this builds on

Discoverability Failure presupposes Discoverability Domain-specific

A discoverability failure presupposes the graded discoverability property whose supported-versus-encountered gap the defect diagnosis thresholds and localizes.
Discoverability Failure is a decomposition of Invisible Affordance Prime

Removing the interface-design frame from discoverability failure leaves the invisible-affordance pattern of a real capability excluded from an agent's option set because sampled surfaces do not signal it.

Hierarchy paths (5) — routes to 4 parentless roots

Discoverability Failure → Discoverability → Coverage / Reachability → Completeness

Show alternative paths (4)

Not to Be Confused With¶

Discoverability (the positive property). The graded system property measuring the degree to which features can be found through exploration. Discoverability failure is the specific defect diagnosis — a particular capability going unfound because no sampled surface signals it. One is the continuous quality being measured; the other is a named failure mode within it (treated as its own entry). Tell: is the referent the overall find-ability of a system (discoverability), or the specific unsignaled-capability defect (discoverability failure)?
Information-scent failure. A cue exists but mispredicts its destination — the user forms an intention, follows the cue, and is misled to the wrong place. Discoverability failure has no cue at all: the intention is never formed. One fixes the cue's prediction; the other places a signal that was never there. Tell: did the user follow a cue that pointed wrong (scent failure), or never see a cue and so never try (discoverability failure)?
Empty-state failure. The user has already arrived at a view and finds its content absence unscaffolded — no guidance on what to do in the blank space. Discoverability failure occurs before any attempt, upstream of arrival: the user never navigated toward the capability at all. Different points in the interaction loop, different fixes. Tell: did the user reach a barren view and get stranded (empty-state failure), or never reach it because its existence never entered their model (discoverability failure)?
Information asymmetry. Parties holding unequal private knowledge, often strategically withheld (a seller knowing a car's defects). Discoverability failure involves no secret and no epistemic advantage: both designer and system fully "know" the capability, and the user merely lacks a surface signal on a shared, non-secret interface. Tell: is one party concealing or privately holding knowledge (information asymmetry), or is the capability openly present but simply unsignaled (discoverability failure)?
Missing or broken feature. The capability does not exist or does not work — a genuine implementation gap. Discoverability failure has the feature fully implemented, tested, and correct; only its advertisement is absent. Opposite remedies: build it versus surface it. Tell: does the capability fail to function or not exist (missing/broken feature), or work perfectly for anyone who knows to look while being invisible to those who don't (discoverability failure)?
The parent pattern it instances (invisible_affordance / unsignaled_capability). The substrate-neutral structure — a capability, right, service, or opportunity genuinely exists but no surface signals it, so it is operationally nonexistent for everyone not independently told. This carries to unclaimed benefits, invisible legal rights, and low-take-up services as genuine co-instances; discoverability failure is the interface-design instance. (It is the negative-space counterpart of the positive affordance prime, and distinct from traceability, which is audit-trail followability.) Tell: strip the designed interface and what remains — an unsignaled capability the user is never told about — is this parent, not discoverability failure. (Treated more fully in earlier sections.)

Neighborhood in Abstraction Space¶

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

Family — Software Evolution & Systemic Laws (16 abstractions)

Nearest neighbors

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