Interface Legibility & Navigability

Abstractions about whether an interface lets users see and reach where they need to go — visible system status and progress indicators, accessible and operable input paths, and failure modes like empty states, mode errors, keyboard traps, and navigation or orientation loss.

12 abstractions in this family — domain-specific abstractions that sit near one another in structural-signature space (k-means over structural-signature embeddings). Each is shown with its short description.

• Empty State Design — The UI practice of deliberately designing the zero-content view — treating it as a first-class state with a fixed four-slot template (message, intentionality cue, call-to-action, optional sample) rather than whatever the populated layout degrades to.
• Empty-State Failure — The interface condition in which a view has no content and provides no scaffolding for the absence — no explanation of the cause, no disambiguation among the possible causes (new, filtered, permission, loading, error), and no next action — so the user, left to infer meaning from nothing, typically concludes wrongly that the system is broken or gated.
• Keyboard Accessibility — The design property that every interactive function in a GUI can be operated with the keyboard alone — making the keyboard a channel-redundant, complete alternative to the pointer, and the upstream contract every assistive technology depends on.
• Keyboard Trap — The accessibility failure where a keyboard-only user moves focus into a UI element that receives focus but never yields it — an absorbing state in the focus-navigation graph, invisible to mouse users because a click supplies the exit edge they lack.
• Mode Error — The interaction failure in which the same user action is interpreted differently by a system depending on a hidden mode the user does not perceive — the user acts correctly for the mode they believe is active, and the system, in the actually active mode, does something else.
• Navigation loop — Diagnose a workflow where a user cannot reach their goal by modeling the interface as a directed graph and asking one structural question — is any goal state reachable from the current state? — rather than blaming screen quality or user confusion.
• Operable Design — The commitment that every action an artefact requires must have at least one operationally-equivalent alternative path across input modalities and motor envelopes, so users are not gated out by assumptions about how actions are performed.
• Orientation Loss — Diagnose why a competent user gets lost by checking three location facts — where am I, what can I move to, how did I arrive — at each transition seam, reading the orientation state off the count of missing facts regardless of substrate.
• Progress Indicator — A UI element that externalises a running process's position — how far along, how much remains, whether it is still alive — to resolve the uncertainty that would otherwise drive a waiting user to abandon or repeatedly check in.
• 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.
• Stream Processing — Compute over data as it arrives — one record or small time-window at a time — under a bounded-latency commitment, decoupling when an event happened from when it arrived and using a watermark to decide when a time window is safe to close and emit.
• Visibility of System Status — Keep users out of the dark by making a system's hidden internal state externally legible through timely, appropriately calibrated feedback — enumerating every state a user's actions can induce and asking, for each, whether the user can see they are in it in time to choose a next action.