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.
- Need to design an AI-assisted, generated, predictive, recommendatory, or tool-using interaction? Read AI interaction and uncertainty and use the AI interaction contract alongside the general contract. Route model evaluation and observability design to agent-evals-and-observability, governance to ai-governance, runtime authority to agent-production-operations, product measurement to product-analytics-and-measurement, accessibility to web-accessibility, and cost/value decisions to ai-operating-economics.
- Need a person to delegate to an agent they use outside the product, then inspect or resume the work across apps? Read external agent interactions and fill the external agent handoff alongside the AI interaction and task-flow contracts. Do not assume the product hosts that agent or can see its private conversation.
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 across every participating role, including recipient-side work after a handoff. Stop at the intended user outcome, not merely submission, delivery, or an intermediate status. Include decisions, alternatives, interruption, re-entry, cancellation, recovery, irreversible actions, side effects, permission changes, and completion evidence. Read
references/task-flows-and-state-models.mdand usetemplates/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.mdand usetemplates/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; usetemplates/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; usetemplates/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 |
| AI uncertainty, grounding, human control, feedback, or model-change acceptance | references/ai-interaction-and-uncertainty.md |
| A person delegates work to their own agent outside the product and returns across app boundaries | references/external-agent-interactions.md; templates/external-agent-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.testandINV-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.
- AI output, confidence, explanation, citation, or user feedback is not proof of correctness by itself. Record the evidence boundary and route model-quality and statistical questions to the owning specialist.
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.
Embedded business-app example
When designing an agent inside an existing task surface, read the equipment-loan worked example. It fills the existing AI interaction, task-flow, and engineering-handoff contracts from recommendation through confirmed effects and recovery; treat its acceptance probes as synthetic design fixtures, not observed usability results.
For executable AI recommendations, re-check current permission, record revision, policy, inventory, and the approved action digest at execution. An approval-time check alone is insufficient. After an uncertain command outcome, query the persisted command ID before any retry; do not create a new reservation ID or repeat a confirmed side effect. Show partial effects separately.