General GUI and Direct Manipulation Design Guidelines

For designers and engineers: a graphical interface lets people believe "what I see is the thing itself, and if I move it, it changes." These guidelines do not specify what controls look like, but the conditions that must be fulfilled for that belief to hold — objects can be identified, consequences can be foreseen, changes can be undone, states can be said true or false, the task can still be completed with a different hand, and what has not yet been submitted does not disappear.

A graphical interface product does one thing in two halves: it displays the system's internal state as objects the user can identify, and it translates the user's actions on those objects back into internal system changes. Direct manipulation works well because the distance between these two halves is short enough — what is seen is what can be operated on, the result of an action is immediately visible, and mistakes can be undone. The most common design error in this domain is mistaking "looks like direct manipulation" for "is direct manipulation": a block on the screen has moved but the server has not received it yet; a grayed-out button cannot say why it is gray; seventeen objects are selected but only three are visible on screen; dragging is the only way to change the order; a form is cleared and must be refilled after a failed submission. None of these are cases of a control simply looking bad — they are cases where the interface's promise to the user was not fulfilled.

These guidelines consist of six principles and 38 rules: principles state the design direction; rules specify applicability conditions, behavior requirements, and verification methods. Each rule belongs to one and only one principle, and the rule number is the principle number (UI3-2 is the second rule under the third principle).

Principles are divided by regulated object, not by interface region or control category. The reason: the same control carries entirely different obligations at different moments — a "delete" button, before it is clicked, is a question of the object's operability (can it be clicked, why can't it be clicked); at the instant it is clicked, it is a question of consequence and reversibility (what will be deleted, can it be undone); after it is clicked, it is a question of feedback (was it accepted, did it succeed); and whether it can be reached on both touchscreen and keyboard is a question of input parity. Dividing by control would blend these four obligations into a single "delete button guideline"; dividing by object lets each obligation be verified independently.

Scope of application: Web, desktop, and mobile products that carry object operations in windows, pages, forms, lists, or canvases. These guidelines specify behavior requirements for objects, actions, feedback, input, data entry, and manipulation; they do not specify visual style, component APIs, or implementation frameworks. An interface without drag-and-drop, batch operations, or remote writes may record the corresponding clauses as not applicable; a missing implementation cannot be written up as not applicable.

Each rule should yield three auditable deliverables: design decision, mechanism fact, user feedback. For "preserve input after a failed submission," for example, it must state which fields are preserved, where the system recovers from, and how the user continues. Drawing only the success state or filling in parameters does not prove the promise holds.

Four chapters in all: Chapter 1 principles, Chapter 2 how to read and quick-reference the rules, Chapter 3 rules in detail, Chapter 4 terminology; for verification checklists, evidence notes, and minimal design records see Appendices A, B, C; for complete sources see reference.md; for configurable items see General GUI and Direct Manipulation Design Token.

---

1. Six principles¶

The six principles divide design responsibility by regulated object: each principle governs the obligations on one category of object, and each rule belongs to the single principle matching the direct regulated object of its obligation. Different objects mean the principles do not substitute for one another — this is both the basis for the division and the way to test it.

A single scenario can touch multiple principles — a user marquee-selects twenty files, drags them into another folder, sees a progress bar after releasing, and the network fails partway through — this one step simultaneously faces whether the objects the selection refers to can be verified (UI1-4), whether the cross-container action is a move or a copy (UI6-3), whether the batch result can be reported per object (UI3-5), and whether the whole thing can be rolled back after a partial failure (UI2-6). This is not a classification error: the four rules constrain obligations on four different regulated objects — one is the selection, one is manipulation semantics, one is feedback, one is reversibility. Mutual exclusivity and exhaustiveness are claims this division accepts being tested against, not facts that hold simply by being stated: when a rule's addition, removal, or assignment is in doubt, verify it against the classification test in Appendix A. If it fails the test, what gets changed is the principles' division.

The two boundaries in this division that most need ongoing testing are stated explicitly here: UI1 and UI3 — UI1 governs the object's own state (what the thing is, whether it can be operated, whether it is selected); UI3 governs the system's response to an action (whether it was received, how far along it is, whether it succeeded or failed). A button turning gray belongs to UI1; a button spinning belongs to UI3; "why it can't be clicked" belongs to UI1-3; "what happens after it's clicked" belongs to UI3-2. UI4 and UI6 — UI4 governs which input methods the product declares support for and whether those methods can complete core tasks; UI6 governs the semantics and substitutes of continuous manipulation as a category of action in itself. The direct regulated object of "drag-and-drop must have a non-drag-and-drop equivalent path" is the manipulation of dragging and dropping, so it belongs to UI6; the direct regulated object of "the same task can be completed on keyboard, touchscreen, and gamepad alike" is the scope of the input-method commitment, so it belongs to UI4. If disputes over assignment keep recurring at these two boundaries in practice, the principles should be adjusted rather than adding an intermediate layer.

Principles are used to understand the rules and adjudicate assignment; they are not themselves a separate compliance item. When a principle's interpretation conflicts with a specific clause, the applicable clause governs, and the ambiguity needing clarification is recorded.

A rule's assignment being unique does not mean a mechanism cannot be reused. A single "object identity" is both the basis for a selection persisting after a view change (UI1-5) and the basis for undo locating a specific object (UI2-3), and it is also the precondition for a batch failure report being able to name names (UI3-5); a single "irreversible action list" decides both the confirmation tier (UI2-4) and whether optimistic updates are usable (UI3-4). The same mechanism serving multiple purposes is the norm; which rule it is written under depends on the direct regulated object of the obligation.

2. How to read the rules¶

2.1 The structure of each rule¶

In one sentence, summarizing each part's force: the rule's main text specifies the requirement; "Applies to" and "Boundary conditions" together bound the requirement's scope; "Design application," "Verification examples," "Counterexamples," and "Basis and references" add no further obligation.

A rule states the nature of the behavior, not the implementation: that an action's target object can be verified before submission is product behavior; whether it is presented with a count badge, an expandable list, or a secondary page is a design solution — the two must correspond, but they are not the same deliverable.

2.2 Normative terms¶

The rule text uses three tiers of normative terms:

• MUST: not satisfying it means non-compliance with these guidelines. Without it, some promise to the user would fail under a foreseeable circumstance — this is the sole basis for marking something MUST.
• MUST NOT: the inverse expression at the same strength as MUST, indicating behavior that must not appear; in the main text, "must not" and "prohibited" are treated as equivalent expressions of MUST NOT.
• SHOULD: followed by default; when there is genuine reason to deviate, record the reason and the alternative approach, and accept the same verification. Deviation does not require approval, but it does require a trace. "SHOULD NOT" is the inverse expression of "SHOULD."

Compliance judgments take the independent obligation clauses in the main text as their unit: a declarative sentence without a normative term carries the strength of the rule heading it appears under; a clause with an explicit normative term is judged at its own strength — a MUST NOT clause inside a [SHOULD] rule remains a hard constraint (UI1-6, UI2-5, UI3-3, UI3-6, UI4-5, UI5-5, and UI6-6 contain such clauses), and the strength annotation on a rule heading or the quick-reference table does not replace a clause's binding force. "Cannot" in the main text is used only for statements of capability or fact, and does not express an obligation.

Strength denotes binding force, not importance.

2.3 The two sides of counterexamples¶

Counterexamples have two sides: "under-delivery" is missing this requirement; "over-delivery" is adding a confirmation before every action, hanging an explanation next to every field, and turning every click into an approval, all in the name of satisfying it. Neither side counts as getting it right. General GUIs go wrong densely at both ends: at one end, everything on the interface is moving and nothing can be explained — a grayed-out button that cannot say why it is gray, a deletion with no undo, a form that clears after a failed submission; at the other end, caution is piled onto the user — a confirmation pops up for every deleted row, an input field turns red the moment the first character is typed, and leaving a page is blocked every time regardless of whether anything was changed. The former end makes people afraid to act; the latter teaches people to click "OK" with their eyes closed, and it is precisely this that invalidates the one confirmation that actually matters. Restraint is not the same as vagueness, and caution is not the same as pushing the judgment onto the user.

2.4 Quick reference: 38 rules¶

The table below is the one-sentence memorable version of every rule; click a rule's name to jump to its full text in Chapter 3. The quick reference does not replace each rule's applicability conditions and full requirements; a few [SHOULD] rules contain MUST NOT-level clauses (UI1-6, UI2-5, UI3-3, UI3-6, UI4-5, UI5-5, UI6-6), and the main text governs the judgment (see 2.2).

UI1 Objects can be identified

UI2 Consequences are foreseeable and reversible

UI3 State and feedback are visible

UI4 Input methods are on par

UI5 Entered data is a kind of promise

UI6 Direct manipulation has an equivalent path

3. Rules in detail¶

This chapter expands all 38 rules across the six principles. Each rule's structure and the binding force of its parts are given in 2.1; the design application, verification examples, and counterexamples within it are only notes that help implementation — they do not specify a single component, nor do they require a new, separate deliverable document.

3.1 UI1 Objects can be identified¶

The premise of direct manipulation is that identifiable objects exist in the interface: the user can tell what something is, whether it can be moved, and whether it is currently selected. This principle governs how an object's own state is expressed, and how the correspondence between a command and its target object is established. It does not govern what happens after the command finishes — that belongs to UI2 and UI3. This principle's core claim is: visibility does not imply operability, operability does not imply current availability, and "what is currently selected" is a product state that must be explicitly maintained, not a control's internal variable.

UI1-1An operation has an explicit target objectMUST¶

In one sentence: Every command can say which thing it acts on.

Applies toAny product that provides a graphical interface and allows the user to issue commands to interface elements.

RuleFor every operation that can be initiated, its target object MUST be resolvable to a specific object or set of objects before initiation, and MUST be presentable to the user. Objects MUST have an identity that remains stable across refresh, sorting, filtering, and pagination (see gui.object.identity.key); screen position, row index, or "the one most recently clicked" MUST NOT serve as object identity. When a command's target object changes with the interface context, the currently referenced object MUST be visible at the same time as the command's entry point.

Boundary conditionsThis rule does not require displaying the object's name for every operation. When the target object and the command entry are directly adjacent in space and unambiguous (a delete button within a single row), adjacency itself constitutes presentation. This rule also does not require the object to be a database entity — a selected span of text or an unsaved canvas region is equally an object.

Design applicationMaintain "the current target object" as an explicit interface state, rather than inferring it on the spot at click time. When the same command is invoked from the toolbar, a menu, a keyboard shortcut, and the right-click menu, its scope MUST match what each entry declares. A right-click acting on a single item and a toolbar acting on the selection can coexist, but the target object cannot be changed merely by an unstated input method.

Verification examples

• User side: initiate the same operation from the toolbar, the right-click menu, and a keyboard shortcut, and check whether the target object matches the scope each entry explicitly states.
• Implementation side: check whether command handling depends on object identity rather than a list index; construct a case that sorts and then replays the same command, and observe whether it acts on a different object.

CounterexamplesUnder-delivery — after the list refreshes, pressing "delete" deletes a different record that has since taken that position; over-delivery — the object's full name and identifier are reprinted next to every button, and the interface is swamped with identity information.

Basis and referencesDirect manipulation places the correspondence between a command and its object in the interface rather than in command syntax — this is the basic claim of the interaction paradigm (R01); keeping the object of concern continuously present, and letting interface actions stay close to the task itself, is the mechanism by which "direct" is established (R03).

UI1-2Operability is perceivableMUST¶

In one sentence: Whether something can be clicked is seen, not discovered by trying.

Applies toProducts whose interface contains both operable and non-operable elements at once.

RuleOperable elements MUST be distinguished from non-operable content by a perceptible cue, and this distinction MUST hold under every input method the product declares support for (see gui.input.methods). "Appears only on hover" MUST NOT serve as the sole cue for operability. Operability cues MUST be consistent with the element's actual availability: looking clickable but doing nothing when clicked, and looking unclickable while actually being clickable, are both violations of this rule.

