| name | product-design-and-ux |
| description | Define user-facing product behavior from validated evidence and approved scope. Use for information architecture, task flows, state and recovery models, interface contracts, usability-study plans, interaction-pattern tradeoffs, or engineering UX handoffs. Use after product discovery and product decisions; route WCAG/ARIA conformance work to web-accessibility and formal software specifications to spec-driven-development. |
| license | MIT |
| compatibility | Works with any agent framework supporting the Agent Skills format; no design tool, frontend framework, or proprietary service required. |
Product Design and UX
Turn validated evidence and chosen scope into observable behavior people can complete and recover from. Design the interaction, not the brand, pixels, CSS, component implementation, or a particular tool.
Entry Check
Confirm the approved scope, outcome, users or roles, evidence links, constraints, measurable experience goals, and open product decisions. Record missing inputs rather than inventing them.
- Need stakeholder evidence, validation, or raw research? Use product-discovery.
- Need prioritization, scope, or why a feature is being built? Use product-methodology.
- Need WCAG, ARIA, native semantics, or accessibility testing depth? Use web-accessibility.
- Need an approved interaction contract translated into a software specification and delivery gates? Use spec-driven-development.
Workflow
- Trace each outcome and design decision to evidence with
templates/outcomes-to-design.md. Optional personas or jobs must change a decision and cite evidence; do not create decorative demographics.
- Establish information architecture from goals, content objects, terminology, permissions, findability, and service context. Read
references/information-architecture.md.
- Define consequential labels, instructions, status, errors, and completion content; review the task's memory, choice, switching, interruption, and recovery demands. Use heuristics to generate testable questions, not verdicts. Read
references/content-and-cognitive-demand.md.
- Model important tasks, including forces that create decisions, alternatives, interruption, re-entry, cancellation, recovery, irreversible actions, side effects, permission changes, and completion evidence. Read
references/task-flows-and-state-models.md and use templates/task-flow-state-model.md.
- Inventory only states forced by the flow, data, permissions, connectivity, and risk. Record risky omissions. Use
templates/screen-state-inventory.md.
- Write framework-neutral contracts for content, controls, accessible interaction requirements, actions, transitions, persistence, permissions, responsive/reflow behavior, telemetry, and open decisions. Read
references/interface-contracts-and-responsive-behavior.md and use templates/interface-contract.md.
- Treat patterns as hypotheses. Compare alternatives, tradeoffs, evidence, and disconfirming conditions with
references/interaction-pattern-selection.md.
- Plan or synthesize only authorized usability work. Read
references/usability-testing-and-privacy.md; use templates/usability-study.md. Never invent participants, consent, observations, quotes, or results.
- Produce an engineering handoff with observable acceptance evidence, dependencies, owners, gates, and deployed-boundary verification. Read
references/engineering-handoff.md; use templates/engineering-handoff.md. Hand approved behavior to spec-driven-development.
Load On Demand
| Need | Load |
|---|
| Scope boundary, traceability, or adjacent-skill routing | references/boundaries-and-traceability.md |
| Goals, labels, navigation, findability, permissions | references/information-architecture.md |
| Plain-language content, heuristic review, cognitive demand | references/content-and-cognitive-demand.md |
| Task paths, state applicability, recovery, side effects | references/task-flows-and-state-models.md |
| Interaction contract or inclusive responsive behavior | references/interface-contracts-and-responsive-behavior.md |
| Pattern alternatives and decision evidence | references/interaction-pattern-selection.md |
| Usability protocol, synthesis, consent, or privacy | references/usability-testing-and-privacy.md |
| Handoff, acceptance criteria, or deployed verification | references/engineering-handoff.md |
| Methodology self-check with synthetic fixtures | references/scenario-probes.md |
| Source authority, status, and examples | references/source-index.md |
Guardrails
- Accessibility is designed throughout, but WCAG/ARIA/native-semantics and testing depth remain with
web-accessibility.
- Specify behavior under relevant width, zoom/reflow, text expansion/localization, orientation, input modes, reduced motion, degraded connectivity, interruption, and re-entry. Do not use device breakpoints as the model.
- Use synthetic fixtures such as
sample-user@example.test and INV-DEMO-042; never request real credentials, payments, financial access, or secrets for an unsafe prototype.
- A finding from usability work is bounded evidence, not accessibility conformance, population prevalence, analytics, or outcome proof.
Completion
Stop when every in-scope behavior has traceable evidence, an applicable state/recovery model, observable acceptance criteria, and either a resolved decision or an owner and resolution gate. Report limitations and untested risks rather than filling gaps with assumptions.
