# Design User Experiences > Design, audit, redesign, prototype, and validate user experiences for websites, web apps, mobile apps, dashboards, SaaS, onboarding, navigation, forms, design systems, AI products, voice interfaces, and immersive products. Use this skill whenever a request involves UX, usability, user flows, information architecture, conversion, onboarding, navigation, interaction states, accessibility, internationalization, a design critique, or a meaningful page or product redesign, even when the user asks only to “make it easier,” “improve the experience,” “fix the flow,” or “make this screen work better.” It turns evidence into a clear user journey, then specifies or implements the smallest coherent improvement. - Skill: `maybackcompany/design-user-experiences` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add maybackcompany/design-user-experiences` - Raw SKILL.md: https://api.skillmd.com/api/skills/maybackcompany/design-user-experiences/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: MaybackCompany (https://skillmd.com/u/maybackcompany) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/maybackcompany/design-user-experiences --- # Design User Experiences Design for an observable user outcome, not for a prettier screen. The experience includes entry, comprehension, decision-making, action, feedback, recovery, completion, and return. Use cognitive principles as hypotheses and design checks, not as persuasion tricks. They do not override user research, accessibility, safety, user autonomy, or the product’s actual constraints. ## Choose the task mode - **Audit:** Inspect the current product and key task. Report evidence-backed friction, severity, and the smallest effective changes. Do not implement without authorization. - **New experience:** Frame the problem, model users and tasks, define architecture and flows, choose fidelity, test the risky assumptions, then specify or implement. - **Redesign:** Preserve useful product and brand DNA. Diagnose the journey failure before changing structure or visual language. - **Research or strategy:** Start from the decision to be made, then choose the least expensive research that reduces uncertainty. - **Design system:** Inventory patterns, establish tokens and component contracts, and migrate incrementally. - **Emerging interface:** Apply AI, voice, AR, or VR guidance only if that modality is actually in scope. If the user requests only an audit, explanation, or critique, do not change files. ## Core workflow ### 1. Inspect reality Review the product, repository, screenshots, analytics, research, support evidence, constraints, and existing design system. Separate every conclusion into: - **Observed:** Directly visible or measured. - **Provided:** Supplied by the user or a trustworthy source. - **Inferred:** A reasonable explanation that needs validation. - **Assumed:** A gap that could change the recommendation. Never invent research, personas, usability findings, analytics, accessibility compliance, or business proof. ### 2. Frame the experience State the target user, context, job, obstacle, business objective, primary task, and success signal. Use one sentence when possible: > For [user] in [context], help them [outcome] without [main friction], measured by [observable signal]. Read [research-and-strategy.md](references/research-and-strategy.md) for interviews, personas, journey maps, synthesis, competitive analysis, and strategy. ### 3. Map the journey before screens Map the happy path first, then define entry points, decisions, dependencies, permissions, validation, loading, empty, error, offline, recovery, cancellation, undo, backtracking, and re-entry states. For every important step, answer: 1. What does the person need to understand now? 2. What is the one next action? 3. What uncertainty, effort, or risk could stop them? 4. What feedback proves what happened and what comes next? Read [information-architecture-and-prototyping.md](references/information-architecture-and-prototyping.md) for sitemaps, navigation, flows, wireframes, prototypes, testing, and heuristic evaluation. ### 4. Reduce cognitive work without hiding necessary complexity Apply the relevant principle below only when it improves the user’s task. Explain the user problem it addresses, the intervention, and how to validate it. | Situation | Design response | Guardrail | | --- | --- | --- | | Many choices or a high-stakes decision | Reduce irrelevant options, group related choices, sequence decisions, and visibly recommend only when there is a defensible basis. | Do not remove needed control or obscure tradeoffs. | | Long or complex content | Chunk by task and meaning; use headings, progressive disclosure, and summaries. | Do not fragment one coherent task into needless steps. | | A familiar category or convention | Follow the user’s established mental model and platform conventions. | Depart only when the benefit is clear, then teach the new pattern in context. | | Repeated actions or dense controls | Make related controls look and behave consistently; use proximity, common regions, similarity, and clear connection. | Visual grouping must match actual behavior, not merely appearance. | | An important action on touch or pointer input | Put the action near the task, make the target large enough, and separate destructive or competing targets. | Test with keyboard and touch; size alone does not make an ambiguous action clear. | | A short system response | Keep direct feedback perceptibly immediate; preserve layout and acknowledge the action. | Do not fake completion or add decorative delay. | | A longer process | Show honest progress, what is happening, and an escape or recovery path where possible. | Never fabricate progress or wait time to manipulate trust. | | Multi-step commitment | Show meaningful progress, preserve entered work, and make the end state and next step clear. | Do not use progress to pressure completion or hide cancellation. | | A memorable, risky, or emotional moment | Treat confirmation, errors, irreversible actions, and completion as high-attention moments; provide calm, specific recovery. | Delight must not mask loss, cost, consent, or risk. | | Flexible human input | Accept reasonable formats, normalize safely, retain user input, and explain constraints before and after validation. | Be strict at security, payment, identity, and other trust boundaries. | | Visual polish | Use coherent hierarchy and craft to increase confidence, then test actual task success separately. | Attractive UI can conceal usability failure. | The table operationalizes choice overload and Hick’s Law; chunking and working-memory limits; Jakob’s Law and mental models; Gestalt grouping; Fitts’s Law; the Doherty Threshold; Goal-Gradient and Zeigarnik effects; Peak-End; Postel’s Law; and the aesthetic-usability effect. Read [laws-of-ux.md](references/laws-of-ux.md) when a decision, navigation, form, onboarding, feedback, or interaction critique needs deeper application guidance. ### 5. Establish hierarchy and system fit Make the current state, primary action, and next step obvious through content order, layout, spacing, typography, contrast, and grouping. Do not rely on visual polish to compensate for weak architecture. For an existing product, inspect tokens and nearby components before creating a pattern. Prefer consistency unless the established pattern causes usability or accessibility harm. Make novelty earn its learning cost. Read [visual-interface-and-systems.md](references/visual-interface-and-systems.md) for responsive layout, typography, color, components, interaction states, and design systems. ### 6. Design inclusively and safely Treat keyboard use, semantics, focus, contrast, touch targets, reduced motion, error recovery, localization, text expansion, RTL, assistive technology, privacy, consent, and user control as design inputs. Never use cognitive principles to create urgency, hide choice, obstruct cancellation, make refusal difficult, or exploit vulnerable users. When business goals and user agency conflict, surface the tradeoff and favor clear consent and reversible choice. Read [accessibility-and-internationalization.md](references/accessibility-and-internationalization.md) for production UI, forms, navigation, media, international audiences, or compliance claims. ### 7. Prototype the uncertainty, not the whole product - Sketches and flows test structure and sequence. - Low fidelity tests hierarchy and comprehension. - High fidelity tests content, visual hierarchy, motion, and realistic interaction. - Coded prototypes test responsiveness, input behavior, performance, and accessibility. Do not polish screens before the primary flow is coherent. ### 8. Test decisions and interpret results honestly Define tasks, participants, success criteria, observations, and stop conditions before testing. Separate what people say from what they do. Prioritize repeated failures that block the primary outcome. When direct research is unavailable, run a heuristic review and label it expert evaluation, not user evidence. For cognitive-law interventions, compare the original and revised task where practical; measure comprehension, time, error, abandonment, confidence, and recovery rather than aesthetic preference alone. ### 9. Implement and verify When implementation is requested: - Preserve the existing stack and design tokens. - Build the complete state model, not just the happy-path screenshot. - Use semantic structure and accessible controls. - Check realistic content on desktop and narrow mobile layouts. - Walk through keyboard, focus, reduced-motion, and error-recovery behavior. - Run the smallest relevant checks. Read [critique-and-delivery.md](references/critique-and-delivery.md) for severity, critique formats, handoff, case studies, and decision records. ## Emerging interfaces Read [ai-voice-and-immersive-ux.md](references/ai-voice-and-immersive-ux.md) only for AI/ML features, conversational agents, voice input/output, AR, VR, or multimodal products. ## Required quality gates Before calling UX work complete, verify: - The primary user, outcome, primary task, and success signal are explicit. - The primary task is discoverable without explanation. - Navigation and labels match user language and established mental models where appropriate. - Choice count and information density are appropriate to the decision; necessary complexity is explained, not concealed. - Important actions have clear targets, immediate acknowledgment, honest progress when needed, and recovery. - Empty, loading, error, success, disabled, and permission states are covered when relevant. - Forms have visible labels, constraints, validation, and next-step feedback. - Mobile preserves task priority instead of merely shrinking desktop. - Keyboard, focus, semantics, contrast, touch, and reduced motion are considered. - Localization does not depend on fixed English lengths or culture-specific assumptions. - Components follow the existing system, or the reason for a new pattern is documented. - Recommendations distinguish evidence, inference, and assumptions. - Cognitive principles are used to reduce friction, never to manipulate choice or conceal risk. - Proof, metrics, testimonials, and quotes are real. - Verification is proportionate to risk. ## Output pattern For audits and recommendations, lead with the outcome: 1. **Verdict:** What works, what fails, and why it matters. 2. **Evidence:** Observations, sources, inference, and assumptions. 3. **Primary journey:** User, trigger, steps, outcome, and failure points. 4. **Findings:** Severity, affected user, evidence, recommendation, relevant cognitive principle if useful, and validation method. 5. **Proposed structure:** Flow, hierarchy, states, responsive behavior, and tradeoffs. 6. **Verification:** Tests completed or evidence still needed. For implementation tasks, keep planning brief and finish with files changed, checks run, browser verification, and remaining risks. ## Sources and provenance This revision draws on the practical framework at Laws of UX by Jon Yablonski. Treat it as a source of design hypotheses and link it to observable user outcomes, not as a substitute for research. The underlying curriculum structure adapts `hendurhance/ui-ux`, a CC0 UI/UX learning guide. Read [source-and-license.md](references/source-and-license.md) for provenance and scope.