Boundary conditionsThis rule does not specify which cue to use, nor does it require all operable elements to use the same cue. A deliberately exploratory interface (hidden interactions in games or creative tools) may deviate provided the design intent is declared and core tasks retain another visible entry point; but this exception does not apply to the entry points a core task requires.

Design applicationDesign "this element is operable" and "this element is currently available" as two independent expressive dimensions; the former is stable, the latter changes with state. A very dense interface easily degenerates into "everything relies on hover"; at that point, check: once the mouse is moved away, can the user still tell which places can be acted on?

Verification examples

• User side: take screenshots under both touchscreen and keyboard-traversal conditions, and check whether operable elements remain identifiable.
• Implementation side: render the interface with all hover styles disabled, and check whether the identifiability of operable elements drops noticeably.

CounterexamplesUnder-delivery — the action button at the end of a table row only appears when the mouse moves over it, so touchscreen users can't find it; over-delivery — every clickable area gets a border, a shadow, and an icon, so every word in the body text looks like a button.

Basis and referencesPerceivable operability is part of "visibility of system status" (R04); not relying on a single input channel to carry critical commands has corresponding statements in both platform input guidelines and accessibility standards (R07, R12).

UI1-3Unavailable states state their reason and recovery conditionMUST¶

In one sentence: Being grayed out is not the end of the story — it must say why, and how to stop being gray.

Applies toProducts that place an operation or object into an unavailable, read-only, or restricted state.

RuleWhen an object or operation is in an unavailable state, the system MUST let the user learn the reason for the unavailability and the recovery condition; presenting only the unavailable state with no explanation path MUST NOT occur. The reason shown to the user and the determination that actually blocks execution MUST come from the same place (see gui.object.unavailable.reason.source); the interface MUST NOT write up a separate explanation of its own. Different causes MUST be distinguishable: read-only content, insufficient permission, a current state that disallows it, unsupported capability, and quota or deadline limits each have different recovery paths (see gui.object.restriction.kind).

Boundary conditionsThis rule does not require the reason to be permanently displayed; being available on demand (a tooltip, an explanation entry, an explanation after a click) satisfies it. When the reason itself is not actionable by the user and the rationale has been recorded (a specific permission determination withheld for security reasons), it is sufficient to state only that the operation is unavailable under the current identity and provide a path to seek help — this is a value this rule permits, not the default value. This rule does not require unavailable objects to always be shown — not showing them is also a legitimate choice (see gui.object.unavailable.mode), but once shown, the reason must be statable.

Design applicationTreat "why it's unavailable" as a piece of data that shares its determination with the blocking logic, not a hardcoded string of copy. When several conditions are unmet at once, prioritize explaining the one the user can currently change.

Verification examples

• User side: for each category of unavailable state, check whether the user can know what to do next without contacting support.
• Implementation side: after modifying the blocking condition, check whether the on-screen explanation changes accordingly; if it does not, the two determinations come from different sources.

CounterexamplesUnder-delivery — "Save" is permanently gray with no hint at all, and the user tries field after field until giving up; over-delivery — a block of explanatory text sits permanently next to every disabled element, and the interface in its normal state is drowned in exception notes.

UI1-4The selection is a product objectMUST¶

In one sentence: What is currently selected must be verifiable before the user acts.

Applies toProducts that allow the user to select one or more objects and issue commands to the selection.

RuleThe selection MUST be maintained as an explicit product state, with clear semantics for establishing, extending, shrinking, and clearing it (see gui.selection.model). Which objects are currently selected MUST be visible; when the selection may extend beyond the current visible range, a count or a verifiable list MUST be provided (see gui.selection.visibility). The selection MUST be established by the user's explicit designation; it MUST NOT be inferred from scroll position, hover position, or a click not declared as a selection action. A command designed for a single object MUST NOT have its scope automatically expanded merely because a selection exists (see gui.selection.actions.scope). When a "select all" that spans pages or filters is offered, its actual coverage MUST be explicitly presented before submission (see gui.selection.include_filtered).

Boundary conditionsThis rule does not require every list to support multi-select, nor does it prescribe how multi-select is operated. The requirement that "what is currently selected is visible" applies equally to single-select interfaces, but the count and list requirements take effect only for multi-select.

Design application"3 items selected" and "all 1,284 items under the current filter selected" are two different meanings that must be visually distinguishable; the latter should be expandable to view its scope before execution, or at minimum give an accurate total count and the filter condition.

Verification examples

• User side: select several objects, scroll to where they're no longer visible, and check whether it's still possible to know what and how many are selected.
• Implementation side: check whether command handling receives the selection set or the currently highlighted single object; construct a case where the two disagree and observe the actual scope of effect.

CounterexamplesUnder-delivery — a batch of files is checked, and after scrolling there is no selection information left on screen at all, so the user only discovers 40 were selected when clicking delete; over-delivery — a confirmation pops up for every item selected, or the selection list permanently occupies half the screen.

Basis and referencesTreating the selection as a verifiable first-class state, together with "presenting the scope of effect before submission," jointly supports UI2-1 (R04, R10, R12).

UI1-5The selection persists or explicitly lapses after a view changeMUST¶

In one sentence: After sorting or filtering, what's selected is still the same objects as before.

Applies toProducts in which the selection may need to persist across sorting, filtering, pagination, search, or data refresh.

RuleAfter a view change, the selection MUST be preserved by object identity, or explicitly cleared and the user notified (see gui.selection.persistence.on_view_change). Preserving the selection by screen position MUST NOT occur, and giving no notice at all when the objects the selection refers to have changed MUST NOT occur. When the selection is preserved, if some objects are no longer in the current view or have been deleted, the change in scope MUST be knowable to the user.

Boundary conditionsThis rule does not require the selection to persist across sessions, nor across devices. Clearing the selection is a legitimate choice; what this rule requires is that the clearing be disclosed, not that it must persist.

Design applicationStore the selection as a set of object identities, not a set of row indices. On data refresh, verify existence and permission by stable identity; objects outside the filter are kept or cleared per the established selection scope, and a change like "3 of these are no longer under the current filter" is then presented to the user.

Verification examples

• User side: select several items, then change the sort or filter condition, and check whether the selection still refers to the same objects.
• Implementation side: inject a backend data change (an object deleted by someone else), and check whether the selection silently includes or excludes objects with no notice.

CounterexamplesUnder-delivery — after selecting rows 2, 5, and 7 and re-sorting, the selection marks stay on rows 2, 5, and 7, but those are now three different objects; over-delivery — every single data refresh forcibly clears the selection and pops up a notice, making batch operations on a long list impossible to complete.

UI1-6Focus, hover, and selection are expressed separatelySHOULD¶

In one sentence: Where the cursor is, where the mouse is, and what's selected are three different things.

Applies toInterfaces where keyboard traversal, pointer hover, and object selection all exist at once.

RuleFocus (the position currently receiving keyboard input), hover (the position the pointing device currently indicates), and selection (the target object of subsequent commands) SHOULD be expressed separately, not conflated into a single visual state. The product MUST declare which coupling model it adopts (see gui.selection.focus.coupling), distinguishing at least three: selection decoupled from focus (moving focus does not change the selection; selection is initiated by a confirm key or a click); selection follows focus in a single-select context (an arrow key moving focus changes the currently selected item, an established convention for single-select lists and galleries); and a multi-select context handled per the declared multi-select model (moving focus does not change the selection, or a modifier key extends the selection, with the semantics of arrow keys, confirm keys, and selection changes stated separately for each). Under a model where selection follows focus, ordinary traversal MUST NOT trigger an irreversible business effect — whether preview-style loading may occur automatically is judged and recorded separately by its latency cost, whether it changes object state (such as marking something as read), and user intent; this rule does not categorically rule "initiating a preview" a violation.

Boundary conditionsThis rule does not prohibit selection following focus — single-select lists, galleries browsed by arrow key, and some table controls using this mode is an established convention, and it holds in the control semantics of multiple platforms. "A selection change driving focus" and "a focus move driving selection" are two different directions; this rule constrains the latter. What this rule requires is that the coupling model be an explicit design decision carrying the above limits, not a default state. Focus MUST be visible, reachable in task order, and able to exit the current region; the specific behavior is defined in UI4-6.

Design applicationDetermine first whether "the command acts on focus or acts on the selection," then design the visuals. Mixing the two within the same interface (toolbar commands acting on the selection, keyboard shortcuts acting on focus) is a common latent defect.

Verification examples

• User side: traverse a list that already has a selection using the keyboard, and check whether moving focus changes the selection, and whether this behavior matches what was declared.
• Implementation side: check whether the focus state and the selection state are two independent states; construct a case where "focus is on A, the selection is B" and observe which one the command acts on.

CounterexamplesUnder-delivery — keyboard-traversing to an item marks it as read and triggers an externally visible state change, when the user just wanted to scroll further; over-delivery — three sets of high-contrast color blocks are used to distinguish the three states, and the interface looks like a paint swatch during ordinary browsing.

Basis and referencesFocus and selection are treated as distinct states in platform control semantics and accessibility guidance (R08, R10, R12).

3.2 UI2 Consequences are foreseeable and reversible¶

This principle governs the consequences of an action: what it will change, whether that can be reversed once it's done, and if it can't, what method is used to make the user think it through before acting. Its core claim is that undo takes priority over confirmation — confirmation places the burden of judgment at the very instant the user presses the button, which is precisely when the user's attention is least reliable; undo moves that burden of judgment to after the consequence is already visible. Confirmation is used for situations where judgment genuinely has value — irreversibility, major impact, necessary authorization; being undoable does not automatically cancel these confirmations.

UI2-1Consequences are knowable before submissionMUST¶

In one sentence: How much will change, and whether it can be undone, should be known before pressing.

Applies toOperations that change system state, produce an external side effect, or affect other users.

RuleAn operation's scope of impact (which objects it acts on, how many are involved) and its reversibility (whether it can be undone, and to what extent) MUST be knowable before submission. When it acts on multiple objects and includes an irreversible consequence, both the count and the specific objects affected MUST be knowable: the count is displayed explicitly, and an expandable object list or a verifiable query-scope description is provided at the same time (see gui.object.action.scope.display) — giving only the count does not satisfy this rule.

The scope of impact MUST state its basis explicitly, distinguishing and expressing at least three kinds: the current page only, all objects in the current filtered result, a user-designated set of objects that spans filters; and it MUST note whether this scope is a snapshot at the moment of execution or a dynamic query re-evaluated at execution time. When the total has not yet been verified and that count would affect the user's judgment, verification MUST be completed first, or the scope narrowed to known objects; presenting a lower bound with uncertainty applies only to situations that do not affect an important judgment, and is not an unconditional pass. Announcing the scope of impact or the irreversibility for the first time only after the result has occurred MUST NOT occur.

Boundary conditionsThis rule does not require a preview to be shown for every operation. For operations whose scope of impact is obvious and reversible (typing one character into text, checking one checkbox), the visible result itself satisfies this rule. This rule does not require enumerating every object one by one — an accurate count that can be expanded for verification, or that resolves to a clear query scope, is sufficient. When the object set changes between confirmation and execution (a new matching record, an object deleted, a permission change), the execution scope MUST NOT silently expand: it is handled per the declared snapshot or dynamic-query basis, and expanding the scope requires obtaining the user's decision again.

Design applicationPresent "how much will change" and "whether it can be undone" as two pieces of information at the command's entry point, not as two lines inside a confirmation dialog. When the count affects an important judgment and has not been verified, verify it first or narrow it to a known scope; present a lower bound with uncertainty only when it does not affect an important judgment.

Verification examples

• User side: for every irreversible operation, check whether the user can state how many objects will be affected and whether it can be undone before pressing.
• Implementation side: check whether the affected count shown in the interface and the count actually executed come from the same computation.

