Product Design and UX

Entry Check

• 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

1. 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.
2. Establish information architecture from goals, content objects, terminology, permissions, findability, and service context. Read

   references/information-architecture.md

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

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

   .
5. Inventory only states forced by the flow, data, permissions, connectivity, and risk. Record risky omissions. Use

   templates/screen-state-inventory.md

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

   .
7. Treat patterns as hypotheses. Compare alternatives, tradeoffs, evidence, and disconfirming conditions with

   references/interaction-pattern-selection.md

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

references/boundaries-and-traceability.md

references/information-architecture.md

references/content-and-cognitive-demand.md

references/task-flows-and-state-models.md

references/interface-contracts-and-responsive-behavior.md

references/interaction-pattern-selection.md

references/usability-testing-and-privacy.md

references/engineering-handoff.md

references/scenario-probes.md

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