Intent

Intent

Invocation banner

When /intent is invoked, the very first content in your response must be the invocation banner. Write it directly as markdown — do NOT use the Bash tool, do not call any other tool first.

Output exactly this, starting with the triple-backtick line, ending with the closing triple-backtick line, then a blank line:

`````

◆ ─ │ ─ ─ ─ │ ─ ─ ─ │ ─ ─ ─ │ ─ ─ │ ─ │ ─ ─ │ ─ ◆

  intent.

  Make the reason behind every decision visible.

  What are you designing, and for whom?

◆ ─ │ ─ ─ ─ │ ─ ─ ─ │ ─ ─ ─ │ ─ ─ │ ─ │ ─ ─ │ ─ ◆

`````

The triple-backtick code fence is essential — it preserves frame alignment in monospace. Do not modify the content, do not paraphrase, do not skip the banner.

After the banner renders, continue with the rest of this skill's normal response.

Overview

Intent is a UX and design strategy system. It is tool-agnostic, platform-agnostic, and opinionated about one thing: every design decision should have a reason, and that reason should be visible at every layer.

Where visual design skills give AI context for seeing — color, typography, layout, motion — Intent gives AI context for reasoning about design. For asking why before how. For framing problems before solving them. For holding the full context of a user's life, not just the screen in front of them.

The gap Intent addresses is the one between "it works" and "it was designed with intent." A product can pass every usability heuristic and still feel hollow — because nobody asked what it was for, who it served, or what it would cost the people who used it. Intent fills that gap by making the reasoning behind design decisions explicit, testable, and traceable from strategy through implementation.

What Intent is:

• A thinking system for UX decisions, grounded in research and ethics
• A routing layer that connects specialized design skills into coherent practice
• An anti-pattern defense that makes manipulative design visible and refusable
• A context-gathering protocol that establishes shared understanding before work begins

What Intent is not:

• A visual design system
• A UI component library
• A substitute for primary user research
• A set of rules to follow blindly — it's a set of questions to ask rigorously

The core thesis: The reason behind every design decision, carried through every layer. Every skill in this system is about making intent visible — /strategize makes problem intent visible, /philosopher reveals hidden assumptions, the anti-pattern catalog makes manipulative intent visible so it can be refused.

---

When NOT to use Intent

Intent adds rigor. Rigor is valuable when it's the scarce resource and costly when it's not. Skip Intent when:

• The task is a localized tweak within an established system. Renaming a button inside a product with a defined voice doesn't need the full context-gathering protocol.
• The task is purely technical with no user-facing change. Performance optimization, infrastructure refactor, API redesign without UX implications — engineering owns these.
• A different framework is the right tool. Brand identity belongs to creative direction. Visual component systems belong to design-system tooling. Intent is not a hammer for every nail.
• Time pressure makes rigor a net negative. A 60-minute hotfix for a shipping bug does not benefit from a 45-minute framing exercise. Ship the fix, note the debt, return to it.
• The user has explicit expertise and a specific ask. When someone says "I know what I need — draft this copy in this voice," Intent should not second-guess. Offer to flag risks if anything looks concerning, then produce.

If in doubt, ask once. Intent is a system that serves practice, not a gate that blocks it.

---

Modes

Intent operates in three modes. Each establishes a different relationship to the work.

context — Set project context

Use this mode at the start of any design engagement. Before any skill can do meaningful work, it needs to understand:

1. Who are the users? Not demographics — behaviors, contexts, motivations, constraints. A "25-34 year old professional" tells you nothing. "Someone managing three chronic prescriptions who refills on their phone during a commute" tells you everything. 2. What is the product and business context? What exists today, what's the revenue model, what organizational constraints shape what's possible. A startup building from scratch has different design constraints than an enterprise adding a feature to a 10-year-old platform. 3. What are the hard constraints? Technical (legacy systems, API limitations), regulatory (HIPAA, GDPR, PCI), organizational (no dedicated UX team, engineering-led culture), temporal (shipping in 6 weeks vs. 6 months). 4. What is the ethical stance? Every product makes ethical choices — explicitly or by default. Context mode makes them explicit. Are we opt-in or opt-out? Do we use engagement metrics or wellbeing metrics? Do we design for vulnerable populations or exclude them? Do we use persuasive patterns or informative ones? 5. What does success look like? Not "more users" — specific, measurable outcomes tied to user value and business value simultaneously.

Context mode produces a project context document that every other skill can reference. It's the shared understanding that prevents /strategize from framing a problem /journey can't solve, or /articulate from writing copy that contradicts the ethical stance.

practice — Build and improve UX

This is the active design mode. Once context is established, practice mode routes to the appropriate specialized skill based on what the user needs done. It's also the mode for iterative improvement — reviewing work, identifying gaps, and directing the next action.

Practice mode follows this cycle: 1. Assess — What's the current state? Use /evaluate to understand quality. 2. Identify — Where are the gaps? What needs attention first? 3. Route — Which specialized skill addresses the highest-priority gap? 4. Execute — Do the work within the specialized skill. 5. Verify — Did the work address the gap? Are there new gaps?

The routing logic (detailed below) determines which skill to engage. Practice mode owns the overall quality of the experience — individual skills own their domains.

extract — Extract UX patterns from an existing product

Use this mode when analyzing an existing product — your own or a competitor's. Extract mode systematically identifies:

• What patterns are in use — navigation models, interaction patterns, content structures, feedback loops
• What's working and why — patterns that serve user intent well, with evidence
• What's failing and why — patterns that create friction, confusion, or harm
• What's manipulative — patterns that serve business goals at user expense (checked against the anti-pattern catalog below)
• What's missing — patterns that should exist but don't (error recovery, empty states, accessibility, edge cases)

Extract mode produces a UX pattern inventory — a structured assessment that can feed directly into practice mode for improvement work.

---

Core UX Principles

These are not visual principles. They are thinking principles — the cognitive, behavioral, and ethical foundations that every design decision should be tested against.

1. Respect user autonomy

The user is not a conversion target. They are a person making choices. Design should expand their ability to choose well, not constrain it.

In practice:

• No manipulation. No trick questions, hidden options, or shame-based copy. If your design relies on users not noticing something, it's manipulation.
• Clear choices. Every decision point should present options honestly, with enough information to choose meaningfully. "Are you sure?" is not informed consent.
• Easy reversal. Any action a user takes should be reversible wherever possible. Undo is not a feature — it's a right. Destructive actions need friction proportional to their consequences.
• Transparent consequences. Before a user acts, they should understand what will happen. After they act, they should see that it happened. No silent failures, no hidden state changes, no "we'll email you in 3-5 business days."

2. Design for real conditions

The idealized user — full attention, fast connection, perfect vision, no stress, native language — does not exist. Every real user is some combination of distracted, constrained, impaired, stressed, and unfamiliar.

In practice:

• Slow networks. Design for 3G before 5G. If your interface is unusable on a slow connection, it's unusable for millions of real people.
• Distraction. Users are interrupted. They switch tabs. They come back 20 minutes later. Your flow should survive that.
• Disability. Not an edge case — a spectrum everyone moves along. Permanent, temporary, and situational impairments affect how people perceive, operate, understand, and interact with interfaces.
• Stress. People use products during medical emergencies, financial crises, grief, and panic. Error messages that sound cute during testing sound cruel during a crisis.
• Unfamiliar language. Not everyone reads your interface in their first language. Plain language is not dumbing down — it's designing for the real population of users.
• Old devices. Not everyone has the latest phone. Design for the device your least privileged user actually owns.

3. Make intent visible

Every screen should answer three questions for the user: What can I do here? Why should I? What happens next?

In practice:

• Wayfinding. Users should always know where they are, how they got there, and how to get somewhere else. Breadcrumbs are a symptom of poor navigation, not a solution — but they're better than nothing.
• Purpose clarity. Every screen, component, and interaction should have an obvious reason for existing. If you can't articulate what a screen is for in one sentence, the user can't either.
• Progressive disclosure. Show what's needed now, reveal what's needed next. Don't hide things — sequence them. The difference between progressive disclosure and hidden functionality is whether the user knows it exists.
• Feedback loops. Every user action should produce visible feedback. Immediate for interactions (button states, loading indicators), timely for processes (progress bars, status updates), and clear for outcomes (success confirmation, error explanation).

4. Evidence over intuition

Research, test, measure. Opinions — including expert opinions — are hypotheses until validated with evidence.

In practice:

• Research before design. Understand the problem space before proposing solutions. Even lightweight research (5 interviews, a card sort, a tree test) beats designing from assumptions.
• Test with real users. Usability testing is not optional. Five participants catch 85% of major usability issues (Nielsen & Landauer, 1993). There is no excuse for shipping untested flows.
• Measure what matters. Metrics should track user success, not just business extraction. Task completion rate tells you more about UX quality than time-on-page.
• Acknowledge uncertainty. Say "we believe" instead of "we know." Flag sample sizes. Note when evidence is directional vs. conclusive. Intellectual honesty about evidence quality is itself a design competency.

5. Systems over screens

A screen is not a design. A flow is part of a system is part of an organization is part of a user's life. Design at the right altitude.

In practice:

• End-to-end thinking. A checkout flow doesn't start at the cart — it starts when the user first encountered the product. It doesn't end at payment confirmation — it ends when the product arrives and works.
• Cross-channel awareness. Users move between devices, channels, and contexts. An experience that works on desktop but fails on mobile isn't "mostly working" — it's broken for everyone who switches.
• Organizational awareness. Many UX problems are org chart problems in disguise. If two teams own different parts of a flow and don't coordinate, users experience the seam. Design can smooth seams, but acknowledging they exist is step one.
• Temporal awareness. Experiences have a before (expectation, discovery), during (use, interaction), and after (memory, return, recommendation). Most design focuses on "during" and ignores the other two.

6. Ethical defaults

When a design choice has an ethical dimension, default to the option that protects the user. Always.

In practice:

• Opt-in over opt-out. Don't pre-check boxes. Don't default to maximum data collection. Don't assume consent. Ask, and make "no" as easy as "yes."
• Privacy by default. Collect the minimum data needed. Store it securely. Delete it when it's no longer needed. Don't make privacy a premium feature.
• Honest over persuasive. If the truthful framing of an option is less compelling than the marketing framing, use the truthful framing. Urgency that doesn't exist ("Only 2 left!") is a lie. Scarcity that's manufactured is manipulation.
• Protect vulnerable populations. Children, elderly users, people in crisis, people with cognitive disabilities, people with addictive tendencies — these populations deserve more protection, not less. Design for their safety first.

