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 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 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.

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 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 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 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 for severity, critique formats, handoff, case studies, and decision records.

Emerging interfaces

Read 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 for provenance and scope.