--- title: UI Responsiveness Standard description: Honest interaction states, preserved work, accessible feedback and purposeful motion. reviewed: "2026-11-12" --- # UI Responsiveness Standard Public edition. Last reviewed: 2026-11-12. Entry point: [Digital Design Standards](digital-design.md). ## Purpose and scope Make interactions feel immediate while accurately representing real system state. Use the relevant patterns for the interaction; do not apply every pattern everywhere. Reduce actual latency and unnecessary work alongside perceived latency. This guide applies the [Digital Design Standards](digital-design.md) to interactions. People and digital agents can use the same guidance for websites, dashboards, and app UIs. Project-specific implementation details belong in that project's documentation. Apply this standard to new UI work and relevant edits; verify affected behavior before claiming implementation. ## Interaction contract - Acknowledge the user's action immediately with a local pending state or response. - Keep pending, confirmed, failed, timed-out, empty, and stale states distinguishable. - Never show success before the operation's required confirmation. Approvals, sent emails, payments, and authentication/access changes require authoritative server confirmation. - Preserve entered text, selections, and recoverable work on failure; offer a useful retry. - Prevent duplicate effects with pending guards and server idempotency where applicable. A timed-out write may have succeeded: reconcile state before blindly retrying it. - Scope responses to the current request, record, and mounted view. Cancel obsolete work where supported and ignore late/out-of-order responses; closing a modal must not let its response mutate a different view. Do not imply a committed write was canceled. ## Choose the pattern that removes the actual friction ### Optimistic UI: reversible local feedback Use for low-risk, reversible writes such as a favorite toggle when rollback is reliable. Mark the change pending, reconcile with the server result, and roll back on rejection. Explain failure and retain enough intent to retry. Serialize or version rapid repeated changes so an older response cannot overwrite the latest intent. Do not use optimism as evidence that an approval, email, payment, or authentication operation succeeded. ### Skeletons: stable shape while real content loads Use when content structure is predictable and a wait is likely to be noticeable. Match final geometry, reserve image dimensions/row space, and prevent layout shifts. Keep useful existing content visible during refresh, with an updating/stale indication. Fast or cached responses should render directly: delay the placeholder briefly if useful, never delay ready content to show a skeleton or force a minimum animation duration. A skeleton must resolve to content, a genuine empty state, or an actionable error/timeout. ### Tiny blurred image previews: visual continuity Use a small derivative or embedded placeholder for an image the user is already allowed to see. Reserve its aspect ratio, then replace it with the real asset without a jump. Keep meaningful alt text on the final image; make the placeholder decorative. Handle failed image loads. Do not download a large second asset merely to create the preview. ### Eased progress: smoother presentation of real work Animate transitions between observed progress values when it helps readability. Easing can be aesthetic, but percentages/counts/completion must never be fabricated: never advance a determinate bar on a timer, invent completed steps, or reach 100% early. Use determinate progress only for measurable work, label its phase (for example, upload), and show an indeterminate pending state when total progress is unknown. Bytes uploaded are not the same as server processing complete. End with authoritative success or error. ### Early upload and bounded prefetch: use an existing wait safely Begin an upload after explicit file selection only when the UI clearly tells the user that selecting the file starts transmission to the expected destination. Otherwise, wait for Upload/Submit. Never surprise-upload private files, auto-discover local files, or send content to a new service. Stay within existing permissions and user intent. Keep speculative prefetch read-only, bounded by size/concurrency, cache-aware, and cancelable; never prefetch mutations. Respect metered/slow connections and avoid work unlikely to be used. For early uploads, provide cancellation and a defined temporary retention/cleanup policy for abandoned files; do not imply cancellation recalls sent bytes. ### Visible search activity: honest feedback for actual queries Debounce typing as appropriate, show the submitted query and a searching state only while real search work is pending, and cancel/ignore superseded queries. Keep previous results usable but labeled as belonging to the prior query until new results arrive. Show real sources/stages only if the backend reports them; never animate invented searches, result counts, or activity. Distinguish no matches from failure, timeout, and offline state. ## Purposeful microinteractions and spatial continuity Use small transitions to explain a real state change or preserve the user's sense of place; this is optional polish, not a requirement to animate every control. Keep timing brief and interruptible, and never delay input or ready content until an animation finishes. - Copy feedback: show a check or “Copied” only after the clipboard write succeeds; expose failure and accessible status. Reserve space so changing the icon/label does not shift neighbors. - Form fields: keep a persistent, programmatically associated label visible for empty, focused, filled, and invalid states. A floating-label transition is optional; placeholders are not labels. - Multi-step flows: show the current step and advance completed-step styling only after its real completion condition. A connecting-line animation must not imply unconfirmed progress. - Pins and list changes: a restrained transition may explain placement, removal or reflow. Preserve context and focus; deletion feedback follows the same confirmation/rollback rules as other writes, with undo only when actually supported. Bounces/ripples are not required. - Photo viewers: retain the relationship between thumbnail and expanded image when useful. If drag-to-dismiss is offered, keep visible and keyboard dismissal, avoid trapping page scroll, handle canceled gestures, and restore focus to the originating control when it still exists. ## Accessibility and resilience are part of responsiveness - Respect `prefers-reduced-motion`: remove shimmer/pulsing and nonessential transitions; retain a clear static status. Do not make motion the only signal. - Keep controls keyboard-operable, preserve logical focus, and restore focus after dialogs. - Use appropriate status/live-region and busy semantics; announce meaningful state changes without repeating every animation frame or exposing decorative skeletons to screen readers. Determinate progress exposes actual values; unknown progress must not invent `aria-valuenow`. - Keep stable layout and sufficient contrast; statuses must not depend on color alone. - Use bounded waits/timeouts, useful recovery, and preserved inputs. Never leave endless loading indicators or present a network failure as an empty data set. ## Default acceptance smoke checks for UI changes Exercise the affected interaction in the browser; use an existing test setup if helpful. No new test harness is required for documentation-only changes. - Fast/cache path: content appears directly, with no forced wait or flashing skeleton. - Slow network/CPU: feedback is immediate, layout stays stable, and pending state is honest. - Failure/offline/timeout: no false success, data loss, stuck loading, or empty-state disguise; rollback, recovery, and retry work, including ambiguous write completion. - Repeated clicks, rapid search edits, and out-of-order responses: no duplicate effects or stale overwrites. Close/reopen a modal during a request; no late updates to the wrong view. - Keyboard, screen-reader status semantics, and reduced-motion mode remain usable. - Added microinteractions: check clipboard rejection, persistent field labels, interrupted/rapid transitions and gesture cancellation as applicable; focus and controls work without animation. - Early uploads/prefetch: confirm destination, intent, bounds, cancellation, and abandonment cleanup; test only with non-sensitive sample data. Measure true latency too: compare request duration, time to usable content, interaction responsiveness, and layout shift before/after where relevant. Record environment and observed results; distinguish verified behavior from assumptions or untested states. ## Standards references - [W3C Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/): keyboard access, focus order, labels, contrast, status messages, and interaction-triggered animation. Relevant criteria include 2.1.1, 2.4.3, 3.3.2, 1.4.3, 4.1.3, and 2.3.3. - [W3C Accessible Rich Internet Applications (WAI-ARIA) 1.2](https://www.w3.org/TR/wai-aria-1.2/): accessible roles, states, and properties, including `status`, `progressbar`, `aria-busy`, and live-region semantics. Prefer native HTML semantics where available. These references cover the accessibility requirements relevant to this guide. Pattern selection, loading behavior, and motion details are b-tec design guidance, not requirements prescribed by those specifications. Validate usability and performance in the actual product; citing a standard does not establish conformance or measured results.