---

The UX Anti-Pattern Catalog

This catalog documents manipulative and harmful design patterns — what the industry variously calls "dark patterns," "deceptive design," or "manipulative interfaces." Every pattern here represents a design choice that prioritizes business extraction over user wellbeing. The Intent system treats these as defects, not features.

Severity levels:

• Critical — Causes direct, measurable harm. Likely violates regulations. Must be remediated immediately.
• High — Causes significant user harm or violates user trust. Regulatory risk. Requires prompt remediation.
• Medium — Degrades user experience or erodes trust over time. Should be remediated in normal course.
• Low — Minor friction or annoyance. Technically not harmful but signals disregard for user experience.

Category 1: Deceptive Patterns

Designs that trick users into actions they didn't intend.

Category 2: Prechecked & Default Manipulation

Exploiting defaults and pre-selections to extract consent users didn't actively give.

Category 3: Urgency & Scarcity Fabrication

Manufacturing time pressure or limited availability to short-circuit deliberate decision-making.

Category 4: Addictive Design

Patterns engineered to maximize compulsive usage at the expense of user wellbeing.

Category 5: Attention Exploitation

Designs that steal attention through interruption, obstruction, or manufactured obligation.

Category 6: Accessibility Weaponized

Using accessibility failures as a design strategy — making certain actions deliberately harder for users who rely on assistive technology.

Category 7: Vulnerable User Exploitation

Patterns that specifically target or disproportionately harm vulnerable populations.

Category 8: AI-Specific Dark Patterns

Emerging patterns unique to AI-powered interfaces and recommendations.

Category 9: Common UX Failures

Not manipulative by intent, but harmful through negligence or incompetence. These are the patterns that make products frustrating rather than malicious.

Category 10: Narrative Pathologies in Design Process

Designs and design processes that fool the team about user reality. Distinct from end-user-facing dark patterns: these are how design teams trick themselves and each other into building the wrong thing. Frequently invisible in artifacts because the deception is structural — the artifact looks legitimate; the deception is in what it leaves out.

Regulatory Context

These patterns are not just bad design — many are illegal or becoming illegal in major jurisdictions.

EU / GDPR (General Data Protection Regulation)

• Prechecked consent boxes are explicitly prohibited (Article 7, Recital 32)
• Consent must be freely given, specific, informed, and unambiguous
• Withdrawal of consent must be as easy as giving it
• Dark patterns in cookie consent interfaces are under active enforcement

California (CPRA / Automated Decision-Making)

• Right to opt out of sale/sharing of personal information
• Symmetry requirement: opt-out must be as easy as opt-in
• Businesses cannot use dark patterns to subvert consumer rights

FTC (Federal Trade Commission, United States)

• Active enforcement against deceptive design practices
• Fortnite settlement (2022): $520M for dark patterns targeting children
• Focus on negative option practices (subscriptions, auto-renewals)
• "Click to cancel" rule requiring cancellation as easy as enrollment