CounterexamplesUnder-delivery — only after clicking "Clear cache" does the user discover that the login state and local drafts were wiped along with it; over-delivery — an "impact scope preview" page is inserted before every operation, so even changing a title requires reading a summary first.

Basis and referencesMaking an operation's consequence assessable before execution is a basic requirement for narrowing the "gulf of execution" and the "gulf of evaluation" (R03); requiring that important irreversible operations be undoable, verifiable, or confirmable has a corresponding written requirement in accessibility standards (R07).

UI2-2Undo takes priority over confirmationMUST¶

In one sentence: Low-consequence actions use undo to reduce interruption; consequential actions still need proportionate confirmation.

Applies toProducts that offer operations capable of changing system state.

RuleUndo capability MUST be provided by default for recoverable state changes; when it is not provided, this MUST be explained category by category per the boundary conditions below. For low-consequence operations with reliable, acceptable-cost recovery, undo SHOULD replace repeated confirmation, and confirmation MUST NOT be stacked on top of it without a clear benefit (see gui.reversibility.undo.mode, confirm.level). "Technically undoable" does not by itself cancel the confirmation requirement: when any of the following holds, a confirmation proportionate to the consequence may be kept in addition to undo capability, with the reason recorded — obtaining necessary authorization is required, a significant cumulative impact exists, recovery cannot cover the entire consequence (others have already been notified, an external process has already been triggered), or the mistaken action itself causes a significant interruption. The undo entry MUST be reachable after the operation completes, and its reachability MUST NOT depend on a notice that disappears automatically (see UI3-6). When an operation with an external side effect has an undo that may be time-limited, that time limit MUST be disclosed (see gui.reversibility.undo.ttl). Categories of operation that do not offer undo MUST have their reason recorded category by category; "implementation cost is high" MUST NOT serve as the sole reason without a recorded consequence assessment.

