--- name: ux-usability-foundations description: "Use when designing, critiquing, or improving an interface for usability, including affordances, feedback, constraints, error prevention, navigation clarity, or task flow." license: MIT metadata: author: hueyexe --- # UX Usability Foundations ## Purpose Help an agent make interfaces understandable, usable, forgiving, and aligned with user expectations. Treat usability as product behavior, not surface decoration. The agent should turn unclear or fragile UI into an interface where users can quickly answer: what is this, what can I do here, where am I, what happened, how do I recover, and is this worth the effort? ## When to use this skill Use this skill when the user asks you to critique, redesign, create, or specify a UI, flow, form, app screen, website, dashboard, onboarding, settings page, checkout, navigation model, state behavior, or component interaction for usability. Use it for affordances/signifiers, feedback, constraints, errors, empty/loading/success states, recognition over recall, task clarity, and frontend behavior. ## When not to use this skill Do not use as the primary skill for deep research operations, brand styling systems, visual polish, typography craft, frontend architecture, or persuasion/growth tactics unless those choices directly affect user understanding, control, or recovery. ## Core principles 1. **Start with goals, not screens.** Identify the user’s goal, task, context, and likely knowledge before changing controls or layout. Design requirements describe needs before widgets. 2. **Make the next action obvious.** Prefer self-evident interfaces. If the task is inherently novel or complex, make it self-explanatory with structure, labels, examples, and feedback. 3. **Show what is possible.** Interactive elements must look interactive. Read-only elements must not look editable. Hidden gestures need visible alternatives. 4. **Match the user’s mental model.** Use the concepts, names, and sequence users understand; do not expose database tables, file paths, internal IDs, or arbitrary system states unless users need them. 5. **Favor recognition over recall.** Keep needed options, context, examples, and state visible or easy to retrieve. 6. **Reduce work and excise.** Remove tasks that serve the system rather than the user’s goal: retyping, transferring data, hunting for controls, configuring obvious defaults, or answering inferable questions. 7. **Guide choices without overloading users.** Use progressive disclosure, sensible defaults, grouping, and prioritization. 8. **Give immediate, informative feedback.** Every consequential action needs a response that says whether the system received it, what changed, whether waiting is required, and what can happen next. 9. **Prevent errors before explaining them.** Use constraints, safe defaults, previews, tolerant input, inline validation, and undo where feasible. 10. **Blame the design, not the user.** Errors reveal a mismatch in expectations or an unsupported edge case. Preserve work and guide recovery. 11. **Respect platform and convention.** Use familiar patterns when they fit. Break convention only when the user’s goal clearly benefits and the new behavior can be discovered and recovered from. 12. **Accessibility is usability under pressure.** Design for perceptibility, operability, simplicity, and forgiveness across varied abilities, devices, literacy, stress, and environments. See [references/principle-cards.md](references/principle-cards.md) for each principle as a reusable card. ## Default recommendations ### Product goal Default to optimizing the primary user task before secondary business asks. Override only for legal, safety, fraud, privacy, or business-critical requirements. Ask: “Which obligation must interrupt or constrain the primary task, and what is the consequence of hiding or delaying it?” ### Audience Default to motivated but distracted users with average domain knowledge and imperfect memory. Override for trained expert operators using the product frequently under stable conditions. Ask: “Is this primarily for first-time/infrequent users, frequent intermediates, or trained experts?” ### Platform and input Default to platform conventions and support pointer, touch, keyboard, and assistive technology where relevant. Ask when platform/input constraints are unknown. ### Information density Default to enough context for recognition and decision-making, while hiding rare advanced controls behind clear entry points. Override for comparison, monitoring, or expert workflows. Ask: “Do users need overview density for monitoring/comparison, or step-by-step focus for completion?” ### Navigation Default to clear location, current object/state, access to major areas, and a visible route back or onward. Override only for intentional guided flows. Ask: “Should users be free to move around, or should this flow intentionally constrain navigation?” ### Labels and language Default to plain, task-oriented labels from the user’s vocabulary. Ask before using internal, clever, legal, or domain-specific terms. ### Forms Default to persistent labels, appropriate input types, upfront constraints, inline validation where helpful, preserved data, and a clear primary action. Ask only when density/speed for experts may be more important than first-time clarity. ### Error handling Default to prevention first; if error occurs, explain what happened, why it matters, and how to fix it without losing work. Ask when error details are sensitive, regulated, or security-relevant. ### Destructive actions Default to visually secondary destructive actions until the final review/confirmation step. Prefer undo for reversible actions; use confirmation for irreversible, costly, legal, or safety actions. Ask about reversibility and harm. ### Feedback and status Default to instant receipt feedback, progress for delays, visible completion, and persistent state for long-running or consequential operations. Ask which status changes should interrupt. ### Accessibility Default to WCAG-oriented basics: semantic controls, keyboard operation, focus visibility, programmatic labels, sufficient contrast, no color-only meaning, readable copy, and screen-reader-friendly state updates. Do not override basics. ## Required user questions Do not ask routine best-practice questions. Ask one focused question only when the answer changes the recommendation: - The primary user/task is unclear. - The action has safety, financial, legal, privacy, medical, or irreversible consequences. - Novices and experts need different behaviors. - Platform/input constraints are unknown. - Required terminology or compliance copy may apply. - The user requests a nonstandard, hidden, or manipulative pattern. - There is a real tradeoff between density and clarity or between guided flow and free navigation. Use this pattern: ```js question({ question: "What is the primary task this interface must help users complete?", recommended_default: "Optimize for the most common successful task first, then make secondary actions available but visually quieter.", options: [ "Complete one focused task", "Compare or monitor multiple items", "Explore and choose among options", "Other / custom" ] }) ``` Use the question-tool-ready prompts in [references/decision-prompts.md](references/decision-prompts.md) for the full decision set. ## Workflow for critiquing an existing UI Inspect in this order: 1. User goal and task fit. 2. First-glance comprehension. 3. Orientation: current place, object, state, and path onward/back. 4. Action discoverability. 5. Choice quality and priority. 6. Labels and language. 7. Feedback and status. 8. Error prevention and recovery. 9. Recognition versus memory burden. 10. Accessibility and input coverage. 11. Frontend feasibility and edge states. 12. Prioritization by task impact, frequency, severity, and fix effort. Report critique as: highest-impact usability issues, quick wins, behavior/spec details, accessibility notes, and risks/tradeoffs. ## Workflow for creating or improving an interface 1. Clarify the user, goal, success condition, and risk. 2. Choose the simplest useful flow. 3. Map user concepts and vocabulary. 4. Create visible structure and action hierarchy. 5. Select standard patterns unless a task reason justifies custom behavior. 6. Design default, hover, focus, active, loading, success, empty, validation, error, offline, disabled, and permission states. 7. Add constraints, validation, and recovery. 8. Support first use and repeated use. 9. Verify accessibility. 10. Explain decisions in terms of task progress, cognitive load, expectations, and risk. ## Decision framework Ask yourself: 1. Is the problem comprehension, choice, control, feedback, navigation, or recovery? 2. Can the design prevent the problem rather than explain it? 3. Can the interface use recognition instead of recall? 4. Can a standard pattern solve this without new learning? 5. Which elements are primary, secondary, tertiary, or dangerous? 6. Does the user need more information, fewer choices, or a better sequence? 7. Will the user notice the state change? 8. What happens if the user is distracted, rushed, using touch, using keyboard, using assistive tech, or recovering from an error? 9. What is reversible, costly, or irreversible? 10. Is this serving the user’s task or the system’s convenience? ## Practical rules ### Obviousness and scanning - Make each screen’s purpose visible in its heading, structure, and primary action. - Use descriptive buttons: “Send invoice,” “Save changes,” or “Book appointment,” not “Submit.” - Make click/tap targets look like controls without relying on hover. - Use headings, grouping, whitespace, and lists so users can scan. - Remove copy and decorative elements that compete with the task. ### Affordances, signifiers, and controls - Use native controls when behavior fits. - Use icons with labels for unfamiliar or consequential actions. - Preserve distinctions between links, buttons, selected items, disabled items, editable fields, and static text. - Do not hide essential actions behind gestures, long press, hover, or tiny overflow menus unless visible alternatives exist. ### Choices and progressive disclosure - Limit initial choices to the current decision. - Use safe, likely defaults. - Reveal advanced options near the point of need. - Use comparison structures when users must choose among similar plans, products, records, or settings. ### Feedback and state - Give immediate micro-feedback for command receipt. - Show progress for delays and async operations. - Confirm completion when the result is not visible. - Make current selection, current page, current filter, unsaved changes, and offline/sync status visible. - Avoid noisy feedback for routine non-events. ### Errors and recovery - Validate constraints before submission when feasible. - Keep invalid user input visible and editable. - Place errors next to affected controls and summarize long-form errors. - Use undo for reversible actions and confirmation for irreversible or high-risk actions. - Never make users start over after a recoverable problem. ### Navigation and orientation - Show current section, object, state, and available next/back paths. - Use breadcrumbs for deep hierarchy, not as a substitute for clear navigation. - Use tabs only for peer sections of the same context. - Use drawers/menus for infrequent or space-constrained actions; avoid hiding frequently needed primary navigation. - Preserve route, filters, and scroll position when users return from detail to list. ### Learnability - Make first-run help temporary and task-focused. - Prefer inline examples and empty-state guidance over separate help documents. - Let repeated successful use reduce beginner guidance. - Design for “perpetual intermediates”: users know the basics but do not remember everything. ## Accessibility and inclusion requirements - Use semantic HTML and native elements before custom widgets. - Ensure all interactive elements have accessible names. - Keep focus order aligned with visual/task order. - Provide visible focus indicators. - Support keyboard operation for all actions. - Associate labels, hints, and errors with form controls. - Do not rely on placeholder text as the only label. - Do not rely on color alone. - Announce async status and errors appropriately. - Ensure dialogs trap focus while open and restore focus when closed. - Respect reduced motion. - Make target sizes suitable for touch and motor variability. - Write at the simplest level compatible with the task and domain. ## Frontend implementation guidance ### Semantic structure - Use `