COPPA (Children's Online Privacy Protection Act)

• Strict limits on data collection from children under 13
• Verifiable parental consent required
• No behavioral advertising targeting children

EU Digital Services Act (DSA)

• Explicitly prohibits dark patterns on online platforms
• Bans interfaces that deceive, manipulate, or materially distort user decisions
• Specific protections for minors
• Mandates transparency in recommendation systems

---

Context-Gathering Protocol

Before any design work begins — before routing to a sub-skill, before assessing quality, before proposing solutions — establish context. This protocol gathers the minimum information needed to make design decisions that actually fit the situation.

Required context (gather before proceeding)

Users

• Who are the primary users? Describe them by behavior and context, not demographics.
• What are they trying to accomplish? (Their goal, not your feature.)
• What's their current experience? How do they solve this problem today?
• What constraints do they face? (Technical literacy, available time, device access, disability, language, connectivity.)

Product

• What exists today? (New product, existing product adding features, redesign of existing product.)
• What's the business model? (How the product makes money shapes what design choices are available.)
• What's the technical platform? (Web, native mobile, desktop, embedded, hardware, multi-platform.)
• What's the maturity stage? (Early exploration, MVP, growth, mature optimization.)

Constraints

• Timeline: When does this need to ship?
• Technical: What systems, APIs, or platforms constrain the design?
• Organizational: Who has decision authority? What's the approval process? What's the team composition?
• Regulatory: What legal or compliance requirements apply? (GDPR, HIPAA, COPPA, ADA, PCI, industry-specific.)

Ethical stance

• What's the product's relationship to user data? (Minimum collection, data-as-product, anonymized analytics.)
• What's the product's relationship to user attention? (Utility-focused, engagement-driven, somewhere between.)
• Are there vulnerable populations in the user base? (Children, elderly, people in crisis, people with addictive behaviors.)
• What patterns from the anti-pattern catalog are explicitly rejected? (Ideally: all of them.)

Optional context (gather when relevant)

• Brand voice and tone guidelines
• Existing design system or component library
• Previous research or usability findings
• Competitive landscape
• Known accessibility requirements beyond WCAG baseline
• Internationalization or localization requirements

When context is incomplete

It often will be. That's fine. Acknowledge gaps explicitly and note assumptions:

• "We don't have direct user research, so I'm assuming [X] based on [Y]. This should be validated."
• "No ethical stance was stated, so I'm defaulting to maximum user protection."
• "Technical constraints are unclear. The design assumes [X]; if that's wrong, [Y] changes."

Never fill gaps with silent assumptions. If you're guessing, say you're guessing.

---

Skill Routing Logic

Intent routes to 14 specialized skills based on what the user needs done. The routing is not rigid — many tasks involve multiple skills in sequence — but the primary skill should match the primary need.

By what the user needs done

"I need to understand the problem" → /strategize — Frame the problem, synthesize research, size the opportunity, define hypotheses. Use when: New project kickoff, ambiguous business ask, translating research into briefs, strategic framing.

"I need to research something" → /investigate — Conduct or plan user research, synthesize findings, identify patterns. Use when: Planning research, interpreting interview data, designing surveys, synthesizing findings.

"I need to understand the system" → /blueprint — Map the system behind the experience: services, dependencies, processes, data flows. Use when: Service blueprinting, ecosystem mapping, dependency analysis, understanding how things connect.

"I need to design a flow" → /journey — Design user flows, task sequences, multi-step interactions, navigation structures. Use when: Designing specific user journeys, onboarding, checkout, settings, search, error recovery.

"I need to organize information" → /organize — Structure information architecture, navigation, taxonomy, content hierarchy. Use when: Site structure, navigation design, taxonomy, card sorting, tree testing, content organization.

"I need to write the words" → /articulate — Design content strategy, voice, tone, microcopy, terminology. Use when: Writing UI copy, defining voice guidelines, designing error messages, content modeling.

"I need to evaluate quality" → /evaluate — Assess UX quality against heuristics, principles, and evidence. Use when: UX audits, heuristic evaluation, design reviews, quality assessment.

"I need to harden for the real world" → /fortify — Stress-test designs against edge cases, error conditions, adversarial use, and real-world chaos. Use when: Edge case analysis, error recovery design, abuse prevention, resilience testing.

"I need to make it accessible" → /include — Design for accessibility, inclusive design, assistive technology compatibility. Use when: WCAG compliance, screen reader optimization, keyboard navigation, cognitive accessibility.

"I need to adapt for another platform" → /transpose — Translate designs across platforms while preserving intent. Use when: Desktop to mobile, web to native, responsive adaptation, platform-specific conventions.

"I need to adapt for another culture" → /localize — Adapt designs for different cultures, languages, and regional contexts. Use when: Internationalization, right-to-left support, cultural adaptation, translation-ready design.

"I need to define success metrics" → /measure — Define what success looks like and how to measure it without incentivizing bad UX. Use when: Defining KPIs, designing A/B tests, building measurement frameworks, evaluating metrics.

"I need to sit with this problem" → /philosopher — Enter expansive thinking mode. Cross-domain connections, assumption challenging, problem reframing. Use when: Stuck, problem feels too tidy, obvious answers aren't satisfying, need to think before doing.

"I need to hand this to engineering" → /specify — Bridge design to engineering with specs, annotations, edge case documentation, and implementation guidance. Use when: Writing design specs, preparing handoffs, documenting component behavior, creating implementation guides.

Assessment-to-action pipeline

When a user brings an existing design for improvement, follow this pipeline:

1. Evaluate (/evaluate) — Run a quality assessment. Identify what's working, what's failing, and what's missing. 2. Prioritize — Rank findings by severity and impact. Critical anti-patterns first, then usability failures, then optimization opportunities. 3. Route — Direct each finding to the appropriate skill:

• Strategic misalignment → /strategize
• Research gaps → /investigate
• System architecture issues → /blueprint
• Flow breakdowns → /journey
• Information architecture problems → /organize
• Content/copy issues → /articulate
• Accessibility failures → /include
• Platform adaptation issues → /transpose
• Localization issues → /localize
• Measurement problems → /measure
• Resilience/edge case gaps → /fortify
• Spec/handoff gaps → /specify

4. Verify — After remediation, re-evaluate to confirm the fix worked and didn't introduce new issues.

Multi-skill sequences

Common workflows that involve multiple skills in sequence:

New product design: /strategize → /investigate → /blueprint → /journey → /organize → /articulate → /include → /specify

UX audit and remediation: /evaluate → (route by findings) → /evaluate (verify)

Content overhaul: /investigate (content audit) → /articulate (voice/strategy) → /organize (structure) → /include (accessibility review)

Platform expansion: /evaluate (current platform) → /transpose (adaptation) → /include (platform-specific accessibility) → /specify (engineering handoff)

International launch: /investigate (cultural research) → /localize (adaptation) → /articulate (content) → /include (accessibility for new contexts)

Loop-backs and exit conditions

Design is iterative. Findings from one skill routinely invalidate assumptions in another, and the right response is to loop back. Uncontrolled loops waste cycles and frustrate users — loop-backs are useful only when they're bounded.

Healthy loop-back patterns:

• /evaluate → routed fix (/journey, /articulate, etc.) → /evaluate (verify)
• /measure → strategic assumption contradicted → /strategize (reframe with evidence)
• /investigate → research reveals misframed problem → /strategize (rescope)
• /philosopher → assumption challenged → return to the skill that was active

Guardrails:

1. Loop-backs require a named triggering condition, not a feeling. "Results are worse than hoped" is not a trigger. "Metrics contradict a documented strategic assumption" is. Name what changed before reopening a previous skill. 2. Explicit human checkpoint before re-triggering. No skill automatically bounces back to another. Pause and ask the user: "Findings suggest reopening [skill] because [specific assumption] appears wrong. Reopen, park, or continue?" 3. Loop budget: 2 backward transitions per engagement. Going back once is reflection. Twice is genuine reframing. A third is a signal the engagement is mis-scoped — stop, surface the tension, and re-establish context rather than looping. 4. Every loop has a written exit condition. "Reopen /strategize until the audience is validated by 5+ interviews." "Re-measure for 14 days post-deploy, then commit or roll back." If you can't state the exit, you're not looping — you're spinning. 5. When in doubt, park the loop. A loop an AI agent can't resolve in two iterations is almost always a decision that belongs to the human, not a problem to churn on.

---

Reference Document Index

Intent is backed by eight reference documents containing deep, practitioner-level knowledge. These are the knowledge backbone that gives the system genuine expertise.

---

Voice & Approach

Intent speaks the same way across all skills and references — conversational but rigorous, specific but not pedantic.

Lead with reasoning. Don't say "add a confirmation dialog." Say "this action is irreversible and the trigger is a single tap next to a common action — add a confirmation dialog to prevent accidental data loss."

Name the principle. When making a recommendation, connect it to the principle it comes from. "This violates user autonomy because..." or "This fails under real conditions because..." Principles without application are platitudes. Application without principles is arbitrary.

Be honest about trade-offs. Almost every design decision involves a trade-off. Name both sides. "Infinite scroll increases content consumption but removes stopping cues, which is a problem for users prone to compulsive usage" is more useful than either "infinite scroll is bad" or "infinite scroll increases engagement."

Cite the catalog. When identifying an anti-pattern, name it specifically: "This is Confirmshaming (Category 1, High severity) — the opt-out copy uses guilt to discourage the user's stated preference." Specificity makes the assessment actionable.

Respect the user's expertise. The user might be a junior designer learning the field or a VP of Product with 20 years of experience. Adjust depth and explanation to what they need, not a fixed level. When in doubt, explain the reasoning and let them decide whether the context was necessary.

---

What This System Believes

These are not preferences. They are positions, held with conviction and open to evidence.

1. UX is not decoration. It's the structural quality of how a product serves human needs. It includes research, strategy, architecture, interaction, content, accessibility, ethics, and measurement. Reducing it to "make it look nice" is a category error.

2. Ethics are not optional. Designing against user interest — through manipulation, deception, or exploitation — is a professional failure regardless of business justification. "But it increases conversion" is not a defense.

3. Accessibility is not a feature. It's a baseline. A product that doesn't work for people with disabilities is an incomplete product, the same way a product that crashes on launch is an incomplete product.

4. Research is not a phase. It's a continuous practice. You don't do research once at the beginning and then stop. You research before, during, and after — because users, contexts, and needs change.

5. Measurement without ethics is surveillance. Tracking user behavior to improve their experience is design. Tracking user behavior to exploit them more effectively is surveillance. The difference is intent — and that intent should be explicit.

6. Design decisions are traceable. Every recommendation in this system can be traced back to a principle, a research finding, a heuristic, or an ethical position. "It feels right" is a starting point for investigation, not a justification for shipping.

Accessibility Foundations

WCAG 2.2 for Designers

The Web Content Accessibility Guidelines are organized around four principles: Perceivable, Operable, Understandable, Robust (POUR). Most designers encounter WCAG as a compliance checklist. That's the wrong frame. WCAG is a design specification — it tells you what your design must achieve for the full spectrum of human ability.

Perceivable

Information and interface components must be presentable to users in ways they can perceive. This means: not everyone sees, not everyone hears, not everyone processes information the same way.

Text alternatives (1.1): Every non-text element that conveys information needs a text equivalent. Images need alt text. Icons need labels. Charts need data tables or summaries. Video needs captions and audio description. The question is always: if this visual element disappeared, would the user lose information?

How designers get this wrong: Decorative images with verbose alt text (screen readers will read "stock photo of a diverse team collaborating in a modern office" for every page — exhausting). Informative images with empty alt text. Complex charts with alt text that says "chart" instead of describing the data. Icons without any programmatic label. The fix is intentional alt text: describe what the image communicates, not what it depicts.

Time-based media (1.2): Video needs captions (synchronized text of spoken content) and audio description (narration of visual content). Audio needs transcripts. Live content needs real-time captions. This isn't just for deaf users — captions serve anyone in a noisy or quiet environment.

Adaptable (1.3): Information structure must be programmatic, not just visual. A heading that's bold and large but coded as a <div> is invisible to screen readers. A data table that's built with positioned divs instead of <table> elements loses its row/column relationships. Design decisions about hierarchy, grouping, and sequence must be implementable as semantic structure.

Distinguishable (1.4): Contrast ratios: 4.5:1 for normal text, 3:1 for large text (18px+ or 14px+ bold), 3:1 for UI components and graphics. These are minimums — aim higher for body text. Color must not be the only means of conveying information — a red error border needs an icon or text too, because not everyone perceives red. Text must be resizable to 200% without loss of content or functionality.

New in 2.2 — Dragging movements (2.5.7): Any functionality that uses dragging must have a non-dragging alternative. Drag-to-reorder must also offer move-up/move-down buttons or an alternative input method.

Operable

Users must be able to operate the interface through multiple input methods — not just mouse and touch.

Keyboard accessible (2.1): Everything must work with a keyboard. Every interactive element must be focusable and activatable. No keyboard traps — users must be able to navigate away from any component. Custom keyboard shortcuts must not conflict with browser or assistive technology shortcuts.

Enough time (2.2): If content has a time limit, users must be able to turn off, adjust, or extend the limit. Session timeouts need warnings and extension options. Auto-updating content needs pause/stop controls. Moving or auto-playing content must be stoppable.

Seizures and physical reactions (2.3): No content that flashes more than three times per second. This isn't theoretical — flashing content can trigger seizures in people with photosensitive epilepsy. Motion animations should be reducible (respect prefers-reduced-motion).

Navigable (2.4): Provide a skip navigation link (first focusable element, links to main content). Use descriptive page titles. Focus order must be logical and predictable — typically matching visual reading order. Link text must make sense out of context ("Read more" fails this; "Read our accessibility policy" passes). Headings and labels must be descriptive.

New in 2.2 — Focus not obscured (2.4.11): When a component receives keyboard focus, it must not be entirely hidden by other content (sticky headers, modals, toasts). At least partially visible.

New in 2.2 — Target size (2.5.8): Interactive targets must be at least 24x24 CSS pixels, with certain exceptions (inline links, native browser controls). This benefits motor-impaired users, touch users, and everyone with large fingers on small screens.

Understandable

Content and interface behavior must be understandable to the user.

Readable (3.1): Set the language of the page (lang attribute). Identify changes in language within the page. Define unusual words, abbreviations, and jargon. These seem like developer concerns, but they're design decisions — the designer decides what terminology to use and how to explain it.

Predictable (3.2): Components that look the same should work the same, everywhere in the product. Navigation should be consistent across pages. Changes of context (opening a new window, submitting a form, changing focus) should only happen when users expect them — not on focus, not on input without warning.

Input assistance (3.3): Errors must be identified and described in text. Labels and instructions must be provided for user input. Error suggestions must offer correction when possible. Important submissions (financial, legal, data modification) must be reversible, verified, or confirmed.

New in 2.2 — Redundant entry (3.3.7): Don't ask users to re-enter information they've already provided in the same process. If shipping and billing address are the same, offer a checkbox instead of making them type it twice. Autocomplete where possible.

New in 2.2 — Accessible authentication (3.3.8): Authentication should not require cognitive function tests (puzzles, memory tasks) unless an alternative is provided. Support password managers, passkeys, and copy-paste for verification codes.

Robust

Content must be robust enough that it can be reliably interpreted by a wide variety of user agents, including assistive technologies. This is primarily an implementation concern, but designers influence it through component choices and specification clarity.

---

Assistive Technology Landscape

Designing for accessibility requires understanding how people actually use assistive technology — not just checking boxes.

Screen Readers

Software that converts on-screen content to speech or braille. Major screen readers: JAWS (Windows, professional contexts), NVDA (Windows, free and open source), VoiceOver (macOS/iOS, built-in), TalkBack (Android, built-in), Narrator (Windows, built-in).

How people use them: Not by reading every word on the screen. Experienced screen reader users navigate by headings (H key), landmarks (D key in JAWS), links (Tab), and form elements. They skim structure first, then dive into content. A page without proper headings and landmarks is like a printed page without any formatting — technically readable, practically unusable.

Common misconception: "Screen reader users are blind." Many screen reader users have partial vision and use the screen reader in combination with magnification or high contrast. Design for the combination, not the assumption.

Switch Access

Users who can't use a mouse, touchscreen, or standard keyboard use switches — physical buttons, sips and puffs, eye-tracking, head movements — to navigate sequentially through interactive elements. Every focusable element is visited in order.

Design implication: The number of interactive elements on a page directly impacts switch users. A page with 50 clickable elements requires 50 switch presses to reach the last one. Group related actions. Provide skip mechanisms. Make the most common actions reachable first.

Voice Control

Software that allows users to navigate and interact by speaking commands. Dragon NaturallySpeaking (professional), Voice Control (macOS/iOS), Voice Access (Android).

Design implication: Voice control users say what they see — "click Submit," "click the search button." If a button's visible label doesn't match its programmatic name, voice commands fail. Ensure visible labels match accessible names exactly.

Magnification

Software or OS features that enlarge portions of the screen. Used by people with low vision who can see but need larger content.

Design implication: At 200% zoom, users see roughly one quarter of the original viewport. At 400%, one sixteenth. Layout must reflow — content that requires horizontal scrolling at zoom levels up to 400% fails WCAG 1.4.10. Think of magnification as a very narrow viewport, not a zoomed-in version of the full page.

---

Screen Reader Flow Design

Reading Order

Screen readers process the DOM in source order. Visual position (CSS) can differ from source order, creating a mismatch between what sighted users see and what screen reader users hear.

Rule: Visual order and source order must match. If a card shows a title, then an image, then a description, the source order should be title → image → description — not image → title → description with CSS repositioning.

Common failure: CSS Grid and Flexbox make it easy to reorder visually while leaving the source in a different order. This creates a disconnect that confuses screen reader users AND keyboard users (Tab order follows source order by default).

Landmarks

ARIA landmarks define the major sections of a page: banner, navigation, main, complementary, contentinfo, search, form. Screen reader users can jump between landmarks to navigate the page structure.

Minimum landmarks: Every page should have a <main> landmark, a <nav> landmark for primary navigation, and a <header> / <footer>. Multiple navigation landmarks need unique labels: "Primary navigation," "Footer navigation."

Live Regions

Content that updates dynamically (notifications, chat messages, status changes, real-time data) needs to announce itself to screen readers using ARIA live regions.

aria-live="polite": Announce when the screen reader is idle. Use for non-urgent updates (status messages, search result counts).

aria-live="assertive": Interrupt current speech to announce. Use for urgent information (error alerts, time-sensitive warnings). Use sparingly — frequent assertive announcements make the interface unusable.

role="alert": Implicitly assertive. Use for error messages and critical warnings. An element with role="alert" will be announced immediately when its content changes or when it's added to the DOM.

role="status": Implicitly polite. Use for status messages and non-critical updates. "Your file was saved successfully" is a status, not an alert.

---

Keyboard Navigation Design

Focus Management

Focus must be visible. The default browser focus ring is ugly but functional. If you replace it with a custom style, the custom style must be at least as visible — 2px solid outline with sufficient contrast against the background. Removing focus styles (outline: none without replacement) is an accessibility failure.

Focus must be logical. Tab order should follow visual reading order: left to right, top to bottom (in LTR languages). Using tabindex values greater than 0 to force a non-standard order creates confusion for keyboard and screen reader users.

Focus must be managed during UI changes. When a modal opens, focus moves to the modal. When it closes, focus returns to the trigger. When content is deleted, focus moves to the next logical element. When an inline edit completes, focus moves to the saved content. Every dynamic UI change needs a focus management plan.

Tab Order

Focusable elements: Links, buttons, form inputs, textareas, selects, and elements with tabindex="0". Only interactive elements should be in the tab order. Non-interactive elements (headings, paragraphs, divs) should not be made focusable unless they serve as custom interactive widgets.

Skip links: The first focusable element on the page should be a "Skip to main content" link. This saves keyboard and screen reader users from tabbing through the entire navigation on every page. The skip link should be visually hidden until focused (visible when it matters, invisible when it doesn't).

Keyboard Patterns for Custom Components

Native HTML elements (buttons, links, inputs) come with built-in keyboard behavior. Custom components need manual keyboard implementation following WAI-ARIA Authoring Practices.

Tabs: Arrow keys move between tabs. Tab key moves to the tab panel content. Home/End keys move to first/last tab.

Menus: Arrow keys move between items. Enter/Space activates. Escape closes. Type-ahead selects items by first letter.

Modals/Dialogs: Focus trapped inside while open. Escape closes. Focus returns to trigger on close. Background content is inert (aria-hidden="true" or the inert attribute).

Tree views: Arrow keys navigate. Right arrow expands a node. Left arrow collapses or moves to parent. Enter activates.

---

Cognitive Accessibility

Accessibility isn't only about sensory and motor ability. Cognitive and learning disabilities affect more people than all physical disabilities combined.

Plain Language

Use simple, direct language. Short sentences. Common words. Consistent terminology. Define technical terms in context. This benefits everyone but is essential for users with cognitive disabilities, learning disabilities, low literacy, or non-native language proficiency.

Consistent Patterns

Do the same thing the same way everywhere. If "delete" is the word in one place, don't use "remove" in another. If the primary action is on the right in one dialog, it should be on the right in all dialogs. Consistency reduces the cognitive load of learning and remembering interface behavior.

Error Prevention

Prevent errors before they happen rather than reporting them after. Constrain inputs (datepickers instead of free-text date fields). Provide smart defaults. Show real-time formatting examples. Disable invalid combinations. For consequential actions, show a preview before committing.

Simplify Processes

Break multi-step processes into clear, named stages with progress indicators. Allow saving progress and returning later. Don't require users to hold information in memory across steps. Show summaries before final submission.

---

Inclusive Design Beyond Disability

Accessibility standards address permanent disability. Inclusive design goes further — designing for the full range of human diversity, including situational and temporary impairment.

Situational Impairment

• One-handed use: Carrying a child, holding a subway pole, arm in a sling. Touch targets and gestures should work one-handed.
• Bright sunlight: Outdoor use makes low-contrast text invisible. Sufficient contrast isn't just for low vision — it's for Tuesday afternoon on a park bench.
• Noisy environments: Audio content is useless on a construction site or in a crowded bar. Captions and visual indicators serve everyone in these contexts.
• Divided attention: Driving (please don't), cooking, watching kids. Interfaces used during divided attention need to be operable with minimal visual engagement.

Low Literacy

Over 50% of U.S. adults read below a 6th-grade level (NAAL, 2003). Globally, 773 million adults lack basic literacy skills (UNESCO). Designing for low literacy means: short sentences, common words, visual cues alongside text, numbered steps for instructions, and avoiding dense paragraphs.

Older Devices and Low Bandwidth

Not everyone has a current-generation smartphone or fast internet. A significant portion of the global population accesses the internet on 3G or slower connections, on devices with limited memory and processing power. Accessibility means designing for these conditions: smaller page weights, progressive enhancement, functional offline states, and interfaces that work without JavaScript when possible.

Aging

Age-related changes affect vision (presbyopia, reduced contrast sensitivity), hearing (high-frequency loss), motor control (reduced precision, slower response time), and cognition (slower processing, reduced working memory). These are not disabilities — they're the universal human trajectory. Design for the user your product's audience will become, not just the user they are today. Larger text, higher contrast, larger touch targets, simpler navigation, and forgiving error handling serve the aging population — and make the product better for everyone.

Content Strategy

Voice Framework Methodology

A voice framework is not a list of adjectives. It's a system that produces consistent, recognizable writing across every author, channel, and context in your product. Building one requires methodology, not inspiration.

Step 1: Brand Attribute Identification

Start with the brand's core attributes — the 3-5 characteristics that define how the organization wants to be perceived. These come from brand strategy, not from the content team's preferences.

Process: Gather stakeholders (product, marketing, executive, support). Ask each: "If our product were a person, how would you describe their personality?" Collect independently, then compare. Where there's alignment, you have a genuine attribute. Where there's divergence, you have a conversation that needs to happen before writing guidelines.

Common pitfall: Every brand wants to be "innovative, friendly, and trustworthy." These are not differentiating attributes — they're table stakes. Push for specificity. Not "friendly" — "the kind of friend who tells you the truth even when it's uncomfortable." Not "innovative" — "explains complex things simply, like a scientist at a dinner party."

Output: 3-5 brand attributes with one-paragraph descriptions that include what the attribute means AND what it doesn't mean. Example: "Direct — we get to the point. We don't pad copy with qualifiers or hide bad news behind hedging language. Direct does not mean blunt or cold — we're straightforward because we respect the reader's time, not because we don't care about their feelings."

Step 2: Voice Principles

Translate brand attributes into writing principles. Each attribute generates 1-2 specific principles that a writer can act on.

Attribute → Principle pattern:

• "Direct" → "Lead with the action. If the user needs to do something, start with the verb."
• "Empathetic" → "Acknowledge the user's situation before providing instructions. Error messages start with what happened, not what to do."
• "Expert" → "Use precise terminology when it helps, but always define it in context. Never use jargon as a substitute for explanation."

Test: Can a new writer read these principles and produce copy that sounds like your product without seeing any examples? If not, the principles are too vague.

Step 3: Tone Spectrum

Voice is constant. Tone shifts by context. A voice framework must define how tone changes across different situations while the voice remains recognizable.

Map tone across a spectrum for each of these dimensions:

• Formality: casual ←→ formal
• Emotion: warm ←→ matter-of-fact
• Authority: peer ←→ expert
• Complexity: simple ←→ technical

Then map where different product contexts fall on each spectrum. Onboarding might be casual, warm, peer, simple. Legal disclosures might be formal, matter-of-fact, expert, technical. Error messages might be casual, warm, expert, simple.

Step 4: Writing Guidelines

Concrete rules that implement the voice principles. These are the operational layer — the "how to write" instructions.

Include:

• Sentence length targets (aim for 15-20 words average; break up longer sentences)
• Active vs. passive voice guidance (active for actions, passive acceptable for system states: "Your file was saved" vs. "We saved your file")
• Pronoun usage (we/you/they — and when to use each)
• Capitalization conventions (sentence case vs. title case, and where each applies)
• Punctuation rules (Oxford comma? Exclamation marks? Ellipses?)
• Vocabulary preferences and prohibited words
• Inclusive language standards

---

Tone Matrix

The tone matrix maps how voice shifts across product contexts. This is the most practical artifact in the content strategy toolkit — it's what writers actually reference daily.

---

Content Modeling

Content modeling defines the structure of content independently from its presentation. Good content modeling makes content reusable across channels, localizable across languages, and maintainable at scale.

Structured Content

Every piece of content should be modeled as structured data, not as a blob of formatted text.

Example: An event

• Title (plain text, max 80 characters)
• Description (rich text, max 500 characters)
• Short description (plain text, max 140 characters — for cards and previews)
• Date and time (ISO 8601 — never store as formatted text)
• Location (structured: venue name, address, coordinates)
• Category (controlled vocabulary)
• Image (with alt text — required, not optional)
• Status (draft, published, cancelled)

Why structure matters: A structured event can render as a card, a list item, a calendar entry, a notification, a social media post, or a search result — each using the appropriate fields. A blob of HTML can only render as itself.

Localization-Ready Content

Content that will be translated needs to be modeled for translation from the start. Retrofitting localization is orders of magnitude more expensive than building it in.

Rules:

• Separate content from presentation. Don't hardcode text in templates, components, or images.
• Don't concatenate strings. "You have " + count + " messages" breaks in languages with different word order. Use ICU MessageFormat or equivalent: "{count, plural, one {You have 1 message} other {You have # messages}}".
• Don't assume text length. German text is typically 30% longer than English. Japanese may be shorter. Design layouts that accommodate variation.
• Don't embed text in images. It can't be translated, can't be read by screen readers, and can't be searched.
• Provide context for translators. "Save" the verb is different from "Save" the noun in many languages. String identifiers like button.save_changes carry more context than string_47.

Content Reuse

Model content once, use it everywhere. But be deliberate about what's shared and what's unique.

Shared content: Legal text, feature descriptions, pricing details — anything that must be consistent across contexts. Change once, update everywhere. Store in a single source.

Adapted content: The same information, but with different length or tone for different contexts. An event description might be 500 characters on the detail page and 140 characters on a card. Model both as distinct fields — don't truncate the long version.

Unique content: Context-specific text that doesn't make sense anywhere else. An error message for a specific form field. A tooltip for a specific feature. Don't over-abstract — not everything needs to be reusable.

---

Microcopy Pattern Library

Microcopy is the small text that guides users through interactions. It's the most impactful writing in a product — a single word change in a button label can shift conversion rates by double digits.

Tooltips

When to use: To explain unfamiliar concepts, clarify ambiguous labels, or provide additional context for a decision. NOT as a substitute for a clear label.

Length: One to two sentences. If a tooltip needs a paragraph, the feature needs better design, not longer tooltips.

Trigger: Hover on desktop (with focus equivalent for keyboard), tap on mobile. Never put essential information in tooltips — they're invisible until triggered.

Pattern: "[What this is/does]. [Why it matters or what to consider]." Example: "Two-factor authentication. Adds a second verification step using your phone when you sign in."

Placeholder Text

What it's for: Format examples and input hints. "name@company.com" in an email field. "DD/MM/YYYY" in a date field.

What it's NOT for: Field labels. Instructions. Anything the user needs to reference while typing. Placeholder text disappears on focus — if the information matters, put it in a persistent label or help text.

Accessibility note: Placeholder text typically renders in low contrast, making it hard to read for many users. Never rely on placeholder text as the only source of information.

Confirmation Messages

Success: What happened + what the user can expect next. "Your payment was processed. You'll receive a confirmation email within a few minutes." Not just "Success!"

Pending: What's happening + when to expect resolution. "We're verifying your identity. This usually takes 1-2 business days." Not just "Processing..."

Failure: What went wrong + what to do. "Your payment was declined by your bank. Try a different card or contact your bank." Not just "Payment failed."

Empty States

The first screen a new user sees is almost always an empty state. It's the product's first impression — and most products waste it.

Good empty states contain: 1. What this area is for (education) 2. How to add the first item (action) 3. Why it's worth doing (motivation)

Example: "This is your project dashboard. You'll see all your active projects here once you create them. Create your first project to get started." + a prominent "Create Project" button.

Bad empty states: A blank page. A lonely icon. "No data." These communicate nothing and leave the user stranded.

---

Terminology Governance

Inconsistent terminology is one of the most common causes of user confusion and one of the easiest to prevent.

Building a Terminology Glossary

Identify terms that need governance: Technical terms, product-specific concepts, feature names, status labels, action verbs. If two writers might use different words for the same thing, it needs a glossary entry.

For each term, document:

• The canonical term (the one we use)
• Synonyms we don't use (and why — "we say 'workspace,' not 'project space' or 'dashboard'")
• Definition (in user-facing language, not internal language)
• Context for use (where this term appears and what it means in each context)

Naming Conventions

Actions should be specific verbs. "Save" not "OK." "Delete permanently" not "Remove." "Send invitation" not "Submit." The button label should tell the user exactly what will happen when they click it.

Status labels should be past participles or adjectives. "Sent," "Draft," "Active," "Archived" — states the item is in. Not verbs ("Send," "Archive") which imply actions.

Consistency across surfaces. If the mobile app says "Log in" and the website says "Sign in," one of them is wrong. Pick one and enforce it everywhere.

Jargon Management

Rules: 1. If the user needs a technical term to use the product, define it the first time it appears — in context, not in a glossary page nobody will visit. 2. If a simpler word exists, use it. "Use" not "utilize." "Start" not "initiate." "End" not "terminate." 3. Internal terminology never reaches the user. The user doesn't know what "SKU" means, that "KYC" stands for Know Your Customer, or that "RBAC" is role-based access control. Translate. 4. When technical terms are unavoidable (API, URL, CSV), use them but don't assume understanding. "Download as CSV (a spreadsheet format)" on first appearance.

---

Readability and Plain Language

Readability Scoring

Flesch-Kincaid Grade Level is the most widely used readability metric. It estimates the U.S. school grade level required to understand the text. Target: grade 6-8 for consumer products, grade 8-10 for professional tools, grade 10-12 for expert documentation.

How to improve readability scores:

• Shorter sentences (average 15-20 words)
• Shorter words (prefer one and two-syllable words)
• Active voice (subject → verb → object)
• One idea per sentence
• Lists instead of long paragraphs

Limitations: Readability scores measure surface features (word length, sentence length), not comprehension. A text can score at grade 6 and still be incomprehensible if the concepts are poorly organized or the terminology is unfamiliar. Use readability scores as a quick check, not a quality guarantee.

Plain Language Principles

Plain language is not simple language. It's clear language. The goal is that the reader can find what they need, understand what they find, and use that understanding to act.

Federal Plain Language Guidelines (plainlanguage.gov) principles: 1. Write for your audience — use their vocabulary, address their needs 2. Organize for the reader — most important information first 3. Use short sentences and paragraphs 4. Use everyday words — avoid jargon, legalese, and unnecessary technical language 5. Use active voice — "We'll review your application" not "Your application will be reviewed" 6. Use present tense — "This deletes your account" not "This will delete your account" 7. Use "you" and "we" — direct address is clearer than third person 8. Use lists and tables for complex information 9. Use meaningful headings

In product interfaces specifically:

• Button labels should be verbs that describe the action: "Save changes," "Create project," "Send message"
• Error messages should be sentences: subject, verb, solution
• Instructions should start with the goal, then the steps: "To export your data, go to Settings > Export"
• Don't use "please" in every instruction — it inflates word count and becomes invisible. Reserve politeness for when you're asking the user to do something inconvenient

Ethical Design

Anti-Pattern Remediation Guide

The master skill catalogs anti-patterns. This document explains how to fix them — and how to design the ethical alternative from the start.

Deceptive Patterns → Honest Alternatives

Bait and Switch → Consistent Delivery. What you show is what you deliver. If a button says "Download," it downloads. If a link says "Learn more," it teaches. Test by asking: if a user described what just happened, would their description match the label they clicked?

Trick Questions → Plain Language Choices. Every option should be stateable as an affirmative: "Yes, send me emails" / "No, don't send me emails." Never use double negatives ("Uncheck to not receive..."). Never combine multiple consents into one checkbox. Test by reading the question aloud — if a colleague gets confused, users will too.

Visual Misdirection → Equal Visual Weight. When presenting choices, the "decline" or "opt-out" option should be equally visible — same size, same visual weight, same position prominence. The user's preferred choice, not the business's preferred choice, should determine which option they pick. Test: cover the page with your hand and peek — can you see both options equally?

Hidden Costs → Upfront Pricing. Show the total cost, including taxes, fees, and shipping, before the user enters any personal information. The Baymard Institute found that 48% of cart abandonment is caused by extra costs shown too late. The fix isn't just ethical — it converts better.

Confirmshaming → Neutral Opt-Out. Opt-out text should be factual, not emotional. "No thanks" is fine. "No thanks, I hate saving money" is manipulation. The test is simple: would you say the opt-out text to someone's face without feeling embarrassed?

Sneak into Basket → Explicit Additions Only. Nothing enters a cart, plan, or order without a deliberate user action. Pre-selected add-ons, bundled insurance, and automatic upsells all fail this test. If the user didn't click "add," it shouldn't be there.

Default Manipulation → Respectful Defaults

Prechecked Consent → Unchecked by Default. GDPR requires this explicitly. But beyond regulation — consent means nothing if it's pre-selected. Every consent checkbox should start unchecked. Every permission should start un-granted. The user's first interaction should be a choice, not an override.

Opt-Out Burden → Symmetrical Effort. The effort to leave should mirror the effort to join. If signing up takes one click, cancellation should take one click. The FTC's "click to cancel" rule codifies this, but the principle predates the rule: asymmetric friction is manipulation.

Forced Continuity → Clear Trial Endings. Before a trial ends: notify the user (email and in-app, not just email). On the transition day: require explicit confirmation before charging. After charging: provide easy refund for the first billing period. Making cancellation hard doesn't create loyal customers — it creates resentful ones who warn others.

Urgency Fabrication → Honest Scarcity

Fake Timers → Real Deadlines Only. If a deadline is real (event starts at 8pm, sale ends Sunday), show it. If there's no real deadline, don't invent one. A timer that resets when the page refreshes is not a deadline — it's a lie.

Fabricated Scarcity → Actual Inventory. If you show stock levels, they should be real. "Only 2 left" when you have 2,000 in the warehouse is fraud by implication. If demand genuinely fluctuates, show real-time data. Otherwise, don't show numbers at all.

Fake Social Proof → Real Activity. "15 people are viewing this" should reflect actual concurrent viewers, not a random number generator. Fabricated social proof is straightforward deception. Real social proof (verified reviews, actual purchase counts) builds genuine trust.

Addictive Design → Respectful Engagement

Infinite Scroll → Natural Boundaries. Pagination, "load more" buttons, or session summaries create natural stopping points. This doesn't reduce engagement — it shifts it from compulsive to intentional. Instagram's "You're all caught up" is a partial fix; actual pagination is more honest.

Variable Ratio Reinforcement → Predictable Value. Notifications should arrive because something meaningful happened, not because the algorithm determined this is the optimal moment to re-engage. Content should be organized, not randomly dispensed. The value should be in the content, not in the unpredictability of its delivery.

Streak Manipulation → Progress Without Punishment. If you track streaks, breaking one should carry no penalty. "You had a 30-day streak! Start a new one?" is fine. "You lost your 30-day streak forever" is manufactured loss aversion. Duolingo's streak freeze is an admission that their streak mechanic creates unhealthy obligation.

---

Regulatory Landscape

GDPR (EU, 2018)

The General Data Protection Regulation is the most comprehensive privacy regulation in force. Key requirements for designers:

Consent (Article 7, Recitals 32, 42, 43):

• Must be freely given — no bundling consent with service access unless data processing is genuinely necessary for the service
• Must be specific — separate consent for separate purposes
• Must be informed — plain language, no legalese
• Must be unambiguous — affirmative action required; silence, pre-ticked boxes, and inactivity do not constitute consent
• Withdrawal must be as easy as giving consent — no asymmetric flows

Data Minimization (Article 5(1)(c)):

• Collect only what's necessary for the stated purpose
• Don't collect data "in case we need it later"
• Design forms to request minimum required fields

Right to Erasure (Article 17):

• Users can request deletion of their data
• Deletion must be actual, not just hiding the record
• Design systems need real deletion capabilities, not just soft deletes

Privacy by Design (Article 25):

• Data protection must be built into the design of systems, not bolted on
• Default settings must be the most privacy-protective option
• This is a legal requirement, not a best practice

Enforcement reality: Fines up to 4% of global annual revenue or 20 million euros, whichever is higher. As of 2024, cumulative GDPR fines exceed 4 billion euros. Meta alone has been fined over 2 billion euros.

FTC (United States)

The Federal Trade Commission uses its authority under Section 5 (unfair or deceptive acts) to pursue dark patterns.

Key enforcement actions:

• Epic Games / Fortnite (2022): $520M settlement for dark patterns targeting children, including confusing purchase flows and unauthorized charges
• Amazon Prime (2023): FTC sued over "Iliad" — Amazon's internal name for a cancellation flow deliberately designed to be confusing
• Age of Empires / Microsoft (2023): Enforcement against manipulative subscription practices

"Click to Cancel" Rule (2024):

• Businesses must make cancellation as easy as sign-up
• Must get affirmative consent before charging
• Must provide clear annual reminders for negative-option programs
• Applies to all negative-option marketing

FTC approach: Pattern-based enforcement. If a design practice is widespread and harmful, the FTC may issue a rule. Designers should treat FTC enforcement actions as de facto design standards.

COPPA (United States, 1998 / Updated 2013)

The Children's Online Privacy Protection Act applies to services directed at children under 13, or services that knowingly collect data from children under 13.

Design requirements:

• Verifiable parental consent before collecting personal information from children
• No behavioral advertising to children
• No conditioning participation on data collection beyond what's necessary
• Clear, prominent, and understandable privacy policies
• Data retention limits — delete when no longer needed

Design implication: If your product might have child users, design the entire data collection pipeline with COPPA in mind from the start. Retrofitting COPPA compliance is far more expensive than building it in.

California CPRA (2023) and Automated Decision-Making

Symmetry requirement: The means by which a consumer opts out of data sale/sharing must be symmetric with the means by which they opted in. If opt-in is one click, opt-out must be one click.

Do Not Sell/Share: Must provide a "Do Not Sell or Share My Personal Information" link on the homepage. This is a design requirement — the link must be visible, clear, and functional.

Automated decision-making: Consumers have the right to opt out of automated decision-making technology, including profiling. If your product uses algorithms to make decisions about users, they have the right to know and the right to opt out.

EU Digital Services Act (2024)

Dark pattern prohibition (Article 25):

• Online platforms must not design, organize, or operate interfaces in a way that deceives, manipulates, or materially distorts users' ability to make free and informed decisions
• Specific prohibition on: giving more prominence to certain choices, repeatedly requesting users to make choices they've already made, making cancellation harder than sign-up, and making choices non-neutral by default

Minor protection (Article 28):

• Platforms accessible to minors must implement appropriate measures to ensure a high level of privacy, safety, and security
• No targeted advertising based on profiling when the platform is aware the user is a minor

Algorithmic transparency (Articles 27, 38):

• Recommendation systems must explain the main parameters used
• Users must have at least one option not based on profiling

---

Design Ethics Frameworks

Values Sensitive Design (VSD)

Developed by Batya Friedman and colleagues at the University of Washington, VSD is a theoretically grounded approach to the design of technology that accounts for human values in a principled and comprehensive manner throughout the design process.

Three investigations: 1. Conceptual — Identify stakeholders (direct and indirect), identify values at stake, investigate how values might conflict 2. Empirical — Study how stakeholders actually apprehend and experience the technology and the values at stake 3. Technical — Analyze how specific technical properties support or hinder stakeholder values

Key values VSD investigates: Human welfare, ownership and property, privacy, freedom from bias, universal usability, trust, autonomy, informed consent, accountability, courtesy, identity, calmness, environmental sustainability.

Application to design: When making a design decision, identify which human values are at stake, who is affected (including non-users), and how the technical implementation supports or undermines those values. VSD doesn't tell you what to decide — it tells you what to consider.

Design Justice (Costanza-Chock, 2020)

Design Justice rethinks design processes by centering the people who are most impacted by design decisions, rather than the most powerful stakeholders.

Core principles: 1. Design to sustain, heal, and empower communities — prioritize impact on the most marginalized 2. Center the voices of those who are directly impacted by design outcomes 3. Prioritize design's impact on the community over the designer's intent 4. View change as emergent from accountable, accessible, and collaborative processes 5. See the role of the designer as a facilitator rather than an expert

Application: When your user research doesn't include the most vulnerable users of your product, your design will fail them. When your design team doesn't include diverse perspectives, your assumptions will go unchallenged. Design Justice argues that who participates in the design process determines who benefits from the design outcome.

Consequence Scanning

Developed by Doteveryone (now the Responsible Technology Institute), Consequence Scanning is a lightweight practice for identifying potential consequences of a product or feature.

Process: 1. Describe the product/feature in plain terms — what it does, who uses it, what data it touches 2. Brainstorm consequences across three dimensions:

• Intended consequences (what you're trying to achieve)
• Unintended but foreseeable consequences (what might happen that you didn't plan for)
• Unintended and unforeseeable consequences (what could happen that nobody predicted)

3. Categorize each consequence: positive, negative, or unclear 4. Decide for each negative consequence: mitigate (design around it), accept (document and monitor), or stop (don't build this)

When to use it: Before building new features, during design critiques, when expanding to new markets or user groups, when adding data collection, when changing algorithms or recommendation systems.

---

Consent Design Patterns

Consent is not a checkbox. It's a design system.

Principles of meaningful consent

Informed: The user understands what they're consenting to. This means plain language, specific descriptions, and concrete examples — not legal abstracts or blanket permissions. "We'll use your location to show nearby restaurants" is informed. "We process data to improve our services" is not.

Specific: Each consent is for one specific purpose. Bundled consent ("By using this service you agree to X, Y, Z, and also W") is not meaningful consent. Separate purposes get separate choices.

Freely given: The user can say no without losing access to the core service. If saying no makes the product unusable, consent wasn't free — it was coerced. The exception: when data processing is genuinely necessary for the service (you can't use a mapping app without sharing your location).

Revocable: The user can withdraw consent as easily as they gave it. A consent given with one toggle should be revocable with one toggle, in the same location, with the same effort.

Timely: Consent is requested at the moment it's relevant, not in a batch during onboarding. Ask for location permission when the user first accesses a location feature, not during account creation.

Consent interface patterns

Layered disclosure: Present a summary first ("We'd like to use your location to show nearby restaurants"), with a path to full detail ("Learn more about how we use location data"). The summary must be accurate and complete enough to make a real decision; the detail is for those who want it.

Granular controls: Separate toggles for separate purposes. Cookie consent should offer granular choices (analytics, marketing, personalization), not just "accept all / reject all." Permission dashboards should show each permission individually with clear descriptions.

Just-in-time consent: Request permissions when the user encounters the feature that needs them, with context that explains why. "To save your route, we need access to your location" at the moment of saving is far more meaningful than a bare permission prompt during onboarding.

Consent receipts: Show the user what they've consented to, when, and how to change it. A privacy dashboard that lists active consents with modification dates and one-click revocation is the gold standard.

Re-consent for material changes: When you change how you use data, don't bury it in a terms-of-service update. Re-request consent for the specific change, with clear explanation of what changed and why.

Common consent failures

• Consent walls that block the entire service until the user agrees to non-essential data processing
• "Accept all" buttons that are visually dominant while "Manage preferences" is small and gray
• Consent flows that take one click to accept but seven clicks to customize
• Withdrawal paths hidden in account settings behind three layers of navigation
• Pre-checked consent boxes (illegal under GDPR, deceptive everywhere)
• Bundled consent that combines essential service terms with optional marketing consent
• Consent prompts that appear on every visit because rejection isn't stored (deliberately or through incompetence)

Information Architecture

Navigation Patterns

Every navigation pattern is a trade-off between findability, scalability, and cognitive load. There is no universally correct pattern — there's the right pattern for your content, users, and context.

Hierarchical (Tree)

The most common pattern. Content is organized in nested categories: top-level → subcategory → item.

When it works: Large content sets with clear categorical relationships. Users have a general sense of what category their item belongs to. Content creators can maintain consistent categorization.

When it fails: When categories overlap significantly (is a "wireless mouse" in Accessories, Computers, or Peripherals?). When the hierarchy is deeper than 3-4 levels — users lose orientation quickly. When the hierarchy reflects organizational structure rather than user mental models ("Products" → "Business Unit A" → "Division 2" → "Team Alpha's Output").

Watch for: The "miscellaneous" drawer. If you have a category called "Other" or "General" that keeps growing, your hierarchy isn't working. Also: category names that mean something to the organization but nothing to users.

Hub-and-Spoke

A central hub connects to independent sections. Each section is largely self-contained. Users return to the hub to navigate between sections.

When it works: Mobile apps with distinct functional areas (Messages, Camera, Profile). Products where tasks are independent — you don't need to combine search results with your shopping cart. Kiosk interfaces and set-top boxes where the input model favors focused navigation.

When it fails: When users need to move fluidly between sections. When tasks span multiple sections. When the "hub" becomes a dumping ground for everything that doesn't fit in a spoke.

Watch for: The desire to add cross-links between spokes. Once spokes start linking to each other extensively, the hub-and-spoke model is fighting the user's actual workflow. Consider switching to a different pattern.

Flat

All content is at the same level. No hierarchy. Often paired with powerful search/filter.

When it works: Homogeneous content sets (a photo gallery, a list of transactions, a feed of posts). Content that doesn't have natural categories. Products with excellent search infrastructure.

When it fails: Diverse content types. Large content sets without strong search/filter. Users who browse rather than search.

Watch for: The illusion of flatness. Many "flat" architectures are actually filtered hierarchies — the user selects filters that create ad-hoc categories. That's fine, but the filter design is now your navigation design.

Faceted

Multiple independent dimensions for filtering the same content set. Users combine facets freely (color + size + price + brand).

When it works: E-commerce, search results, large databases with multiple attributes. When different users want to slice the same content differently. When the content has natural, independent attributes.

When it fails: When facets aren't independent (selecting "red" and "small" leaves zero results because small items don't come in red). When there are too many facets — 15 filter dimensions overwhelm rather than help. When the vocabulary is inconsistent across facets.

Watch for: Empty states. Faceted navigation creates combinatorial explosion — many facet combinations will return zero results. Design for graceful degradation: show result counts per facet before selection, disable facets that would return zero.

Dashboard

Multiple content types displayed simultaneously, typically with summary views that link to detail.

When it works: Monitoring and analytics products. Executive overviews. Products where users need to scan multiple information streams quickly. Return-visit products where users want a status snapshot.

When it fails: When the dashboard becomes the entire product — dashboards that require scrolling through 15 widgets have become a flat architecture by accident. When every stakeholder demands their metric on the dashboard, resulting in information overload. When the dashboard shows data but doesn't enable action.

Watch for: Dashboard-driven design, where every new feature gets a widget on the dashboard instead of its own proper location. Also: dashboards that show the same data to everyone when different roles need different views.

---

Taxonomy Design

Taxonomy is the art of naming and grouping things so that users can find them. Get taxonomy wrong and no amount of visual design will save the navigation.

Top-Down vs. Bottom-Up

Top-down starts with organizational logic: What are the major categories? How do they subdivide? This approach works when domain experts understand the structure well and users share that understanding. Risk: imposing a structure that makes sense internally but not to users.

Bottom-up starts with content items: What do we have? How do users group these things? What labels do they use? Card sorting is the primary method. This approach discovers the taxonomy users actually want. Risk: producing categories that are too specific or too numerous to function as navigation.

Best practice: Start bottom-up (card sorting to understand user mental models), then refine top-down (using domain expertise to fill gaps and resolve edge cases). Neither approach alone produces good taxonomy.

MECE Principle

Mutually Exclusive, Collectively Exhaustive. Every item belongs in exactly one category, and every item has a category to belong to.

Mutually Exclusive: If a user could reasonably place an item in two categories, the categories overlap. Fix by: making categories more specific, merging overlapping categories, or moving to faceted navigation where items can exist on multiple dimensions.

Collectively Exhaustive: If items exist that don't fit any category, the taxonomy has gaps. The test: take 50 random content items and try to categorize each one. If you hesitate on more than 10%, the taxonomy needs work.

Reality: True MECE is often unachievable for complex domains. When items genuinely belong in multiple categories, consider cross-referencing (the item lives in one place with links from others) or polyhierarchy.

Polyhierarchy

An item can appear in multiple places in the hierarchy. "Wireless Mouse" appears under both "Computer Accessories" and "Wireless Devices."

When to use: When card sorting consistently shows items being placed in multiple categories by different users. When the cost of "missing" an item (user can't find it) is higher than the cost of duplication.

Risks: Maintenance complexity (update in one place, forget the other). User confusion if the same item has different metadata or behavior in different locations. Navigation that feels unreliable — "I saw this somewhere else, which is the real one?"

Mitigation: Make one location canonical. Other appearances are clearly marked as cross-references. Maintain through automation, not manual duplication.

---

Mental Models

A mental model is the user's internal representation of how a system works. It doesn't need to match the actual system model — but the interface needs to match the user's mental model, or the user will fail.

Applied Mental Model Theory

The Design of Everyday Things (1988) distinguishes three models: 1. Design model — How the designer thinks the system works 2. System model — How the system actually works 3. User model — How the user thinks the system works

The interface is the bridge between design model and user model. When they align, the product feels intuitive. When they don't, the product feels broken — even if it works perfectly from a technical standpoint.

Common misalignments:

• Users think "deleting" removes something permanently; the system moves it to trash. (Mild — the system is more forgiving than expected.)
• Users think "saving" preserves their work; the system auto-saves and "save" does nothing visible. (Confusing — the action has no visible effect.)
• Users think each browser tab is independent; the system shares session state across tabs. (Dangerous — changes in one tab silently affect another.)

Design implication: Research mental models before designing navigation, naming, or interaction patterns. Card sorting reveals categorical mental models. Think-aloud usability testing reveals procedural mental models. Both are necessary.

---

Wayfinding

Romedi Passini and Paul Arthur's "Wayfinding: People, Signs, and Architecture" (1992) established principles for spatial navigation that translate directly to digital environments.

Core Wayfinding Principles

Orientation: Users must always know where they are. In physical space: "You Are Here" maps, visible landmarks, floor numbers. In digital space: breadcrumbs, highlighted navigation items, page titles, URL structure. A user who doesn't know where they are can't decide where to go next.

Route decision: At every decision point, users need enough information to choose correctly. In physical space: directional signs at intersections. In digital space: navigation labels, preview text, descriptions. If a user must click to learn whether a link leads somewhere useful, the wayfinding has failed.

Closure: Users need feedback that they've arrived. In physical space: room numbers, door labels, reception desks. In digital space: page headings that match the link they clicked, content that delivers what the label promised. The disorienting feeling of clicking "Privacy Settings" and landing on a page titled "Account Management" is a closure failure.

Progressive disclosure of the environment: Don't show the entire map at once. Show what's relevant at each decision point. In physical space: building directories show floors, not individual rooms. In digital space: top-level navigation shows categories, not subcategories. Reveal depth as the user navigates deeper.

Lynch's Spatial Elements

Kevin Lynch's "The Image of the City" (1960) identified five elements people use to navigate physical space. All five apply to digital products:

1. Paths — Routes through the environment. In digital: navigation flows, breadcrumbs, sequential processes. 2. Edges — Boundaries between regions. In digital: section dividers, navigation group boundaries, sidebar edges. 3. Districts — Areas with identifiable character. In digital: distinct product sections with consistent visual treatment (the "settings" area looks different from the "content" area). 4. Nodes — Strategic focus points. In digital: landing pages, dashboards, search results pages — places users pass through to reach destinations. 5. Landmarks — Reference points for orientation. In digital: logos, persistent headers, unique page layouts that users remember and navigate by.

---

Search Behavior Models

Not all search is the same. Marcia Bates' research and Gary Marchionini's framework identify fundamentally different search behaviors that require different design responses.

Known-Item Search

The user knows what they want and knows what it's called. They type a specific query and expect a specific result. Example: searching for "AirPods Pro" on an electronics site.

Design for: Speed. Autocomplete. Exact match ranking. Typo tolerance. The user's success metric is: did I find the exact thing, fast?

Exploratory Search

The user has a need but doesn't know the exact solution. They're browsing, comparing, learning. Example: searching for "wireless earbuds" to learn what options exist.

Design for: Browsing. Faceted filtering. Comparison. Rich result previews. Related items. The user's success metric is: did I learn enough to make a decision?

Re-finding

The user found something before and wants to find it again. Example: "I saw a pair of earbuds last week, they were around $150, I think they were Sony..."

Design for: History. Recently viewed. Favorites/bookmarks. Fuzzy search that handles partial recall. The user's success metric is: did I find that thing I saw before?

Don't-Know-What-I-Don't-Know

The user doesn't know the domain well enough to formulate a useful query. Example: a first-time investor searching a financial platform with no idea what terminology to use.

Design for: Guided discovery. Popular searches. Category browsing. Plain-language interpretation. "Did you mean..." suggestions that educate, not just correct.

---

Card Sort and Tree Test Methodology

Running a Card Sort

Preparation: 1. Select 30-60 content items that represent the full breadth of your content. Too few misses important distinctions; too many fatigues participants. 2. Write each item on a card (physical or digital — tools like OptimalSort, Maze, or UXtweak work well for remote sorts). 3. Use real content labels, not internal jargon. If the sort reveals that users don't understand a label, that's a finding.

Open sort protocol: 1. Ask participants to group cards in whatever way makes sense to them. No right answer. 2. After grouping, ask them to name each group. 3. Ask about any cards they found difficult to place. 4. Note: some participants will create many small groups; others will create few large groups. Both patterns are informative.

Closed sort protocol: 1. Provide pre-defined categories. 2. Ask participants to place each card in the category where they'd expect to find it. 3. Record placement and confidence. Low-confidence placements indicate taxonomy problems.

Analysis:

• Generate a similarity matrix showing how often items were grouped together.
• Use dendrograms or cluster analysis to identify natural groupings.
• Look for items that consistently end up alone or oscillate between groups — these are your taxonomy's problem children.
• Compare sort results with your proposed architecture. Where they diverge, the user is right and your architecture needs to adjust.

Running a Tree Test

Preparation: 1. Create a text-only representation of your navigation hierarchy. No visual design, no icons, no color. 2. Write 8-12 tasks that represent common user goals. Example: "Where would you find information about changing your password?" 3. Each task should have exactly one correct destination.

Protocol: 1. Show the top level of the tree. 2. Present a task. 3. Participant clicks into categories, drilling deeper until they think they've found the right place. 4. Record: path taken, success/failure, directness (did they backtrack?), time to completion.

Key metrics:

• Success rate: What percentage of participants found the correct answer? Below 70% for a task indicates a structural problem.
• Directness: What percentage went straight to the answer without backtracking? Low directness with high eventual success means the label worked but the location wasn't intuitive — users found it by elimination.
• First click: Where did participants click first? If the majority's first click is wrong, the top-level labels or categories are the problem.

Interpreting results:

• High success + high directness = the structure works for this task
• High success + low directness = findable but not intuitive; users had to hunt
• Low success + varied paths = structural problem; the item isn't where users expect it
• Low success + consistent wrong path = the item is in the wrong category, and users agree about where it should be (which tells you where to move it)

Interaction Patterns

Form Design Principles

Forms are where users exchange value with your product. Every unnecessary field, confusing label, or unhelpful error message is friction between the user and their goal. The research on form design is extensive and remarkably consistent.

One Thing Per Page

The Government Digital Service (GDS) pattern, validated across millions of transactions: each screen asks one question or collects one piece of information. Not one form field — one conceptual unit.

Why it works: Reduces cognitive load. Each page has a clear purpose. Error recovery is simpler — the error is on this page, about this thing. Progress feels tangible. Mobile performance improves (less content per load). Analytics are more granular (you know exactly where drop-off occurs).

When to bend it: Closely related fields that users think of as one concept (first name + last name, city + state + zip). Editing flows where users need to see multiple fields to understand context. Expert tools where speed matters more than guidance.

When not to bend it: Checkout flows. Registration. Any flow where drop-off is a risk. Any flow used on mobile.

Inline Validation Timing

When to validate is as important as how to validate. Get the timing wrong and validation becomes harassment.

Validate on blur (leaving a field), not on keystroke. Validating while the user is still typing is hostile — they haven't finished their input and you're already telling them it's wrong. Luke Wroblewski's research (2009) confirmed that inline validation improves completion rates, but only when triggered after the user leaves the field.

Exception: password strength. Real-time feedback on password requirements is one of the few cases where keystroke-level validation helps, because the user is building toward a goal and needs to know the criteria as they type.

Exception: character counts. If a field has a maximum length, show the remaining count as the user types. Don't wait until they've written a paragraph to tell them the limit is 140 characters.

Validate once, then validate on change. After a field shows an error, re-validate on every change so the error disappears the moment the input becomes valid. Don't make users re-submit the form to discover they've fixed the error.

Field Grouping

Related fields should be visually and semantically grouped. Ungrouped forms feel longer than they are.

Use fieldsets for conceptual groups: Personal information, payment details, shipping address — each is a group. The <fieldset> element with a <legend> provides both visual grouping and accessibility structure.

Limit visible fields. If a form has 20 fields but only 6 are relevant based on previous answers, show 6. Conditional visibility reduces perceived complexity without hiding options. The user sees a short form that adapts, not a long form that wastes their time.

Single-column layout. Matteo Penzo's eye-tracking research (2006) and Baymard Institute's studies consistently show that single-column forms outperform multi-column forms. Users scan vertically; multi-column layouts create ambiguous reading order and increase completion time.

Smart Defaults

Default values should serve the user's most likely intent, not the business's preferred outcome.

Good defaults: Country pre-filled from IP geolocation. Date pre-filled to today. Quantity defaulting to 1. Shipping address copied from billing address with one click.

Bad defaults: Pre-selected premium tier. Pre-checked marketing consent. Default to most expensive option. Privacy settings defaulting to "share with everyone."

The test: If 80% of users would choose this value, it's a good default. If the default primarily benefits the business, it's manipulation (see the anti-pattern catalog).

---

State Machines for UI

Every interactive component exists in multiple states. Enumerating those states before building prevents the most common class of UI bugs: the states nobody designed for.

Universal Component States

Default/Resting — The component as it appears before any interaction. This is what the user sees first. It must communicate: what is this, and what can I do with it?

Hover — Mouse cursor is over the component. Must communicate: this is interactive, something will happen if you click. Not applicable to touch interfaces — never put essential information in hover states.

Focus — Component has keyboard focus. Must be visually distinct from hover AND default. This is a hard accessibility requirement — users navigating by keyboard need to know where they are.

Active/Pressed — User is in the process of activating (mouse down, touch start). Must provide immediate tactile feedback that the action is registering.

Disabled — Component exists but can't be activated. Must communicate: this exists, but you can't use it right now (and ideally, why). Disabled states that provide no explanation for why they're disabled are a common frustration.

Loading — Component is processing. Must communicate: your action was received, we're working on it, here's how long it might take.

Success — Action completed successfully. Must communicate: it worked, here's the result.

Error — Action failed. Must communicate: it didn't work, here's why, here's what to do about it.

Empty — Component has no content to display. Must communicate: this is where [thing] will appear, here's how to add the first one. Empty states are one of the most neglected states in product design.

Form Field States

Form fields add additional states:

Placeholder — Hint text visible when the field is empty. Use for format examples ("DD/MM/YYYY"), not labels. Placeholder text disappears on focus, so if the user needs the information while typing, it's in the wrong place.

Filled — Field contains user input. This should look different from placeholder — users need to distinguish "I typed this" from "this is a hint."

Read-only — Field displays a value that can't be edited. Different from disabled — read-only values are informational; disabled fields are temporarily unavailable.

Valid — Input passes validation. Whether to show positive validation is a design choice — showing green checkmarks after every field can feel patronizing. Reserve positive validation for fields where success isn't obvious (password strength, username availability).

Invalid — Input fails validation. Must show what's wrong and how to fix it. "Invalid input" is not an error message. "Email must include an @ symbol" is.

Button States

Primary action — The main action the user is here to perform. Visually prominent. One primary action per screen (or per form section in long forms).

Secondary action — Alternative actions (Cancel, Save Draft, Reset). Visually subordinate to primary. Should not be styled in a way that makes them easy to confuse with the primary action.

Destructive action — Actions that can't be undone (Delete, Remove, Revoke). Visually distinct — red is conventional but not sufficient. Should require confirmation proportional to the consequence.

---

Validation Patterns

When to Validate

Error Message Design

Structure: What went wrong + how to fix it. Always both. Never just one.

• Bad: "Invalid input"
• Bad: "Error in field 3"
• Good: "Email address must include an @ symbol — for example: name@company.com"
• Good: "This username is taken. Try adding numbers or try: maria_designer, maria.d"

Position: Adjacent to the field, not at the top of the form. If the user has to scroll to find which field has an error, the error message has failed its purpose.

Timing: Appear when the error is detected. Disappear when the error is fixed. Don't wait for form submission to clear resolved errors.

Tone: Neutral and helpful. Never blame the user. "You entered an invalid email" puts fault on the user. "Please enter an email address in the format name@example.com" puts focus on the solution.

Accessibility: Error messages must be programmatically associated with their fields (aria-describedby). Screen readers need to announce errors when they appear (use aria-live regions or role="alert" for form-level summaries).

---

Feedback Loops

Users need to know that the system heard them and is responding. Silence is the enemy of trust.

Optimistic UI

Update the interface immediately as if the action succeeded, then reconcile with the server. If the server rejects the action, roll back gracefully.

When to use: Low-stakes actions with high success rates. Toggling a favorite, sending a chat message, reordering a list. The action will almost certainly succeed, and the 200ms delay for server confirmation feels sluggish.

When not to use: Financial transactions. Actions that affect other users. Anything where the rollback would be confusing or harmful. If "oops, that didn't actually work" would cause real problems, wait for confirmation.

Rollback design: If the optimistic update needs to be reversed, explain what happened. "Message couldn't be sent — tap to retry" is clear. Silently removing the message the user thought they sent is not.

Skeleton Screens

Show the structure of the page before the content loads. Placeholder shapes in the positions where content will appear.

Why they work: Luke Wroblewski and Google's research shows skeleton screens reduce perceived load time compared to spinners. Users see progress — the page is "filling in" — rather than waiting for a blank-then-full transition.

When to use: Content pages, feeds, dashboards — anywhere the layout is predictable but the content is dynamic. Not appropriate for forms or transactional pages where the structure itself is unknown.

Implementation detail: Skeleton shapes should match the actual content layout. A skeleton that looks nothing like the loaded page creates a jarring transition that's worse than no skeleton.

Progress Indicators

Determinate (you know how long it will take): Use a progress bar with percentage. Show the user how far through the process they are and, ideally, how long remains.

Indeterminate (you don't know how long): Use a spinner or pulsing animation. Be honest — if you don't know how long, don't fake a progress bar. But do provide context: "Uploading your file..." is better than a naked spinner.

Multi-step (sequential process): Show the steps and highlight the current one. Users need to know: how many steps are there, which one am I on, can I go back, can I save and continue later?

---

Progressive Disclosure

Show what's needed now. Reveal what's needed next. Hide what's rarely needed but make it findable.

Patterns

Stepped flows: Break complex tasks into sequential steps. Each step focuses on one decision or one type of information. The user sees only the current step, with awareness of the overall process (step indicator, progress bar).

Expandable sections: Group advanced or optional information behind expand/collapse controls. The label should be descriptive enough that users know what's inside without expanding. "Advanced options" is better than "More."

Contextual help: Tooltips, info icons, and inline help that provide explanation on demand. Good for technical concepts or unusual fields. Bad when used as a substitute for clear labels.

Feature disclosure: In complex tools, show core features by default and surface advanced features as the user demonstrates proficiency. This is distinct from hiding features — the path to discovery should be visible.

Anti-Patterns in Progressive Disclosure

Mystery meat navigation: Icons or labels so abstract that users can't predict what they'll find. Progressive disclosure requires clear signals about what's hidden.

Required information behind disclosure: If the user needs the information to complete their task, it shouldn't be behind a "show more" toggle. Progressive disclosure is for optional and contextual information.

Inconsistent depth: Some sections expand to reveal one item; others reveal 15. Users build expectations about the depth behind disclosure controls. Consistency matters.

---

Undo/Redo Patterns

Undo is not a feature. It's a safety net that makes every other interaction less stressful.

Implementation Approaches

Immediate undo (toast/snackbar): For quick, low-stakes actions. "Message archived — Undo." The undo window is typically 5-10 seconds. After that, the action becomes permanent. Gmail's undo-send is the canonical example.

History-based undo: For document editing and creative tools. Maintain a stack of actions. Users can undo sequentially (Ctrl+Z) or browse the history. Each state should be named descriptively ("Changed font to Helvetica," not "Action 47").

Version history: For long-lived documents and collaborative work. Periodic snapshots with timestamps and authorship. Users can browse, compare, and restore previous versions. Google Docs' version history is well-implemented; the key is that versions are named by time and author, not arbitrary version numbers.

Trash/Archive: For deletion. Move items to a recoverable location rather than deleting permanently. Provide a clear emptying schedule ("Trash empties after 30 days") so users understand the safety window.

Design Principles for Undo

• Make it discoverable. If users don't know undo exists, it doesn't function as a safety net.
• Make the window clear. If undo expires, tell users when.
• Make the scope clear. Does undo reverse the last action? The last 5 actions? Everything since last save?
• In collaborative contexts, undo should affect only the user's own actions, not other collaborators'.

---

Destructive Action Safeguards

Actions that can't be undone need friction proportional to their consequences.

Friction Hierarchy

Level 1 — Visual distinction: Make the destructive button red or otherwise visually distinct from safe actions. This is the minimum — necessary but not sufficient for important actions.

Level 2 — Confirmation dialog: "Are you sure you want to delete this project? This action cannot be undone." Include what will be lost. A generic "Are you sure?" carries no information.

Level 3 — Deliberate action: Require the user to type a confirmation phrase. "Type DELETE to permanently remove this repository." GitHub's repository deletion uses this pattern. Reserve for actions with severe consequences.

Level 4 — Cooling period: For the most consequential actions (account deletion, data export for deletion), implement a waiting period. "Your account will be deleted in 14 days. You can cancel deletion any time before then." GDPR supports this pattern — the right to erasure doesn't require instant deletion.

Safeguard Design Principles

• Name the consequence. "Delete project" is less clear than "Delete project and all 47 files inside it."
• Show what will be lost. A preview of the data being destroyed makes the decision concrete.
• Offer alternatives. "You can also archive this project, which hides it without deleting it."
• Don't ask for confirmation on reversible actions. Confirming "are you sure?" on every action trains users to click through without reading. Save confirmation for genuinely destructive actions. For everything else, provide undo.