Boundary conditionsFor temporary navigation with no meaningful recovery result, or operations limited by an unrecoverable consequence, undo may be omitted, but the consequence and a feasible remedy MUST be explained; pure implementation cost does not constitute an exemption. This rule does not require undo to be infinitely deep or to last forever, nor does it require undo to cover side effects that have already gone out and cannot be recalled (an email already delivered, a payment already cleared, a notification already pushed to someone else's device) — those cases are handled under UI2-6. This rule does not prohibit confirmation: confirmation for irreversible operations is specified by UI2-4. Security-sensitive re-verification (re-entering a password before a transfer) and confirmation that obtains necessary authorization are not the "repeated confirmation" this rule aims to reduce, and are not bound by it.

Design applicationImplementing deletion as "mark first, clean up later" trades a cleanup window for undo capability — this is the most common way of turning the irreversible into the reversible. At the same time, note: the existence of an undo window is not a reason to withhold the consequence from the user — UI2-1 still applies.

Verification examples

• User side: across all delete-type operations in the product, tally how many offer undo and how many only offer confirmation.
• Implementation side: check whether the conditions under which the confirmation dialog appears match the irreversible.actions list; for confirmations layered onto undoable operations, check the risk and authorization rationale item by item — only repeated confirmation with no clear benefit violates this rule.

CounterexamplesUnder-delivery — a confirmation pops up every time a single email is deleted, and there is no undo after deletion; over-delivery — "undo takes priority" is read as meaning no operation needs any prompt at all, so account deactivation and overwriting a data export are executed directly too.

Basis and references"User control and freedom" requires leaving a clear exit for mistaken actions, and undo is the typical implementation of that heuristic (R04); platform guidelines treat undo as a routine interface capability rather than an exceptional one (R10).

UI2-3Undo boundaries align with the user's mental modelMUST¶

In one sentence: One undo reverses the one step the user thinks they took.

Applies toProducts that provide undo capability.

RuleOne undo MUST correspond to one operation the user can identify; splitting one user operation into multiple undos MUST NOT occur, and merging multiple user operations into one undo without notice MUST NOT occur (see gui.reversibility.undo.granularity). An internal transaction may have multiple steps, but it MUST NOT be exposed as multiple required undos; when two operations are genuinely initiated separately by the user, they MUST be recorded as two operations rather than treated as an exception to "one operation." The scope of an undo MUST be resolvable (the current view, the current document, the current session, or a larger range), and its boundary MUST be predictable to the user (see gui.reversibility.undo.scope). When the undo stack is shared across views, documents, or users, that shared scope MUST be disclosed. Undo and "back navigation" are two different things; the same entry point MUST NOT carry both meanings at once. When concurrent editing is involved, undo MUST revert only that operation's own contribution; when the ownership of a change cannot be confirmed, it MUST first be verified and the conflict explained — overwriting someone else's or the user's subsequent valid edits with a whole snapshot MUST NOT occur.

Boundary conditionsThis rule does not specify the depth of the undo stack, nor does it require undo to persist across sessions. Merging consecutive micro-operations of the same kind (consecutively typed characters, the intermediate frames of a continuous drag) into one step conforms to this rule, because the one operation the user identifies is already "typed this sentence," not "pressed seventeen keys."

Design applicationWhen defining the undo unit, go by "how the user would describe what they just did," not by internal transaction boundaries. One drag-and-drop involves two internal changes, a deletion and an insertion, but it is one step for the user (see UI6-4).

Verification examples

• User side: after performing one compound operation, press undo once and check whether the interface returns to the state before the operation, not to an intermediate state.
• Implementation side: check the correspondence between the undo stack's push unit and the user's operation; check which view an undo acts on after a cross-view operation.

CounterexamplesUnder-delivery — "applying a template" once takes twenty undos to reverse, and it stops at half-finished states along the way; over-delivery — every operation in an entire session is merged into a single undo step, so a user who only wanted to revert the last change loses an hour of work.

Basis and referencesUnderstanding undo as "a user intent that needs to be supported," rather than a system command waiting to be implemented, is an established claim in this field; a small-sample study reported that participants preferred an undo model that considers dependencies between operations — for the limitations of its sample, tasks, and response method see reference.md (R06).

UI2-4Irreversible operations are tiered by consequenceMUST¶

In one sentence: Confirmation strength is decided by consequence, not by the number of dialogs.

Applies toOperations that cannot be undone once executed, or whose undo cannot cover the entire consequence.

RuleIrreversible operations MUST be listed in the irreversible-operations list with their consequences stated (see gui.reversibility.irreversible.actions); the strength of their confirmation MUST be proportionate to the severity of the consequence (see gui.reversibility.confirm.level). Confirmation MUST restate the specific consequence and the affected objects; a question with no consequence information, such as "are you sure you want to continue," MUST NOT serve as confirmation, and increasing the number of confirmation steps MUST NOT substitute for increasing the information content of a single confirmation. When the consequence is significant and irreversible, the user SHOULD be required to make an active input bound to that operation (typing the object's name, checking off specific consequence items), so that confirmation cannot be passed through unconsciously.

Boundary conditionsThis rule does not specify which confirmation tier corresponds to which category of operation — that is decided and recorded by the product based on a consequence assessment. This rule does not require every irreversible operation to have an active-input requirement; imposing high-strength confirmation on a low-consequence irreversible operation is the "over-delivery" side of this rule's counterexample. Specific situations involving law, finance, or data submission have their own written requirements for reversibility, verifiability, or confirmability (see reference.md Section 3); this rule does not replace the compliance judgment for that requirement.

Design applicationWhen writing confirmation copy, write "what will happen once it's done, what cannot be recovered" first, then decide which interaction tier that statement needs. Clicking "OK" twice in a row won't make the user think any more clearly; saying once, clearly, "this will permanently delete 1,284 records, including 12 referenced by other people" will.

Verification examples

• User side: for each irreversible operation, check whether the confirmation step states the specific consequence and the number of affected objects.
• Implementation side: check whether the confirmation tier corresponds one-to-one with the consequence rating in the irreversible-operations list; find items where the tier and the consequence don't match.

CounterexamplesUnder-delivery — "Delete workspace" only pops up "are you sure?", and clicking through wipes out every member's data at once; over-delivery — deleting a single draft also requires typing the workspace name, and the user quickly learns to skip reading the dialog and just copy-paste.

Basis and referencesFor important operations involving law, finance, and data submission, written standards require providing one of undoable, verifiable, or confirmable (R07); error prevention taking priority over error messages is an established item in heuristic evaluation (R04).

UI2-5Destructive actions are not set as the default executionSHOULD¶

In one sentence: A slip of the hand shouldn't land exactly on the most severe option.

Applies toConfirmations, menus, and action areas that contain a destructive option.

RuleA destructive action SHOULD NOT be the default focus, the default button, or the default target of the Enter key (see gui.reversibility.destructive.default); replacing a safe action at the same position with a destructive one during a sequence of operations with no warning — so that repeated clicking or leftover input directly executes the destructive consequence — MUST NOT occur. The destructive entry point and the commonly used entry point SHOULD be separated in space, or require a different action sequence than the common action.

Boundary conditionsThis rule does not require hiding the destructive action — being hard to find and being easy to trigger by accident are two different failures. When a destructive action is the sole action in a context where its meaning is unambiguous (the only button on a dedicated "delete account" page), the requirement for spatial separation does not apply.

Design applicationCheck for position overlap along a sequence of operations: if the previous step's "Next" button and this step's "Delete all" button land at the same coordinates, the user's hand will stay still between the two clicks.

Verification examples

• User side: press Enter immediately when a confirmation dialog appears, and check whether a safe action or a destructive one occurs.
• Implementation side: check the default focus position of every confirmation dialog; tally interfaces where a destructive action's coordinates overlap the previous step's primary action.

CounterexamplesUnder-delivery — the default button on a delete confirmation is "Delete," and Enter executes it directly; over-delivery — the delete entry is buried three menu levels deep plus a search, making routine cleanup work impossible to complete.

UI2-6Undo failure is reported truthfully with a remedyMUST¶

In one sentence: Don't say it's undone if it isn't.

Applies toProducts where undo may partially fail or may not cover the entire consequence.

RuleWhen undo is incomplete or only partially completed, the system MUST truthfully state which part could not be undone and why, and MUST provide an executable remedy (see gui.reversibility.undo.failure.mode); presenting "undone" when the undo has not actually completed MUST NOT occur. Side effects that have already gone out and cannot be recalled (a message already delivered, a third-party call already triggered, a reminder already notified to someone else's device) MUST NOT be represented as recalled merely because the interface's state reverted. The content of undo-failure information is handled per UI3-5.

Boundary conditionsThis rule does not require the system to be able to undo everything; what it requires is that the statement of "to what extent it was undone" be consistent with the facts.

Design applicationTreat the result of the undo itself as an operation whose stage and result are handled separately (UI3-2), rather than as an interface rollback that is bound to succeed.

Verification examples

• User side: perform an undo under a network-interruption condition, and check whether the interface shows "undone" or "could not be undone, with the reason and next step."
• Implementation side: inject a response where the downstream service refuses to roll back, and check whether the local state has already reverted while the outward statement still claims it was undone.

CounterexamplesUnder-delivery — after undoing a send, the interface shows "recalled," but the notification is still on the recipient's device; over-delivery — because undo might fail, a "this undo may not fully take effect" notice pops up before every single undo.

Basis and referencesLocal state rollback and the recall of an external side effect are two different things; this distinction holds equally in the engineering practice of optimistic updates (R13, R14).

3.3 UI3 State and feedback are visible¶

This principle governs the system's response to an operation. Its core claim is that stage and result are kept separate: input received, executing, and processing finished answer "how far along is it"; success, failure, partial success, and unknown answer "what is the result based on." Merge them into a single loading animation, and the user can no longer tell "it didn't hear me" apart from "it's working on it" apart from "it finished but nothing changed." This principle also governs something increasingly common in modern interfaces: the interface changes first, the server confirms later — there is nothing wrong with this approach in itself; the problem is when the interface quietly reverts after a failure while the user believes the thing has already gone through.

UI3-1An accepted operation has immediate feedbackMUST¶

In one sentence: First let the person know "it heard me."

Applies toOperations whose result is not visible at the same moment the operation occurs.

RuleThe fact that an operation has been accepted by the system MUST have perceptible feedback, and this feedback MUST appear in a location the user can currently discover (see gui.feedback.ack.mode, placement). Acceptance feedback MUST NOT be represented as completion: it promises only that "the input has been received," not the result. The upper bound on feedback latency is determined and recorded by the product based on the target scenario and population; these guidelines give no number.

Boundary conditionsWhen the operation's result is itself immediately visible and cannot fail (toggling a purely local expanded state), the result itself is the feedback, and no additional acceptance expression is needed. This rule does not require an independent visual feedback element for every click — a state change in place is sufficient. Status messages MUST be perceivable by assistive technology, and ordinary progress updates MUST NOT steal input focus; high-frequency progress SHOULD be coalesced into a single announcement, and failure states or states requiring user action MUST NOT be lost in that coalescing (see gui.feedback.announcement.policy).

Design applicationPlace acceptance feedback where the user's hand is (on the element that was clicked), not in a corner of the screen. An operation that takes effect in a different region needs feedback in both places: where the action was taken and where it takes effect.

Verification examples

• User side: operate under artificially added network latency, and check whether the user clicks repeatedly because of "no response."
• Implementation side: tally how often the same operation is resubmitted within a short time; a high repeat rate indicates missing or invisible acceptance feedback.

CounterexamplesUnder-delivery — after clicking submit, the interface shows absolutely no change, so the user clicks five times in a row and produces five records; over-delivery — every click triggers a full-screen overlay loading animation, so even switching tabs requires a wait.

Basis and referencesThe classic tiering of response time and user perception (the order-of-magnitude differences around 0.1 second, 1 second, and 10 seconds) is often used as a reference starting point for feedback design (R05); for the assistive-technology presentation of status messages see R20; these guidelines do not transcribe these numbers into universal thresholds — product-specific values must be determined independently.

UI3-2Stage, result, and unknown are each distinguishableMUST¶

In one sentence: Received does not equal completed, and no result received does not equal failed.

Applies toOperations involving asynchronous execution, background processing, or an external call.

RuleThe operation's stage and its result are expressed separately. Stage is distinguished, according to capability, into locally received, queued, executing, and ended, with an additional stage-unknown state retained; result is distinguished into pending, success, failure, partial success, canceled, and unknown. Not yet settled but normally trackable counts as pending; unable to confirm the fact counts as unknown. Each of these meanings MUST be distinguishable (see gui.feedback.states). Using the same presentation to express two or more of these meanings at once MUST NOT occur, and inferring success from "no error reported" MUST NOT occur. They may share the same interface location, but the meanings MUST NOT be merged.

When the basis for a result cannot be obtained, "unknown" MUST be retained with a path to verify it provided: a request timeout, a lost response, or a dropped connection does not by itself imply success or failure — rewriting unknown as "failed" or "not yet submitted" MUST NOT occur, nor may completion be inferred from a timer. Under what conditions a retry is safe (whether it's idempotent, whether anti-duplication protection already exists) MUST be declared separately; automatic resending MUST NOT occur when this has not been declared.

Boundary conditionsThis rule does not require an independent visual component for every state; a single status label switching between values is sufficient, and it does not require every interface to display every dimension. This rule does not apply to purely local operations whose result is synchronously visible and cannot fail — such operations are recorded as "not applicable" under gui.feedback.states with the rationale stated.

Design applicationWrite stage, result, and factual basis into the state model first, then design the presentation. The state most often missing in engineering implementations is "accepted but not yet started" — the request has been sent but the queue has not yet processed it, and at this point the interface usually shows nothing at all.

Verification examples

• User side: construct three separate cases — slow success, fast failure, and long-term queuing — and check whether the interface presentation is distinguishable among them.
• Implementation side: check whether the state machine expresses stage and result separately, and whether the result includes an "unknown" value; check for the existence of a "timeout counts as success" or "timeout counts as not submitted" branch; check whether automatic resending occurs under the unknown state.

CounterexamplesUnder-delivery — an upload interface only has "spinning" and "not spinning"; after a failure the spinner just stops, and the user thinks it finished; over-delivery — an independent component is designed for every state, and the interface for a simple operation is filled up with state explanations.

Basis and references"Visibility of system status" is the first item in the heuristic checklist, requiring that users know what's happening within a reasonable time (R04); platform guidelines offer separate presentation recommendations for in-progress and completed feedback (R10, R11, R12); for the mechanism boundaries of lost responses and safe retry see R21.

UI3-3In-progress states give decision-relevant informationSHOULD¶

In one sentence: Whether it can be canceled and whether to keep waiting matter more than the progress bar itself.

Applies toOperations whose duration may exceed the user's expected waiting time.

RuleAn in-progress operation SHOULD provide information that supports the user's decision-making: whether it can be canceled, whether it blocks other operations, and how much remains or whether the remaining amount is unknown (see gui.feedback.progress.info). Faking a completion percentage with a looping animation or a timer MUST NOT occur, and presenting a cancel entry when cancellation is not actually possible MUST NOT occur. When a completion percentage cannot be given, truthfully presenting "remaining amount unknown" is preferable to giving an estimate that doesn't hold up. An indeterminate-progress animation may express that the wait continues, but it MUST NOT be read as a completion percentage. A cancelable operation MUST distinguish cancel request received, cancellation in effect, and result pending verification; the portion already completed MUST retain its receipt and MUST NOT be erased by "canceled." Cancellation itself is handled per UI3-2's stage, result, and unknown.

Boundary conditionsThis rule does not require precise progress for every time-consuming operation. The threshold for "expected wait" is determined and recorded by the product based on the target scenario and population; these guidelines give no number.

Design applicationDuring a wait, the user usually has only three decisions to make: keep waiting, go do something else, or cancel. The progress bar only serves the first one; the other two need "whether it's blocking" and "whether it can be canceled."

Verification examples

• User side: attempt other operations while a long-running operation is in progress, and check whether the interface states the scope of blocking.
• Implementation side: check which incomplete actions cancellation actually stops; when cancellation and completion arrive at the same time, the final verified result must be shown, not just the notice closed.

CounterexamplesUnder-delivery — a large file export only shows a single spinner, and the user doesn't know whether they can switch away, so they're stuck watching it; over-delivery — a full scan is done first just to show precise progress, doubling the wait time as a result.

UI3-4Optimistic updates must be rollback-able and the rollback visibleMUST¶

In one sentence: Showing it first and confirming later is fine; quietly reverting it after failure is not.

Applies toInterfaces that present the expected result to the user before server confirmation (optimistic updates).

RuleWhen adopting optimistic updates, the system MUST be able to roll the interface and local state back to a consistent state after a failure, and MUST let the user know which step did not succeed (see gui.feedback.optimistic.mode). Silent rollback MUST NOT occur: a result that once appeared on the interface disappearing after a failure with no explanation at all is a violation of this rule. The scope of applicability of optimistic updates MUST be declared — irreversible operations and operations that produce an external side effect MUST NOT be presented as completed via an optimistic update. The scope of state covered by rollback (the interface, local cache, derived counts and ordering) MUST be declared together with it.

Boundary conditionsThis rule does not object to optimistic updates — they are a reasonable approach for reversible operations with a low failure rate whose result is partially visible. This rule also does not require the rollback to restore the user's other input during that period verbatim: subsequent valid edits MUST be preserved. A concurrent request's failure reverts only that failed operation's contribution, or re-reads a trusted state and resolves conflicts against the preserved user input; overwriting a subsequent successful operation with an old snapshot MUST NOT occur. When the result is unknown, a pending-verification marker is retained rather than blindly rolling back as if it were a confirmed failure (see gui.feedback.concurrency.policy).

Design applicationSeparate "the optimistically presented state" from "the confirmed state" at the data layer, so the interface can express "this one is not yet confirmed." The presentation after a failure SHOULD preserve the user's intent (a retry entry, the edited content), rather than restoring the interface to look as if the user never acted at all.

Verification examples

• User side: perform the operation under an offline or server-rejected condition, and check whether the interface presents success and then silently reverts, or explicitly reports the failure.
• Implementation side: check whether the failure branch covers every derived state (list counts, sort position, unread counts), not just the primary object.

CounterexamplesUnder-delivery — clicking "like" immediately increments the count, and after the request fails the number quietly decrements back, leaving the user thinking their like went through; over-delivery — out of fear of failure, every operation waits for server confirmation before presenting anything, so even local sorting and collapsing has to wait for a round trip.

Basis and referencesMainstream data-layer libraries treat "rolling back to the prior state after failure" as a component of optimistic updates, not an optional addition (R13, R14); these documents describe the mechanism's existence and usage, and do not prove whether any given product should or should not adopt optimistic updates.

UI3-5Failure can be traced to the object and the reasonMUST¶

In one sentence: If three out of twenty failed, it must say which three.

Applies toOperations that may fail, especially batch operations acting on multiple objects.

RuleFailure information MUST include the affected object, the reason for the failure, and an executable next step (see gui.feedback.failure.content). When acting on multiple objects, results MUST be reported per object, and an overall conclusion MUST NOT mask a partial failure (see gui.feedback.batch.result.granularity). A partial-success situation MUST be explicitly presented as a partial success, stating what portion has taken effect and whether it can be reverted. Whether a retry is safe (whether it would produce a duplicate side effect) MUST be knowable; a retry MUST preserve the identity of the same operation, act only on objects verified as unsuccessful, and repeating execution on items that already succeeded MUST NOT occur (see gui.feedback.retry.policy).

Boundary conditionsThis rule does not require exposing internal error codes or stack traces to the user. The granularity of the reason is governed by "the user can decide the next step based on it"; when the specific reason genuinely cannot be disclosed for security reasons, this MUST be stated along with a path to seek help, rather than giving a reason that doesn't hold up.

Design applicationOrganize the presentation of a batch operation's result by "how many succeeded, how many failed, which ones failed, how many categories of failure reason," and let failed items be reselected and retried.

Verification examples

• User side: construct a batch operation where 3 of 20 items fail, and check whether the user can find out which 3 and why.
• Implementation side: check whether the batch interface's return value preserves per-item results; check whether the interface collapses per-item results into a single conclusion.

CounterexamplesUnder-delivery — after a batch import completes, it only shows "some records failed to import," with no way to locate them at all; over-delivery — a separate dialog pops up for every single failed item, so 20 failures means 20 dialogs.

Basis and referencesHelping users recognize, diagnose, and recover from errors is an independent item in the heuristic checklist, requiring the problem to be stated in understandable language along with a constructive next step (R04).

UI3-6How long feedback persists does not constitute a deadline for actingSHOULD¶

In one sentence: The undo entry shouldn't disappear along with the toast.

Applies toProducts that use an automatically dismissing notice to carry operation feedback.

RuleHow long an automatically dismissing notice persists SHOULD NOT become the deadline by which the user must complete a follow-up action; entries such as undo, retry, and view details MUST NOT exist only within a notice that dismisses itself automatically (see gui.feedback.notice.duration). How long a notice persists is determined and recorded by the product based on the target population's reading and action time; these guidelines give no number. Feedback carrying failure information SHOULD NOT dismiss itself automatically, unless the same information remains reachable elsewhere.

Boundary conditionsThis rule does not prohibit an automatically dismissing notice — it is appropriate for successful, low-consequence operations. This rule also does not require the undo entry to be permanently on screen: placing it, at the same time, in a persistent location (operation history, the edit menu, the object's own state) satisfies this rule.

Design applicationTreat the notice as a channel for "announcing that this happened," and treat undo as a capability for "this can be reverted"; implement the two separately. The capability not disappearing along with the notification is the entirety of this rule.

Verification examples

• User side: perform an undoable operation, wait for the notice to disappear, and check whether it can still be undone.
• Implementation side: check whether the lifecycle of the undo capability is bound to the notice component.

CounterexamplesUnder-delivery — the "deleted, undo" notice after a deletion disappears after 4 seconds, and by the time the user reacts there's no entry left; over-delivery — every operation leaves behind a notice that never disappears, and the screen piles up with a dozen historical notifications.

3.4 UI4 Input methods are on par¶

This principle governs which input methods a product declares support for, and whether those declarations are fulfilled. Its core claim is: the criterion for parity is whether the task can be completed, not whether the gesture can be reproduced. There is no hover on a touchscreen, no coordinates on a keyboard, no precise pointing on a gamepad — requiring them to imitate each other's actions gets parity backwards. This principle also governs keyboard and assistive-technology reachability, focus flow, target areas, and pointer cancellation, to keep "supporting an input method" from remaining a mere capability declaration.

UI4-1Core tasks can be completed under every declared-supported input methodMUST¶

In one sentence: What must be on par is the task, not the gesture.

Applies toProducts that declare support for multiple input methods.

RuleThe product MUST declare its input methods and core task list (see gui.input.methods, core_tasks). Each input method is recorded separately as full support or limited-scope support: full support MUST be able to complete every core task; limited-scope support MUST list the subset of tasks it can complete, the gaps, and the alternative paths, and MUST NOT claim full parity. Substituting simulated mouse coordinates or a single gesture for task-completion verification MUST NOT occur.

Core tasks cover at least the product's main outcomes, along with the create, select, modify, submit, recover, and exit steps needed to reach that outcome; when a capability is not provided, the rationale MUST be recorded, and a task MUST NOT be deleted merely to mask a channel gap. Explicitly applicable requirements such as keyboard operability and single-pointer drag alternatives are still covered per their actual functional scope, and cannot have their scope narrowed by the support tier or the core task list.

Boundary conditionsThis rule does not require support for every input method; the scope of declared support is decided by the product. This rule also does not require equal efficiency across input methods — the path length may differ, but the task MUST be completable. A product designed specifically for a particular input (a drawing tablet's pressure-sensitivity feature, a motion-based game's action input) may exclude that capability from the core task list with a stated reason.

Design applicationWrite the core task list first, then walk through the complete path for each input method one by one. This list is the task-verification basis for this rule — without it, "supports keyboard" is just an unfalsifiable statement.

Verification examples

• User side: unplug the mouse, walk through the core task list with only the touchscreen, and again with only the keyboard, recording which tasks cannot be completed.
• Implementation side: check whether the core task list exists and resolves to concrete tasks, rather than being written up as "main features."

CounterexamplesUnder-delivery — a value can only be set by dragging a slider into position, so keyboard users cannot enter it; over-delivery — a separate interface is built for every input method, maintaining four copies of the same feature, whose behavior gradually diverges.

Basis and referencesInput-method-independent operation paths have corresponding items in both accessibility standards and multi-platform guidelines (R07, R08, R12).

UI4-2Hover and context menus are not the sole entry pointMUST¶

In one sentence: There's no hover on a touchscreen — those features can't simply disappear because of that.

Applies toInterfaces that carry a feature's entry point via hover reveal, a right-click menu, or a long-press menu.

RuleInformation and operations necessary to complete a core task MUST NOT exist only in a hover state or a context menu (see gui.input.hover.role, context_menu.role). Hover and context menus may serve as shortcut channels, but a discoverable equivalent entry point that requires neither hovering nor right-clicking MUST exist; a permanently present "more actions" button is sufficient, and every command does not need to be laid out flat. Supplementary information carried by hover (an explanation, a preview, the full text) MUST have a reachable equivalent presentation under an input method without hover capability.

Boundary conditionsThis rule does not prohibit hover effects, nor does it prohibit right-click menus — they are efficient on pointing devices. What this rule constrains is "exclusivity": compliant as an accelerator, non-compliant as the sole path. Purely decorative hover feedback is outside the scope of this rule. Author-supplied hover or focus supplementary content SHOULD be dismissible, allow the pointer to move into it to read it, and remain while the user still needs to read it; the dismiss mechanism may be omitted only under applicable exceptions such as content that does not obscure or replace other content, or error messages.

Design applicationTreat the context menu's contents as a copy of the permanent entry point, not its substitute. The check during design review is simple: turn off both hover and right-click, and see whether the core task can still be completed.

Verification examples

• User side: walk through the core task completely on a touchscreen device, recording which features have no findable entry point.
• Implementation side: list every command triggered only by hover or right-click, and check each one for a permanent equivalent entry point.

CounterexamplesUnder-delivery — renaming is only available through the right-click menu, and a touchscreen long-press is already claimed by a system gesture, so the feature is effectively unavailable on mobile; over-delivery — every right-click menu item is laid out flat on the toolbar, cramming it with dozens of icons.

UI4-3Switching input method does not reset working stateMUST¶

In one sentence: Put down the mouse, pick up the keyboard — the selection and draft are still there.

Applies toProducts where multiple input methods on the same device may be used interchangeably.

RuleWhen the user switches input method within the same session, the selection, drafts, scroll position, expanded/collapsed state, and any in-progress operation MUST be preserved (see gui.input.switch.preserved); resetting these states because the input method changed MUST NOT occur. When a change in input method causes a change in interface form (density adjustments in touch mode), the requirement to preserve state holds equally. When the layout changes, the reading position is preserved by the same content anchor; this rule does not require mechanically preserving the scroll position in pixels.

Boundary conditionsThis rule does not require cursor position or hover focus to persist across input methods — those are transient states tied to the device. This rule also does not prohibit adjusting presentation density or control size when the input method changes. "Having notified the user that state was reset" does not satisfy this rule: notification is necessary, but it does not discharge the obligation to preserve state; when preservation is genuinely impossible, the product MUST NOT declare that it supports the coexistence of multiple input methods (see UI4-1, UI4-5).

Design applicationSeparate working state (selection, drafts, position) from device state (pointer position, hover object) at the data layer. When the two are mixed together, switching input method will sweep away the working state along with it.

Verification examples

• User side: on a 2-in-1 device, switch from touchscreen to keyboard and mouse, and check whether the selected objects and unsubmitted input are still there.
• Implementation side: check whether the logic handling an input-method change triggers a view rebuild; check whether that rebuild preserves the selection and drafts.

CounterexamplesUnder-delivery — after selecting a dozen files on a tablet and then attaching a keyboard, the interface switches to desktop mode and the selection is cleared; over-delivery — in order to preserve state, control size is never adjusted at all when the input method changes, leaving hit areas too small for touch.

UI4-4Target area and precision requirements are measurableMUST¶

In one sentence: What is measured is the area that can actually be hit, not just how big the icon looks.

Applies toProducts that provide pointing input (mouse, touch, pen, remote pointer).

RuleThe minimum target-area size, spacing requirements, and their exceptions for operable elements MUST cite an existing accessibility standard or design-system rule and resolve to that source (see gui.input.target_size.ref); size MUST be measured by the actual hit area, and the unit, input method, source, and exceptions MUST be recorded; using the icon's visual boundary directly as target-area evidence MUST NOT occur. Precision differences across input methods MUST be reflected in the target-area decision, rather than requiring the user to improve their operating precision.

Boundary conditionsWhen a web pointer target adopts WCAG 2.5.8 (AA), the judgment uses 24×24 CSS px or its explicitly stated spacing, equivalent control, inline, user-agent-controlled, and essential exceptions; this is not a comfortable-size recommendation for every platform. CSS px, pt, and dp are not interchangeable. A product may increase the size based on input precision, but MUST NOT substitute a smaller, self-set value for the applicable minimum. The exception clauses in an existing standard (inline elements, equivalent controls, user-agent default styling, functional necessity) MUST NOT be dropped when citing it.

Design applicationWrite the target-area rule as a single citable source, annotated with the standard clause it is based on and its exception conditions, rather than writing a separate number into every component.

Verification examples

• Implementation side: measure the actual target area, covering edge clicks, adjacent hit areas, and zoom; when using the spacing exception, check that a 24 CSS px diameter circle centered on a small target does not intersect the corresponding circle of another target or another small target.

CounterexamplesUnder-delivery — a mobile icon button is only about a dozen pixels square, with no size rationale at all; over-delivery — every element is uniformly enlarged to a single minimum, ignoring the equivalent-control and inline exceptions the standard allows, and information density drops sharply.

Basis and referencesThe minimum target-area size and its exceptions have written clauses in current accessibility standards (R07); platform design guidelines have their own recommended values and applicability conditions (R10, R11, R12). These guidelines only cite them and do not trim their exceptions.

UI4-5Differences in input capability are disclosed, not silently degradedSHOULD¶

In one sentence: If it can't be done, say so, and give another way.

Applies toProducts where some feature genuinely cannot be implemented at parity under certain input methods.

RuleWhen a feature is limited under a particular input method, that limitation SHOULD be disclosed, along with an executable alternative path (see gui.input.capability.gaps); giving no explanation when a feature is unavailable, and simply letting the entry point disappear or the click do nothing, MUST NOT occur. The capability-gap list SHOULD record, item by item, the limited input method, the limited feature, the alternative path, and the reason for the limitation.

Boundary conditionsThis rule does not require eliminating every difference — some differences come from the device itself (a device without pressure sensing cannot implement pressure-sensitive input). What this rule requires is that the difference be stated, and not presented by silently disappearing.

Design applicationMaintain this gap list in the capability description and help content, and keep it sourced from the same place as the actual implementation, to avoid the documentation and the product telling different stories.

Verification examples

• User side: access the feature under the limited input method, and check whether an explanation and an alternative path are given.
• Implementation side: check whether the gap list is empty; an empty list MUST be backed by an actual verification record, not by never having been checked.

CounterexamplesUnder-delivery — the handwritten-annotation feature's entry simply doesn't display on a device without a pen, and the user thinks the product doesn't have this feature at all; over-delivery — a banner reading "some features are limited under the current input method" is permanently displayed at the top of every page.

UI4-6The graphical layer does not block keyboard and assistive-technology pathsMUST¶

In one sentence: Custom controls and drag-and-drop implementations must not seal off the path.

Applies toGraphical interfaces that provide operable controls, overlays, or dynamic content.

RuleExcept for functionality whose input path is itself irreplaceable, interface functionality MUST be operable by keyboard. Controls MUST expose an accessible name, role, value, and state; a visible label SHOULD be included in the accessible name. The graphical layer MUST NOT break the platform's existing access paths. Keyboard focus MUST be visible, follow an order consistent with task logic, and MUST NOT be completely obscured by author-created content; the user MUST be able to enter and leave an operating region (see gui.input.keyboard.policy, focus.policy).

Once a modal dialog opens, focus MUST move to an appropriate position within it, Tab traversal MUST stay inside the dialog, and the background MUST NOT continue to be operable; a reachable cancel or close entry MUST be provided. After closing, focus returns to the trigger; when the trigger no longer exists, it moves to a position appropriate to the next task. A non-modal overlay MUST NOT trap focus without reason. After a row is deleted, a virtual list recycles a node, or content is refreshed, focus MUST land on an explainable subsequent position; silently falling back to the top of the page MUST NOT occur.

A custom control may take over the keys needed to implement that pattern, but it MUST preserve the paths for entering, exiting, and text editing. A single-character shortcut MUST be able to be turned off, changed to a key combination, or made to take effect only while the corresponding control is focused; a global shortcut MUST NOT intercept text input, IME candidate selection, or platform-reserved commands.

Boundary conditionsThis rule does not require an accessibility compliance assessment to be completed within the scope of these guidelines, nor does it replace that assessment. This rule does not prohibit the use of canvas or custom-drawn rendering — it requires that such implementations be accompanied by an equivalent access path.

Design applicationMake "which existing interaction pattern this custom control corresponds to" part of the design deliverable. Existing interaction-pattern guidance gives a systematic set of keyboard interaction conventions for common patterns (grid, tree, listbox, dialog), which can serve as a design reference (see reference.md Section 3).

Verification examples

• User side: traverse an interface containing custom controls using only the keyboard, and check for regions that cannot be entered or cannot be left.
• Implementation side: check the complete task path with keyboard and screen reader, where focus goes on modal open/close, and the stability of the focused object in a virtual list; compliance cannot be judged merely by whether an event-interception method was called.

CounterexamplesUnder-delivery — a custom-drawn table control is skipped entirely during keyboard traversal, so its internal cells cannot be reached; over-delivery — a role annotation is added to every decorative element just to satisfy a testing tool, and assistive technology reads out a flood of meaningless information.

Basis and referencesThe keyboard conventions and role semantics of common interaction patterns are systematically described in public interaction-pattern guidance (R08, a non-normative guide, not used as a basis for compliance judgment); for the minimum requirement on focus obscuring see R20.

UI4-7Pointer actions can be canceled before commitMUST¶

In one sentence: A wrong press can be moved off; releasing shouldn't lock in the mistake.

Applies toClick, touch, pen input, and long-press actions as interpreted by the product.

RuleThe semantics of press, move, release, and cancel events MUST be declared (see gui.input.pointer.policy). An ordinary button SHOULD adopt the platform's activation event, executing when released over a valid target; if the pointer moves off the target after pressing and is then released, it MUST NOT execute. When adopting an interaction that takes effect on press, a corresponding release-reversal, cancel-before-completion, or undo-after-completion mechanism MUST be provided, or the reason the moment of pressing is itself irreplaceable MUST be recorded. Implementing accidental-touch protection as only a visual pressed state while the business action has already been submitted MUST NOT occur.

Boundary conditionsFunctionality that depends on the exact timing of a press, such as a musical keyboard, may adopt immediate triggering. Sustained press and drag-and-drop each have their own completion boundary, and cannot be uniformly replaced by a button's move-off logic; the specific behavior MUST match the feedback visible to the user. Input behavior provided by the platform itself and left unmodified by the product is verified against the platform's own contract.

Design applicationPrefer the native button's activation mechanism. Within the drag threshold it remains a candidate click; once the threshold is crossed into a drag, a click MUST NOT be additionally dispatched afterward; a scroll gesture MUST NOT incidentally trigger a card action.

Verification examples

• User side: press and hold the delete button, move off and release; long-press and then cancel; press and then start scrolling — none of these should accidentally submit.
• Implementation side: inject pointer cancel, focus loss, and a click event after a drag, and check that the same action is not activated more than once.

CounterexamplesUnder-delivery — the moment a finger touches the delete button it deletes, too fast to move off in time; over-delivery — every click requires a long press or a second confirmation.

Basis and referencesThe W3C's pointer-cancellation clause and its accompanying explanation give the boundaries for release, reversal, and essential cases (R17).

3.5 UI5 Entered data is a kind of promise¶

The things a user types, checks, uploads, or drags into the interface but has not yet submitted are a special category of object: they carry work the user has already invested, but the business submission has not yet completed. This principle governs exactly this span of time — "already spent, not yet landed" — whether the thing will be lost, when to tell the user they got it wrong, whether they know how to fix it once told, whether they must retype everything after a failed submission, and what exactly the words "already saved" promise. Failures in this domain are mostly unremarkable — they just make someone redo the work; but redoing the work is the most common point of user churn for this category of product.

UI5-1Unsubmitted content is not lost because of the system's own behaviorMUST¶

In one sentence: What a person has written shouldn't be swept away by a refresh.

Applies toProducts that allow the user to enter multi-field content, long text, or uploaded content.

RuleContent the user has entered but not yet submitted MUST NOT be lost because of behavior on the system's side — including automatic refresh, session expiry, token renewal, layout switching, background updates, navigation, and a reload not initiated by the user. The system MUST declare its draft-saving policy and retention period (see gui.entry.draft.mode, draft.ttl); not saving a draft is a legitimate choice, but it MUST be disclosed before the user begins investing effort, not only after the loss has occurred. "Not saving drafts" limits the recovery promise after a crash, a close, or across sessions; it does not exempt this rule's prohibition on the system's own-side behavior — loss within the same session caused by automatic refresh, session expiry, token renewal, layout switching, or a reload not initiated by the user is not permitted under any draft policy.

Boundary conditionsThis rule does not require saving content the user has explicitly discarded, nor does it require saving across devices. For situations beyond the product's control, such as the device losing power or the process being terminated by the system, this rule requires a best effort to save and a truthful account at recovery, not an absolute guarantee. Fields that must not be retained for security or compliance reasons (payment credentials, one-time verification codes) may be excluded from the saved scope, with the reason listed for each.

Design applicationImplement "save draft" and "submit" as two independent paths, with the former not going through business validation. When a session expires, preserve the content first and then require re-login; upon returning, continue where the user left off, rather than returning to an empty form after logging in.

Verification examples

• User side: fill the form halfway, let the session expire, and check whether the content is still there after logging back in.
• Implementation side: during input, trigger a forced background refresh and a layout breakpoint switch, and check whether the entered content is preserved.

CounterexamplesUnder-delivery — after spending twenty minutes filling out a form, the token expires and it redirects to the login page, coming back blank; over-delivery — even content the user explicitly clicked "discard" on is restored, or a draft containing sensitive information is synced to the server long-term.

UI5-2Validation timing and error placement align with the input processMUST¶

In one sentence: Don't tell someone they got it wrong before they've finished writing.

Applies toProducts that validate user input.

RuleValidation timing MUST align with the input process (see gui.entry.validation.timing): judging a field as an error before the user has finished entering it MUST NOT occur, unless that input can already be judged wrong and cannot become correct with further input. An error MUST be locatable to a specific field (see gui.entry.error.placement); when multiple errors exist, it MUST be possible to reach the specific field from a summary, and that location MUST NOT depend on the user searching for it themselves. Field-level errors and submission-level errors MUST be distinguishable.

Boundary conditionsThis rule does not prohibit instant feedback — positive instant hints (password strength, remaining character count, format already satisfied) are not limited by this rule, because they do not announce an error. Leaving the field or an explicit completion signal is the primary basis for "finished entering"; a pause can only serve as a supplementary signal, and an IME composition process or a brief pause MUST NOT be judged as completion by itself. A displayed error SHOULD be cleared promptly once the correction holds; asynchronous validation MUST be bound to the content it validated, and a stale response MUST NOT re-mark a field that has since been modified.

Design applicationSeparate "this value is not currently valid" from "this value cannot possibly become valid." At the third character of typing an email address, the former holds but not the latter, so no error should be reported yet; when a disallowed character is entered, the latter holds, and an instant hint may be given.

Verification examples

• User side: type a value that is ultimately valid, character by character, and record how many times a red error appears along the way.
• Implementation side: check the trigger timing bound to each validation rule; find rules bound to every keystroke.

CounterexamplesUnder-delivery — the email field flags "invalid email format" in red the moment the first letter is typed, and only turns green on the last character; over-delivery — every validation is deferred until submission, so the user fills out fifteen fields and then gets eight errors at once.

Basis and referencesThe effect of validation timing and error locatability on form completion rates is under ongoing discussion in usability research and industry surveys (R15); these studies establish that the problem exists, and do not directly prove that any one trigger timing suits every form.

UI5-3Error messages explain how to fix themMUST¶

In one sentence: "Invalid format" doesn't tell anyone what to do.

Applies toProducts that report input errors to the user.

RuleAn error message MUST state where the error is, what the error judgment is based on, and how to fix it (see gui.entry.error.content); announcing only that an error exists with no executable direction for fixing it MUST NOT occur. Format normalization that is semantically unchanged and follows a reliable rule SHOULD be handled automatically, with the correction visible to and revertible by the user; content that could change in meaning — a name, an address, a code, a password — MUST retain its original value or let the user choose from suggestions, and MUST NOT be silently rewritten under the guise of formatting, rather than requiring the user to manually change it into the shape the system accepts. Error messages use language the user can understand; presenting an internal error code directly as the only information MUST NOT occur.

Boundary conditionsThis rule does not require disclosing the complete validation rule — for cases where it is inadvisable to explain for security reasons (the specific reason a login failed), a general explanation and a path to seek help may be given, with a statement that this is a deliberate limitation.

Design applicationWhen writing an error message, check it against three parts — "what — why — what to do" — and fill in whichever is missing. Thresholds in the rule (length, character set, value range) SHOULD be visible before the error occurs, not discovered through trial and error.

Verification examples

• User side: for each error message, check whether a user unfamiliar with the internal rule can fix it correctly on the first try based on it.
• Implementation side: tally the proportion of error copy that contains no direction for fixing it.

CounterexamplesUnder-delivery — "Invalid input"; over-delivery — pasting the complete regular expression and the internal validation rule's raw text for the user.

Basis and referencesThat error messages should state the problem in understandable language and offer a constructive solution is a written item in the heuristic checklist (R04).

UI5-4A failed submission preserves the content already enteredMUST¶

In one sentence: The system's failure shouldn't be paid for by the user retyping everything.

Applies toProducts with a submit action that may fail.

RuleOn a failed submission, the content the user has already entered MUST be preserved in full (see gui.entry.submit.failure.retain); clearing the form and requiring it to be refilled MUST NOT occur. Fields that must not be refilled for security or compliance reasons MUST be listed individually with the reason stated; every other field is preserved without exception. After a failed submission, it MUST be possible to correct or safely retry based on the preserved content; when the result is unknown, verify first; when it is permanently rejected, provide a path to correct it or seek help; whether a retry would produce a duplicate side effect MUST be knowable (see UI3-2, UI3-5). Uploaded or attachment content is equally covered by this rule after a failed submission; requiring re-upload of a portion that has already transferred successfully MUST NOT occur.

Boundary conditionsThis rule does not require preserving content beyond the product's control (the in-memory content after a browser crash); that is the responsibility of UI5-1's draft policy.

Design applicationDesign the interface for a failed submission as "continue where you were," not "back to the start": the error is located to a specific field, and the cursor can land directly where the fix is needed.

Verification examples

• User side: fill out the complete form, inject a server-side error at submission, and check whether the content is still there and whether the error is located to a field.
• Implementation side: check whether the submission-failure branch triggers a form reset; check the persistence of already-uploaded attachments after a failure.

CounterexamplesUnder-delivery — a registration form's submission fails, and the password, verification code, and all information are cleared together; over-delivery — even one-time verification codes and payment credentials are refilled and preserved.

UI5-5Leave confirmation is conditioned on substantive changesSHOULD¶

In one sentence: Don't block if nothing changed; if you block, say clearly what would be lost.

Applies toProducts that intercept and ask when the user tries to leave.

RuleLeave confirmation SHOULD be triggered by the existence of substantive unsaved changes (see gui.entry.leave.guard); intercepting when there is no change, or when the change has already been saved, MUST NOT occur. When navigation the application itself controls (in-app routing, tab switching, closing a dialog) triggers the interception, three separately executable options — save, discard, cancel — SHOULD be provided, and what would be lost by "discard" SHOULD be visible. Leaving that is controlled by the runtime environment (closing a browser tab, a system-level back action) can only use the prompt capability that environment actually provides — its copy and buttons are usually not customizable, and it may require prior user interaction; here, what this rule requires is not abusing that capability, and separately ensuring the draft policy itself can carry the content — claiming to have achieved an effect the environment does not support, merely to satisfy "three options," MUST NOT occur. Treating leave confirmation as a substitute for draft saving MUST NOT occur — when a draft has already been saved per UI5-1, interception is usually unnecessary.

Boundary conditionsThis rule does not specify how interception is implemented; different runtime environments offer different degrees of control over leave interception, and some restrict custom prompt content and require prior user interaction (see reference.md Section 3). A leave prompt is not a persistence mechanism: at most it warns once, and it does not replace UI5-1's draft saving.

Design applicationThe judgment of "substantive change" should exclude default values written by the system alone, formatting results, and empty changes produced by focus movement. Too broad a judgment makes the interception appear when the user has done nothing at all, and after a few times the user learns to confirm with their eyes closed.

Verification examples

• User side: open the form, make no changes at all, and leave directly, checking whether it is intercepted.
• Implementation side: check whether the change judgment compares substantive content, or merely records that "the form was touched."

CounterexamplesUnder-delivery — opening the page, glancing at it, and leaving triggers "you have unsaved changes"; over-delivery — the interception is built as an inescapable modal flow, forcing the user to deal with the form first when all they wanted was to close the tab.

Basis and referencesThe runtime environment's limits on leave interception (restricted custom prompts, a requirement for prior user interaction) are documented in the relevant specification and platform documentation (R09).

UI5-6Autosave and business submission are semantically separateMUST¶

In one sentence: It must be possible to say exactly which layer "saved" refers to.

Applies toProducts that present a save, sync, or submission status.

RuleEvery instance of "saved," "synced," or "completed" MUST map to a verifiable factual condition (see gui.entry.save.semantics): storage location, whether local persistence is confirmed, whether remote persistence is confirmed, the business submission result, and the basis for the external effect. A remote draft may exist while there is no persistent local copy; a local draft may likewise exist and never have been submitted as a business transaction. Compressing these independent facts into a mutually exclusive three-tier state MUST NOT occur; using autosave to represent that the business has been submitted, or using "submission accepted" to represent that the external effect has completed, MUST NOT occur.

Boundary conditionsOnly the facts the current user needs to judge are displayed; this rule does not require putting every dimension on the interface. When a storage receipt cannot be obtained, mark it as save pending confirmation or result pending verification; success MUST NOT be inferred from the animation ending, the request having been sent, or the local edit having finished.

Design application"Saved on this device," "draft saved to the server, not yet submitted," and "submission result pending verification" each bind to a different fact. A save operation MUST bind to its corresponding content; a delayed receipt confirming a previous block of text was saved successfully MUST NOT mark new input that is still unsaved as saved.

Verification examples

• User side: separately test a local offline draft, a remote-only draft, and a case where the business has been submitted but the notification hasn't gone out, checking whether the user can distinguish "saved" from "in effect."
• Implementation side: check the factual mapping of each piece of copy; make save A's receipt arrive after edit B, and B must still show unsaved or saving.

CounterexamplesUnder-delivery — while editing offline, the interface shows "saved," and the user opens it on another device to find the changes are entirely gone; over-delivery — every pause in typing displays a full explanation of all three layers of state on the interface.

UI5-7Input assistance and composed input are not interruptedMUST¶

In one sentence: Let people finish writing in their own input method, and don't treat selecting a candidate as submitting.

Applies toInterfaces that accept input of text, credentials, or repeated data.

RuleCandidate content within an IME composition MUST NOT be disrupted by validation, autoformatting, or re-rendering; the Enter key used to confirm a candidate word MUST NOT also submit the form, and the Esc key used to cancel a candidate MUST NOT also close the editor. The final text is processed only after composition ends (see gui.entry.input.policy). Paste, autofill, password managers, and platform text editing MUST be usable; when a restriction is genuinely necessary, the reason MUST be recorded per field along with an alternative that can complete the task, and disabling paste MUST NOT be used as a generic security measure.

Information already provided within the same flow SHOULD be carried in automatically or offered as a selectable option; requiring it to be re-entered with no reason MUST NOT occur; when re-entry is genuinely the substance of the task, a security necessity, or the original information has expired, the exception MUST be recorded (see gui.entry.reuse.policy). Labels, format, and the purpose of the input MUST be perceivable, and a label MUST NOT rest solely on placeholder text that disappears once typing begins; a date, number, name, or similar value MUST NOT be forcibly converted into a format that changes its meaning without explanation.

Boundary conditionsA password may use a password manager or paste during the current authentication process, while not entering ordinary draft persistence. Supporting input assistance and saving sensitive content are separate decisions.

Design applicationTest Chinese and Japanese IME composition, paste, autofill, and voice-to-text input separately; do not bind all input handling only to keyboard keystroke events.

Verification examples

• User side: press Enter to select an IME candidate word — the text lands normally but nothing is sent; pasting a verification code or using a password manager can complete authentication.
• Implementation side: check the ordering of composition state, final text input, and shortcut-key handling; after autofill, the model value, the validated value, and the on-screen value are consistent.

CounterexamplesUnder-delivery — pressing Enter to select a pinyin candidate sends half a sentence, or the form remains internally empty after pasting; over-delivery — instant suggestions are disabled entirely in the name of protecting input, or a password is saved long-term as an ordinary draft.

Basis and referencesFor an explanation of composition events see R18; for applicable requirements on repeated input and accessible authentication see R19. This rule's prohibition on accidental submission is derived from the commitment to input integrity.

3.6 UI6 Direct manipulation has an equivalent path¶

Drag-and-drop, zoom, marquee selection, and handwriting — these continuous actions are the most intuitive form of direct manipulation: the action of the hand and the change on the screen are linked together, with no layer of commands in between. This principle governs the semantics and substitutes for this category of action. Its core claim is: continuous manipulation is an input method, not a feature. If reordering is implemented only as drag-and-drop, then for someone who cannot drag, this product simply has no "reorder" feature. This principle also governs the predictability of the manipulation process itself — knowing what will happen before releasing, and an explicit cancel or releasing on an invalid target leaving no residue of this operation.

UI6-1Drag-and-drop has a non-drag-and-drop equivalent pathMUST¶

In one sentence: Someone who can't drag must still be able to get the task done.

Applies toProducts that use drag-and-drop to accomplish moving, sorting, categorizing, uploading, or adjusting parameters.

RuleDrag-and-drop MUST NOT serve as the sole channel for any feature (see gui.manipulation.drag.mode). For every feature accomplished through drag-and-drop, an equivalent path that does not depend on a drag action MUST exist (see gui.manipulation.drag.alternative); the criterion for equivalence is being able to complete the same task, not reproducing the same action. The equivalent path MUST be discoverable, and MUST NOT exist only in help documentation or a keyboard-shortcut reference.

The single-pointer path and the keyboard path MUST each hold independently and be verified independently. For a drag feature implemented by the product itself, besides the keyboard path, there MUST also exist a single-pointer path that requires no dragging and does not depend on a path-shaped gesture (click the source, then click the target, or a menu command); providing only a keyboard command does not satisfy this item — a user who can only click with a pointing device and cannot perform a drag action is still unable to get through. Multiple input paths share the same object, the same permission determination, the same point of submission, and the same undo boundary; only the means of input differs, and this MUST NOT produce an additional business action. When the drag action is itself the substance of the task (freehand drawing, a signature), or the behavior is provided by the runtime environment and unmodified by the product, the reason MUST be recorded feature by feature per the corresponding exception, and the applicable clause is used to record its scope of applicability and the basis on which the exception is essential and necessary; manufacturing an exception by moving a feature out of the core task list MUST NOT occur.

Boundary conditionsThis rule does not prohibit drag-and-drop, nor does it require the equivalent path to be equally efficient — drag-and-drop as an accelerator is reasonable. The equivalent path may be a menu command, cut and paste, a target-selection dialog, a keyboard command, or numeric input, chosen by the product, but the single-pointer path and the keyboard path cannot each be established by proxy of the other. When the drag action is itself the substance of the task and irreplaceable (freehand drawing, a signature), that feature has its reason recorded item by item under this rule's exception; moving it out of the core task list cannot substitute for that argument (for the list's role see UI4-1).

Design applicationWhen designing sorting, categorizing, or uploading, design the non-drag-and-drop path first, then add drag-and-drop as an accelerator. Doing it the other way around, the equivalent path often ends up as an inconspicuous menu item added as an afterthought.

Verification examples

• User side: walk through every applicable drag feature using only the keyboard, and again using only single-pointer clicking, recording which tasks cannot be completed.
• Implementation side: list every feature triggered by drag-and-drop, and check each one for the existence and discoverability of an equivalent path.

CounterexamplesUnder-delivery — a kanban board can only change a card's status by dragging it, with no way to move it via keyboard or menu; over-delivery — the equivalent path is built as a multi-step dialog requiring selection through layer after layer, which no one wants to use in daily practice.

Basis and referencesAn equivalent path not dependent on a drag action has a written clause with exceptions in current accessibility standards (R07); platform guidelines also require an alternative to be provided for drag-and-drop (R10); drag-and-drop needs to be expressed through accessible controls, object state, and result messages, and cannot rely solely on drag visual effects (R08).

UI6-2The drop target and result are visible before releaseMUST¶

In one sentence: Know what it will look like before letting go.

Applies toProducts that provide drag-and-drop or other manipulation that requires designating a drop target.

RuleWhile the manipulation is in progress, which targets are valid drop targets, which are not, and what it will become after being dropped MUST be visible before release (see gui.manipulation.drop.preview). The preview MUST include at least one expression that conveys the result (the resulting position, result-semantic copy), not merely "you can drop here." Presenting the nature of the drop result for the first time only after release MUST NOT occur (which container it went into, where it was inserted, what it replaced).

Boundary conditionsThis rule does not require a pixel-exact preview of the final rendered result; expressing the position and semantics is sufficient. When there are extremely many targets (a large canvas), only the targets near the current pointer may be marked, without requiring all of them to be marked.

Design applicationDesign "can drop here" and "what happens once dropped" as two layers of feedback: the former is the target's highlight, the latter is an insertion-position line, a placeholder preview, or a line of result copy. Doing only the former is this rule's most common omission.

Verification examples

• User side: drag an object and pause over a container boundary, between list items, and over an invalid region, checking what the interface expresses in each case.
• Implementation side: check whether valid targets and invalid targets have two independent expressions; check whether the result preview matches the actual execution result.

CounterexamplesUnder-delivery — dragging a file onto a folder produces only a generic highlight, and only after releasing does the user find it was a replacement rather than a drop-in; over-delivery — the entire list re-sorts for a live preview every few pixels of movement, so the interface keeps jittering and the target becomes harder to see.

Basis and referencesDrop-target and result previews are a standard recommendation in platform drag-and-drop guidelines (R10, R11, R12).

UI6-3Whether a cross-container action moves or copies is disclosedMUST¶

In one sentence: Whether anything is left behind after dragging can't be a guess.

Applies toProducts that allow an object to be dragged into another container, list, project, or application.

RuleThe semantics of a cross-container manipulation (move, copy, or chosen by the user during the manipulation) MUST be disclosed, and the semantics currently in effect MUST be visible before release (see gui.manipulation.cross_container.semantics). When the user is allowed to switch the semantics during the manipulation, the tier currently in effect and how to switch it MUST be visible; the default tier when no choice is made MUST be declared. Letting the same action produce different semantics between different containers with no distinguishing expression at all MUST NOT occur.

Boundary conditionsThis rule does not specify whether move or copy should be the default — conventions differ across products, and using a different default for the same operation between same-source and cross-source cases is established practice. What this rule requires is that this default be declared, and that whichever tier is currently in effect be visible before release.

Design applicationCross-application or cross-account drag-and-drop especially needs disclosure — users' default expectations for "dragging from here to there" are not consistent across different systems, and this kind of operation is often irreversible.

Verification examples

• User side: drag once within the same list, once across lists, and once across projects, checking whether the semantics are expressed and match the actual result.
• Implementation side: check the semantic configuration corresponding to each drop target; find targets with no declared default tier.

CounterexamplesUnder-delivery — dragging a task card to another project makes the card disappear from the original project, and the user thought it was a copy; over-delivery — every single drag-and-drop first pops up a "move or copy" choice dialog, even for the most common case of reordering within the same list.

UI6-4One manipulation is undone as one stepMUST¶

In one sentence: A wrong drag is fixed with one undo, not five.

Applies toProducts that provide both direct manipulation and undo capability.

RuleOne complete manipulation (one drag-and-drop, one zoom, one batch move following a marquee selection) MUST be undone as one step (see gui.manipulation.undo.unit); splitting one manipulation into multiple undos MUST NOT occur, nor may undo be allowed to stop at an intermediate state of the manipulation. Derived changes produced by the manipulation (reordering, ownership change, count updates) MUST be undone together with the primary change. For the general requirement on undo granularity see UI2-3.

Boundary conditionsThis rule does not require merging multiple consecutive independent manipulations into one step. A user consecutively dragging three objects is three steps, not one.

Design applicationTreat the start and end of the manipulation as the boundary of the undo transaction, with the continuous intermediate changes not pushed onto the stack. This usually requires explicit handling at the implementation layer, because the manipulation process produces a large number of intermediate events.

Verification examples

• User side: after completing one cross-container drag-and-drop, press undo once and check whether the object returns to its original position in the original container.
• Implementation side: check how many records in the undo stack correspond to one manipulation.

CounterexamplesUnder-delivery — after dragging a card across columns, undo first puts it back at the top of the column, and it only returns to its original column after pressing undo a second time; over-delivery — an entire round of organizing is merged into a single undo step, so a user who wanted to revert the last action instead reverts to a state from half an hour ago.

UI6-5Abandoning midway leaves no partial resultMUST¶

In one sentence: Canceling the current manipulation leaves no half-finished remnant of it.

Applies toProducts that provide continuous manipulation.

RuleWhen a manipulation whose semantics are preview-then-commit is abandoned before completion, this preview MUST be cleared and the pre-change state restored, while unrelated concurrent changes are preserved, and leaving a partial result MUST NOT occur (see gui.manipulation.abort.methods). The method of abandonment MUST include at least one discoverable explicit way (a cancel key, dropping back in place, releasing over an invalid target, moving out of a droppable region); no method of abandonment may leave this preview as a business result. A temporary state within a preview MUST NOT be treated as a committed business result. An interruption such as the system seizing the pointer, a lost touch point, or the window losing focus MUST have explicit handling, and MUST NOT leave behind a lingering "currently dragging" state.

Boundary conditionsA continuously-in-effect control, such as volume, SHOULD clearly distinguish "end the adjustment and keep the current value" from "cancel and restore the original value," declaring the boundary of what takes effect and what is compensated per gui.manipulation.commit.policy; an action that has already taken effect MUST NOT be labeled as a no-consequence preview. When the target has been deleted by someone else, that object MUST NOT be resurrected merely to restore a starting point. When the remote result cannot be verified, it is converted to pending verification rather than claimed as reverted. This rule does not require the interface changes during the manipulation (placeholders, previews, temporary highlights) to be restored frame by frame after abandonment; it requires clearing this manipulation's uncommitted changes while preserving valid external changes. When interrupted for an external reason (the object was deleted by someone else during the manipulation, the connection dropped), this rule requires explicitly disclosing the known impact and the portion pending verification, rather than hiding the uncertainty.

Design applicationFor move, sort, and similar actions, adopt a temporary preview layer with an explicit commit boundary; for continuously-in-effect controls, retain the starting value and define compensation, explaining any impact that cannot be compensated for in advance. The two approaches are verified separately; "writing data on every frame" cannot be used to pretend a cancel mechanism exists.

Verification examples

• User side: lift an object and press the cancel key, drag it to an invalid region and release, and drag it out of the window and release, checking whether all three cases produce no change.
• Implementation side: check per the commit policy whether the preview writes early, and whether a continuously-in-effect control can be ended or compensated; inject an interruption and check for residue and concurrent edits.

CounterexamplesUnder-delivery — pressing Esc partway through a drag has already removed the object from the original list without it entering any target, and it simply disappears from the interface; over-delivery — to guarantee it can be abandoned, the user is required to confirm the drop again at the end of every single manipulation.

UI6-6Precision requirements are proportionate to the input methodSHOULD¶

In one sentence: Anything that must align to the pixel shouldn't rely on the hand alone to hold steady.

Applies toProducts whose manipulation result is sensitive to precision in position, size, order, or value.

RuleA manipulation requiring fine positioning or small adjustments SHOULD provide an equivalent input that does not depend on the steadiness of the hand (see gui.manipulation.precision.alternative): step keys, numeric input, alignment and snapping, zoomed-in manipulation, or selecting the target by object. Leaving the responsibility for achieving precision entirely to the fineness of the user's own motion MUST NOT occur, especially under lower-precision input methods such as touchscreens and remote pointers. The existence of a precision-equivalent input does not replace the equivalent-path requirement of UI6-1; the two may be satisfied by the same mechanism.

Boundary conditionsThis rule does not require numeric input for every manipulation — it does not apply to manipulations that are not sensitive to precision (dragging a card into another column). When, in a freeform creative tool, the fineness of the manipulation is itself the content being expressed (a hand-drawn stroke), that manipulation may be excluded from this rule's scope with the reason stated.

Design applicationSnapping and alignment are the most common form of precision compensation, but they also make "deliberately not aligning" harder. When snapping is provided, a way to temporarily turn it off SHOULD be provided alongside it, along with an input channel precise down to a number.

Verification examples

• User side: on a touchscreen, adjust an element to a specific value, and record how many attempts it takes.
• Implementation side: check whether precision-sensitive manipulations have a numeric or step equivalent channel.

CounterexamplesUnder-delivery — a crop box can only be adjusted by dragging its handles, and on a touchscreen it's always off by a few pixels, with no numeric input; over-delivery — all snapping and guide lines are removed, requiring the user to enter coordinates one by one to complete a layout.

Basis and referencesThe requirements for target-area size and drag-action alternatives apply equally to judging precision compensation (R07); platform guidelines offer related recommendations for snapping and step adjustment (R10, R12).

4. Terminology and definitions¶

This chapter defines only the terms used within these guidelines that are prone to ambiguity.

Appendix A: Fault-injection verification checklist and classification test¶

This checklist is used to verify whether the clauses actually take effect; it adds no new obligation. Inject item by item and record the system's actual behavior; recording "not applicable" is a qualifying result, recording "not tested" is not.

A.1 Objects and selection

A.2 Consequences and reversibility

A.3 Feedback and state

A.4 Input and data entry

A.5 Direct manipulation

A.6 Concurrency, unknown states, and input boundaries

A.7 Classification test

Used to test whether Chapter 1's division holds: take 10 to 15 concrete requirements (from this guideline's clauses, or from real review comments), and have at least three reviewers who did not participate in writing them independently judge which principle each belongs to. When disagreement over assignment concentrates between two particular principles, it means the regulated objects of those two principles have not been cleanly separated — at that point the principles should be adjusted, rather than adding an intermediate layer or an explanatory note. The two spots already known to need focused testing are stated explicitly in Chapter 1 (UI1 and UI3, UI4 and UI6). The number of reviewers and the disagreement threshold are an internal check method this guideline suggests, not a literature-validated standard.

Appendix B: Evidence boundaries and source types¶

B.1 The criterion for normative terms

The sole basis for marking something MUST is: without it, some promise to the user would fail under a foreseeable circumstance. The three categories of evidence below provide different kinds of support; they are not three independent mandatory sources — an implementation reference by itself is not sufficient to decide a MUST marking —

The seven rules marked SHOULD (UI1-6, UI2-5, UI3-3, UI3-6, UI4-5, UI5-5, UI6-6) are all trade-off questions, not bottom-line questions: deviation may have a legitimate reason, but it must leave a trace and accept the same verification. Among them, UI1-6 allows selection to follow focus in a single-select context, and UI6-6 allows a creative tool to exclude a manipulation where the fineness of the hand's motion is itself the content being expressed — the exception scope at these two spots is the one most prone to being stretched too far in use.

B.2 The three spots where this guideline's evidence is thinnest

Listed explicitly, not concealed under the tone of a normative clause:

1. The time thresholds in UI3-1 and UI3-3 have no universal value verifiable by this guideline. The classic tiering of response time is widely cited, but it has not been re-verified against current devices, networks, and interface forms, nor can it be directly transcribed into a universal threshold for every category of operation. These guidelines therefore only require "determined and recorded by the product based on the target scenario and population," giving no number — this is also the item in these guidelines most easily satisfied only on paper.
2. UI2-2's "undo takes priority over confirmation" is a design claim, not an empirically proven conclusion. Existing sources support the two directions of "leaving an exit for mistaken actions" and "error prevention over error messages," but this search did not find a cross-product controlled study proving that "undo is generally superior to confirmation." This rule's strength comes from a consequence analysis (confirmation requires the user to judge at the moment their attention is lowest), not from experimental evidence.
3. UI4's input parity is anchored on the core task list, and the list itself is defined by the product. This makes the strictness of this group of rules depend on which tasks the product writes into the list. UI4-1 gives the basis for inclusion — main outcomes plus create, modify, submit, recover, and exit; it must still be checked against real task observation to see whether the list omits critical work, and cannot rely on self-declaration alone.

B.3 What this guideline does not do

It gives no control list, no visual specification, no grid and spacing, no motion durations, no uniform cross-platform target-area value, no component API, no state-machine implementation, no recommendation for selecting a drag-and-drop library, and it does not make an accessibility compliance judgment. These are decisions for the product, the design system, and specialized assessments; this guideline only specifies that these decisions must be made, must be verifiable, and which values are not permitted.

B.4 Sources

For the complete source cross-reference, verification status, and search records see reference.md. A clause in these guidelines does not hold simply because some platform has done it this way; a platform's practice is evidence that "this kind of mechanism is feasible in a real product," not a basis for "it should be required this way." When inconsistencies exist among multiple platform guidelines, this guideline does not rank them by merit, and only takes the quality of behavior they jointly support.

Appendix C: A minimal design record from scenario to acceptance¶

This appendix is an application method; it adds no new rule. Fill it in per an actual task, avoiding expanding the document by control count.

A scenario running throughout: move 20 selected cards to the archive column. The toolbar shows "Move 20 items," which can be checked against the cross-page selection; a drag-and-drop preview shows the target and the move semantics, alongside a "Move to" menu usable by keyboard and by clicking. The object scope is frozen at release or target confirmation; before remote confirmation it shows "moving," not "completed." When 17 items succeed, 2 are rejected, and 1 has an unknown result, they are summarized into three groups with each item locatable; retry is opened only for items verified as failed and meeting the retry conditions, with unknown items verified first. Undo belongs to this operation and protects subsequent edits; when not everything can be restored, it is explained item by item. An ordinary move does not gain repeated confirmations because of these safeguards.

Acceptance evidence is kept separately: a documentation check proves the definitions are complete; fault injection proves the mechanism holds under test conditions; real-task testing proves the user can understand and complete it. A composite score MUST NOT be used to offset a bottom-line failure such as the wrong object, lost input, an unknown result reported as success, or a duplicate external send. "Not tested" does not count as passing; "not applicable" must be reviewable. Also record the click count, completion time, error-recovery duration, and no-benefit interruptions on the normal path, to check whether error prevention has added unnecessary burden.

---

Implementation acceptance scenarios¶

The scenarios below turn existing clauses into reviewable acceptance inputs; they set no additional universal performance threshold. Select per the product's applicable capability, and supplement with real devices, users, input sequences, and evidence; record the reason when not applicable, and an untested item must not be recorded as passing.

Each scenario separately checks the configuration's effective value, the execution record, and the user-understandable result. Retain the version, target, event timestamp, failure scope, and recovery result; an unknown external result is not filled in as success or failure.