{
  "schema_version": 1,
  "skill_name": "product-design-and-ux",
  "evals": [
    {
      "id": "task-flow-design",
      "prompt": "We are designing the invite-teammates flow for our collaboration app. Users need to add multiple teammates, choose roles, and receive invites by email. What does the task flow look like, and what should I decide before the design handoff to engineering?",
      "expected_output": "A task flow design that walks the complete user path including the decisions at each step: entry points into invite, the invite composition step (email addresses, roles, optional message), validation states for invalid or duplicate addresses, the confirmation and what happens next for the inviter, and the invitee-side journey (email receipt, acceptance, account creation or login, role assignment). The response makes the interface decisions explicit: whether invites can be sent partially (some valid, some invalid), whether resending and revoking are supported, the failure and error states, and the boundary conditions (max batch size, deduplication). It ends with the unresolved decision points that need product input before engineering handoff.",
      "assertions": [
        "The response covers both the inviter-side and invitee-side journeys end to end",
        "Validation and error states are specified for invalid, duplicate, and partial batches of addresses",
        "The response resolves or flags decisions on resend, revoke, deduplication, and batch limits",
        "The flow includes the post-acceptance state such as role assignment and account creation",
        "Unresolved decision points are explicitly listed for product input before handoff"
      ]
    },
    {
      "id": "state-recovery-model",
      "prompt": "Our checkout form loses all user input when the page reloads or the session times out, and users abandon the flow. I want a state and recovery model so this stops happening. What states does the form have and how should recovery work in each?",
      "expected_output": "A state and recovery model that enumerates the form's states: initial empty, partial input, validation error, submitting, submitted, and the failure states (network error, session expiry, server-side validation rejection, duplicate submission). For each state the response defines what is preserved and what is recoverable: input autosaved locally and restored on reload, session expiry handled by re-authentication that returns the user to the same step with data intact, idempotency so a retried submit does not double-charge, and explicit error recovery paths that tell the user what happened and what to do. The response also defines the timeout boundary after which recovery is no longer possible and the data is cleared with a clear message.",
      "assertions": [
        "The response enumerates the full state set including partial input, submitting, network failure, and session expiry",
        "Input is preserved and restored on reload through autosave or local persistence",
        "Session expiry recovery returns the user to the same step with data intact",
        "Retried submissions are idempotent and cannot double-charge",
        "The response defines when recovery is no longer possible and how that is communicated"
      ]
    },
    {
      "id": "interface-contract-handoff",
      "prompt": "I am handing the search-results page design to engineering. Every handoff before has produced drift: different spacing, wrong empty states, unclear loading behavior. What should the interface contract contain so the implementation matches the design?",
      "expected_output": "An interface contract that specifies behavior rather than only aesthetics: the component inventory with names matching the design system, spacing and sizing tokens with concrete values, the states each component must render (loading, empty, error, populated, end-of-results), interaction behavior (debounce timing, keyboard navigation, focus management), and the data contract the page consumes (fields, ordering, pagination model). The response explains how to make the contract verifiable: reference screenshots or fixtures for key states, named tokens instead of pixel values repeated ad hoc, and a checklist the engineer uses to confirm each state before the page is considered done.",
      "assertions": [
        "The contract covers behavior and states, not only visual appearance",
        "Components map to the design system with concrete spacing and sizing tokens",
        "All states including loading, empty, error, and end-of-results are specified",
        "Interaction behavior such as debounce, keyboard navigation, and focus is specified",
        "The contract is verifiable through named tokens, fixtures, and a state checklist"
      ]
    },
    {
      "id": "usability-study-plan",
      "prompt": "We are about to redesign our dashboard navigation and want to test the new information architecture before building it. How do I plan a usability study that gives us signal we can act on, without over-engineering the research?",
      "expected_output": "A usability study plan scoped to the decision at hand: a task-based test of the navigation where participants are asked to find specific information in the new IA, with a small set of well-chosen tasks that cover the highest-frequency user goals. The plan specifies participant criteria (a pragmatic small set of current users across the main personas, not a large panel), the protocol (moderated sessions with think-aloud, task success and time as measures, plus observation of where people look first), and the analysis: task success rates, the places where participants get lost, and a ranked list of IA problems with severity. The response right-sizes the study: 5-8 participants for a formative IA test, task selection driven by analytics data on what users actually do, and a report format that leads with the actionable problems.",
      "assertions": [
        "The study is task-based and tests the new IA against high-frequency user goals",
        "Participant criteria are pragmatic and grounded in real usage, with a small formative sample",
        "The protocol specifies moderated think-aloud sessions and the measures taken",
        "Analysis produces ranked, severity-ordered problems from task success and lostness data",
        "The response right-sizes the study and justifies the sample size for a formative test"
      ]
    },
    {
      "id": "information-architecture-review",
      "prompt": "Our app has grown from 5 to 40 screens and navigation is now a maze. Users cannot find features that exist, and teams keep adding entries to the sidebar. How should I review the information architecture and fix it systematically?",
      "expected_output": "An information architecture review that starts from evidence, not opinion: card sorting or tree-testing results if available, analytics on navigation paths and search queries, and a content inventory grouped by user task frequency. The response proposes a hierarchy organized around the top user jobs with a small number of top-level destinations, applies the rules of thumb for where items belong (frequency and importance drive depth, related tasks cluster), and defines the governance fix: a stated policy for when a new feature earns a navigation entry versus living inside an existing destination, so the maze does not grow back. It sequences the work: audit, propose IA, validate with tree-testing or a quick study, then migrate with redirects.",
      "assertions": [
        "The review is driven by evidence such as navigation analytics, search data, and a content inventory",
        "The proposed hierarchy is organized around top user jobs with few top-level destinations",
        "Placement rules are explicit, using frequency and importance to drive depth",
        "The response includes navigation governance so the structure does not regrow into a maze",
        "The response sequences audit, redesign, validation, and migration with redirects"
      ]
    },
    {
      "id": "ai-uncertain-output-recovery",
      "prompt": "We are designing an AI assistant that drafts answers from an internal knowledge base. What should happen when the sources are missing, stale, or conflicting, and how should a user recover?",
      "expected_output": "A framework-neutral interaction design that defines source ownership and freshness, distinguishes draft from verified fact, makes unsupported or conflicting context visible, preserves the user’s request, and provides clarification, correction, safe fallback, and escalation paths. It names the evidence and model-change acceptance checks without inventing confidence or claiming that a citation proves correctness.",
      "assertions": [
        "The response defines missing, stale, and conflicting source behavior",
        "The draft is distinguished from a verified fact or committed action",
        "The response provides correction, clarification, fallback, and escalation recovery",
        "The user’s input and relevant context are preserved through recovery",
        "The response avoids unsupported confidence or correctness claims"
      ]
    },
    {
      "id": "ai-human-control-boundary",
      "prompt": "A product team wants an AI system to recommend account changes and sometimes execute them. Define the interaction contract before implementation.",
      "expected_output": "An interaction contract that compares assist, recommend, and execute modes against stakes, reversibility, observability, permissions, and review burden; identifies the human approval boundary; separates preview from external commit; and specifies authorization re-checks, cancellation or undo where real, partial failure, and completion evidence.",
      "assertions": [
        "The response compares control modes using task risk and reversibility",
        "A human approval and authorization boundary is explicit",
        "Preview is distinguished from an external side effect",
        "Partial failure, retry or deduplication, and completion evidence are specified",
        "The response records an owner and revisit trigger for the control decision"
      ]
    },
    {
      "id": "ai-feedback-consent-loop",
      "prompt": "We want feedback on AI suggestions in a customer workflow. Design a feedback loop that is useful without treating every thumbs-up as truth.",
      "expected_output": "A consent-aware feedback design that uses minimal signals such as accepted, edited, rejected, corrected, escalated, or completed; explains purpose and retention; separates preference, experience, task completion, and correctness; routes signals to triage and evaluation owners; and defines the evidence required before changing the model, prompt, retrieval, or UX.",
      "assertions": [
        "The response proposes minimal, meaningful feedback signals",
        "Purpose, notice or consent, minimization, retention, and ownership are addressed",
        "Preference and experience are distinguished from correctness",
        "Signals flow to triage, representative fixtures, independent evaluation, and a release decision",
        "The response does not treat ratings alone as correctness evidence"
      ]
    },
    {
      "id": "ai-change-acceptance-fixtures",
      "prompt": "A team is changing its model and retrieval index for a production recommendation experience. What acceptance evidence should the UX handoff require?",
      "expected_output": "A change-acceptance plan with versioned model, prompt, and retrieval identifiers; authorized representative fixtures covering normal, ambiguous, unsupported, stale, permission, interruption, and fallback cases; observable behavior and recovery expectations; user and countermetric evidence; and separate recording of blocked, inconclusive, and passed results.",
      "assertions": [
        "The plan records the changed model, prompt, and retrieval versions",
        "Fixtures include normal, ambiguous, unsupported, stale, permission, interruption, and fallback cases",
        "Each fixture has observable behavior and recovery expectations",
        "User outcomes and countermetrics are considered alongside quality evidence",
        "Blocked and inconclusive results remain distinct from passes"
      ]
    },
    {
      "id": "ai-handoff-escalation",
      "prompt": "A conversational assistant must hand a difficult case to a human. Define the handoff and opt-out behavior for the UX and engineering teams.",
      "expected_output": "A handoff design that states when escalation occurs, what status and destination are shown, what context is transferred, how the user can inspect or correct the summary, what the alternate or opt-out path does, and how the human continues without re-entering known information. It distinguishes a generated summary from a verified transcript and protects unnecessary sensitive content.",
      "assertions": [
        "Escalation trigger, destination, and user-visible status are explicit",
        "Transferred context is bounded and inspectable",
        "The user can correct the handoff summary",
        "Opt-out or alternate behavior is defined",
        "The design distinguishes generated summary from verified transcript and minimizes sensitive data"
      ]
    }
  ]
}

# AI Interaction and Uncertainty

Use this reference when a product includes generated content, predictions, recommendations, classification, conversational input, retrieval, or an AI system that can call tools. It extends the general task-flow, state-model, interface-contract, usability, and handoff workflow. It does not select models, implement evaluation or telemetry systems, define organization-wide governance, or operate production agents.

## Entry boundary

Start with an approved outcome and evidence. Record the task, affected roles, decision owner, system role, relevant data/context sources, freshness, constraints, and what remains human-controlled. State whether the system assists, drafts, recommends, ranks, predicts, routes, or executes. If the problem, scope, or success measure is unvalidated, route upstream to `product-discovery`, `product-methodology`, or `ai-operating-economics`.

## Choose the control boundary

Treat interaction mode as a hypothesis. Compare a conventional interaction, AI assistance, AI recommendation, and AI execution against:

| Force | Questions |
|---|---|
| Stakes and reversibility | What is the harm of a wrong output or action? Can a person inspect, edit, undo, or contain it? |
| Ambiguity and observability | Can the user and reviewer recognize an unsupported or wrong result? What evidence is available? |
| Frequency and review burden | How often does the task occur? Does review remove the claimed benefit or create a new queue? |
| Data and context | Are inputs permitted, current, complete, and relevant? How are conflicts and missing context shown? |
| Authority and side effects | Which actions are drafts or recommendations, and which cross an external commit boundary? |
| User capability and access | What expertise, language, modality, and assistive input must the flow support? |

Higher stakes, weak observability, irreversible effects, or unclear authority generally require a meaningful human review or approval point. A good offline score or pilot result does not by itself authorize broader autonomy. Record the selected boundary, alternatives, evidence, owner, and revisit trigger.

## Make uncertainty useful

Specify behavior for evidence that is weak, conflicting, missing, stale, outside the supported task, or unsafe. The interface should make the limitation actionable: ask for clarification, show the relevant source or input boundary where it is available, offer a safe fallback, preserve the user’s work, or escalate. Do not invent a confidence number, rationale, citation, or “understanding” claim merely to make an answer feel certain.

Separate:

- **Draft or suggestion:** the person can inspect and edit it; no external effect is implied.
- **Decision support:** the system presents evidence and tradeoffs; the authorized person makes the decision.
- **Action:** the system may cause a side effect only after the defined authorization, validation, and commit boundary.

For each output, define the correction, edit, reject, retry, clarify, source-inspection, fallback, and escalation actions that are actually supported. Preserve relevant input and context through those paths.

## Model states and recovery

Add only states forced by the task and system boundary. Typical AI-specific states include pending or streaming, partial, complete, unsupported or uncertain, stale/conflicting context, blocked by permission or policy, failed, escalated, corrected, and committed. For each state, specify the visible status, retained work, permitted actions, transition, and completion evidence.

When an AI system uses tools or multiple steps, distinguish each successful side effect from the overall workflow. Define preview, approval, authorization re-check, cancellation, retry/deduplication, undo where it is real, and the recovery path after partial completion. Never show a successful completion state before the external effect is confirmed.

## Grounding and freshness

For retrieval, recommendations, or decisions that depend on external information, record the source owner, retrieval/context boundary, freshness expectation, conflict behavior, and what the user can inspect. A source link or citation is an affordance for verification; it is not proof that the generated claim follows from the source. If context is unavailable, stale, or contradictory, expose that condition and route to clarification, fallback, or review.

## Opt-out and human handoff

Offer an understandable opt-out or alternate path when AI participation is optional, consequential, inaccessible, or not useful. Explain what opting out changes and retain enough task context for the alternate path without silently continuing AI processing. For escalation, state the trigger, destination, expected handoff time or status if known, and what summary/context is transferred. Let the person inspect and correct the handoff summary; do not present a generated summary as a complete transcript or verified fact set.

## Feedback as evidence

Design the smallest useful feedback signal: accepted, edited, rejected, corrected, escalated, task completed, or optional reason. Tell the person the purpose, retention, and whether content is being captured; minimize data and do not request secrets or unnecessary personal information. Treat a rating as a preference or experience signal until independently checked. Route event schema, privacy, statistical inference, and model evaluation to `product-analytics-and-measurement`, `agent-evals-and-observability`, `data-scientist`, or `ai-governance` as appropriate.

Define the improvement loop: signal → triage → representative fixture or test case → proposed UX/content/context/model change → independent evaluation → release decision. A feedback signal alone is not permission to change behavior or evidence that the change improved correctness.

## Acceptance for model, prompt, or retrieval changes

When a model, system prompt, retrieval index, ranking method, tool policy, or grounding source changes, rerun the approved behavior boundary. Use authorized representative fixtures covering:

- normal and ambiguous inputs;
- unsupported, stale, conflicting, and out-of-distribution inputs;
- permission, privacy, unsafe-output, and escalation paths;
- interruption, retry, partial side effect, and re-entry;
- review burden, latency, and any user-visible fallback.

Record the version/change identifier, fixture provenance, expected observable behavior, evidence captured, and limitations. Compare user outcome and countermetrics against the declared baseline; do not substitute benchmark scores, output count, or self-reported success. Route statistical design and model-quality thresholds to the owning specialists.

## Handoff checklist

Before engineering handoff, confirm that the linked artifacts state:

- AI role, authority, human review, and prohibited side effects;
- input/context ownership, freshness, privacy, and missing/conflicting behavior;
- output form, uncertainty language, grounding affordance, correction, fallback, and escalation;
- pending, partial, failed, blocked, and committed states with recovery and completion evidence;
- feedback purpose, notice/consent, minimization, retention owner, and improvement trigger;
- fixtures and deployed checks for model/prompt/retrieval/tool changes;
- unresolved decisions, owners, and revisit gates.

Use the general `templates/interface-contract.md` for the complete interaction contract and `templates/ai-interaction-contract.md` for these AI-specific additions. Pass approved behavior to `spec-driven-development`; do not turn this reference into a model or runtime operations manual.

# Boundaries and Traceability

## Pipeline Boundary

| Concern | Owner | This skill receives or produces |
|---|---|---|
| Obtain and validate human evidence | `product-discovery` | Validated needs, evidence links, limitations, unresolved assumptions. |
| Decide scope, priority, and rationale | `product-methodology` | Chosen outcome, scope boundary, decisions, and success measures. |
| Define user-facing behavior | This skill | IA, task/state models, interface contracts, usability evidence, and handoff. |
| Accessibility conformance depth | `web-accessibility` | Routed requirements and its implementation/testing evidence. |
| Formal software specification and gates | `spec-driven-development` | Approved interaction contracts and observable acceptance criteria. |

Do not replace discovery with invented research, reopen an approved scope through prioritization, issue a WCAG conformance claim, or prescribe visual implementation.

## Traceability Method

Assign stable identifiers to evidence (`E-01`), outcomes (`O-01`), decisions (`D-01`), tasks (`T-01`), contracts (`IC-01`), and acceptance criteria (`AC-01`). For each decision, record the source, confidence or limitation, affected role, and what would change it. A claim without evidence is an assumption; name its owner and resolution gate.

Read `templates/outcomes-to-design.md` when creating the trace. The trace is complete when a reviewer can move both directions: outcome to interface behavior, and interface behavior to evidence or an explicit open decision.

## Accessibility Routing

Carry requirements such as keyboard reachability, focus outcome, accessible name/role/state expectations, text alternatives, reflow, and error recovery into contracts. For exact criterion applicability, semantics selection, ARIA, browser/AT evidence, or conformance claims, link the work to [web-accessibility](../../web-accessibility/SKILL.md) rather than summarizing standards here.

# Content, Heuristic Review, and Cognitive Demand

Content is part of behavior. Labels, instructions, status, errors, and confirmation evidence determine what a person understands and can recover from; they are not decoration added after the interaction model.

## Content Contract

For consequential content, record:

- audience, task, decision, and moment of use;
- source and accountable owner;
- terminology and evidence for the chosen label;
- required facts, uncertainty, consequence, and next action;
- state variants such as loading, empty, pending, stale, denied, partial, failed, and complete;
- localization, text expansion, formatting, and fallback behavior;
- review and freshness requirements.

Use the person's domain language unless technical or legal precision requires another term; explain unavoidable specialized language at the point of use. Prefer a concrete action or outcome over a vague label. Error content should say what happened, what was preserved, what the person can do, and where to get help when self-recovery is unavailable. Do not blame the person or claim success before the side effect is known.

Plain language is contextual, not a sentence-length formula. Preserve necessary nuance, risk, and legal meaning. Test whether intended people can find, understand, and act on the content rather than relying on a readability score alone.

## Cognitive Demand Review

Inspect the task for demands created by the design:

| Demand | Questions and possible responses |
|---|---|
| Recall | Must people remember an identifier, rule, prior value, or hidden choice? Keep context visible or make recognition possible. |
| Choice and comparison | Are options distinguishable by consequences that matter? Group or stage only when it preserves overview and comparison. |
| Context switching | Does the task require moving between surfaces, channels, or documents? Preserve state, references, and return paths. |
| Interruption | Can a person tell what is saved, pending, expired, or changed when they return? |
| Error interpretation | Does feedback identify the affected field/action, retained input, consequence, and recovery? |
| Time or attention pressure | Are irreversible actions, expiring state, or background work communicated without forcing premature decisions? |
| Unfamiliar sequence | Is guidance available at the decision point, and can experienced people bypass it safely? |

Reduce unnecessary demand without hiding decisions, removing control, or oversimplifying risk. Defaults can reduce effort but must be safe, visible, reversible where possible, and appropriate to the role. Progressive disclosure can reduce scanning but becomes harmful when it hides consequence, status, or recovery.

Do not use a magic limit for steps, options, or memory. The stopping criterion is whether the task's demands are supported in the actual context and whether evidence exposes avoidable confusion or recovery failure.

## Heuristic Review as a Hypothesis Generator

Use these prompts to find questions, not to issue a usability verdict:

- Is system status timely and truthful, including pending and partial work?
- Does language match the domain and distinguish neighboring concepts?
- Can people cancel, undo, recover, or understand why they cannot?
- Are similar actions consistent without forcing unlike tasks into one pattern?
- Does the design prevent consequential mistakes at the right boundary?
- Is necessary context visible rather than dependent on memory?
- Can frequent and infrequent users complete the task without blocking each other?
- Is every piece of content relevant to the current decision or recovery?
- Do errors preserve work and provide a specific correction or support path?
- Is help available where the domain cannot make the task self-explanatory?

For every finding, identify the task, state, evidence, risk, affected role, and contract change. A heuristic match without task evidence is a review lead, not proof. Validate consequential findings through the appropriate evidence path: source review, domain/policy review, accessibility evaluation, authorized usability work, or deployed-boundary observation.

# Engineering Handoff

Handoff is a traceable behavior package, not a mockup link or presentation. It should let implementation and verification reconstruct what the user can observe, where the evidence came from, which decisions remain open, and how to prove the delivered boundary matches the approved contract.

## Required Package

Include:

- approved outcome and scope, affected users/roles, and evidence trace;
- information architecture and terminology decisions;
- task flows, state/transition inventory, recovery, permission, and side-effect models;
- interface contracts and content requirements;
- accessibility requirements routed to `web-accessibility`, with the expected evidence boundary;
- usability evidence, negative cases, fidelity limits, and untested paths;
- data/content/service dependencies, ownership, freshness, fallback, and failure behavior;
- telemetry purpose and minimum event contract where evidence requires it;
- implementation risks, unresolved decisions, owners, and gates;
- observable acceptance criteria and deployed-boundary verification plan.

Do not attach a pile of artifacts without a navigation surface. `templates/engineering-handoff.md` is the index and gate record; link every supporting artifact from it.

## Observable Acceptance Criteria

Write criteria at the user-facing or deployed boundary. A useful criterion identifies:

1. entry condition, role, permission, and relevant data state;
2. action or external event;
3. visible behavior and state transition;
4. persistence or side effect, including partial/failure behavior;
5. recovery, interruption/re-entry, and completion evidence where applicable;
6. accessibility expectation and routed test evidence;
7. exact environment, fixture, observation, and result record.

Avoid “works well,” “is intuitive,” “is responsive,” or “is accessible.” Replace them with observable behavior. Do not force a binary criterion when the open decision genuinely needs research; record the decision and gate instead.

## Dependency Contract

For each content, data, service, policy, permission, or platform dependency, record:

| Field | Question |
|---|---|
| Provider/owner | Who can answer and change it? |
| Contract/source | What schema, content source, policy, or platform behavior is expected? |
| Freshness and availability | When can it be stale, delayed, missing, or revoked? |
| Failure/fallback | What does the person see and retain when it fails? |
| Privacy/security boundary | What data or authority crosses the boundary? |
| Verification | How will implementation and deployed behavior be checked? |

A dependency without an owner or fallback is an unresolved design risk, not an engineering detail.

## Handoff Review

Run a walkthrough using at least one normal path and the highest-risk permission, interruption, partial-commit, stale/conflict, or failure path. Trace each behavior backward to evidence or an explicit assumption and forward to an acceptance criterion. Confirm no mockup-only state, inaccessible interaction, placeholder content, or simulated side effect is represented as complete.

Classify findings:

- **Blocking:** implementation would invent consequential behavior, expose unsafe data/action, omit required recovery, or lack a testable contract.
- **Conditional:** an owner and resolution gate exist and implementation can proceed without guessing past that gate.
- **Nonblocking:** clarification improves maintainability without changing behavior or risk.

## Deployed-Boundary Verification

Component or prototype success does not prove integration behavior. Name the actual delivery boundary, supported environment, fixture, steps, expected observation, evidence capture, and cleanup. Include permissions, persistence, external effects, responsive behavior, and accessibility environment where relevant. Record failed, blocked, and not-applicable results instead of converting absent evidence into a pass.

After approval, pass the interaction contracts and criteria to [spec-driven-development](../../spec-driven-development/SKILL.md) for formal software specification and delivery gates. Keep UX evidence linked rather than flattening it into implementation prose.

# Information Architecture

Information architecture (IA) makes objects, actions, relationships, and routes findable and understandable. Start with what people need to accomplish and locate, not with a preferred navigation control or the current database schema.

## Inventory Before Structure

Record:

- user goals and entry contexts;
- content or domain objects, their relationships, ownership, and lifecycle;
- language people use and conflicting internal terminology;
- roles, permissions, visibility boundaries, and cross-account or cross-tenant context;
- likely entry points from links, search, notifications, history, and other channels;
- frequency, urgency, risk, comparison needs, and interruption/re-entry;
- content volume, growth, freshness, archival, and deletion behavior.

Do not expose implementation nouns merely because they already exist. Do not flatten distinct user concepts because they share a table. Preserve a vocabulary conflict as an open decision until evidence resolves it.

## Derive and Test the Model

For each important object or action, answer:

| Question | Evidence to retain |
|---|---|
| Where can a person enter directly? | Entry-point inventory and required context |
| Where would they look first? | Research, domain language, support/search evidence, or explicit assumption |
| What label distinguishes it from neighbors? | Terminology evidence and rejected labels |
| What role or ownership changes visibility or action? | Permission matrix and empty/denied behavior |
| How do they move between overview, object, action, and history? | Navigation/search model and return path |
| How do they resume after interruption? | Stable identifier, preserved filters/context, and re-entry route |
| What happens when the object is missing, stale, archived, or moved? | Recovery, redirect, explanation, and support path |

Validate labels, grouping, hierarchy, navigation, and search assumptions with the smallest evidence capable of disproving them. Depending on uncertainty, that may be source review, content inventory, tree/path exercise, search-log analysis, or authorized task-based observation. Name the method and limitation; do not call an untested sitemap intuitive.

## Navigation and Disclosure Decisions

Choose navigation only after the object and task model is visible. Compare depth, breadth, orientation, backtracking, scanning, cross-linking, search dependence, permission-induced gaps, and context preservation. A sitemap, route map, or search schema documents the result; none substitutes for reasoning.

Progressive disclosure is a hypothesis. Reveal detail when it supports the next decision, but never hide information needed to assess consequence, cost, privacy, authorization, or irreversibility. Record what is hidden, the reveal trigger, how the trigger is discoverable, whether state persists, and how keyboard, touch, and assistive input reach it.

## Output Gate

Use `templates/outcomes-to-design.md` to connect goals and evidence to findability decisions, then carry entry points, labels, object context, and permissions into `templates/interface-contract.md`. IA is ready for flow design when every in-scope task has a plausible entry and return path, permission-driven absences are explained, and unresolved terminology has an owner and resolution gate.

# Interaction Pattern Selection

Patterns are reusable hypotheses, not prescriptions. A familiar component can still be wrong for the task, risk, frequency, data shape, permission model, platform, or recovery requirement.

## Decision Record

For every consequential pattern, record:

1. the user goal and context;
2. forces: frequency, urgency, reversibility, data volume, uncertainty, comparison, permissions, connectivity, interruption, and accessibility;
3. plausible alternatives, including a simpler native interaction;
4. tradeoffs and failure modes of each alternative;
5. supporting and disconfirming evidence;
6. the selected approach, owner, assumptions, and revisit trigger.

Do not present a design-system example as proof. If no evidence distinguishes alternatives, name the choice as provisional and define the observation that would change it.

## Common Pattern Forces

| Pattern family | Questions that determine fit |
|---|---|
| Forms and validation | When can validity be known? Is input preserved? Can errors be associated, summarized, and corrected without losing context? |
| Search and filtering | Is the person locating, exploring, comparing, or narrowing? How are active filters, zero results, stale results, saved views, and re-entry handled? |
| Dense tables and dashboards | Which comparisons and actions matter? What does sorting, truncation, horizontal movement, personalization, or narrow width do to meaning? |
| Onboarding and guidance | Is instruction needed before action, at the decision point, or only after failure? Can experienced users bypass it? |
| Disclosures and progressive detail | Is hidden information nonessential to the current decision? Is the reveal discoverable, reachable, stateful, and safe? |
| Destructive or consequential actions | Is the effect reversible, delayed, repeated, or rare? Would confirmation, typed intent, preview, undo, delayed commit, or approval reduce the actual risk? |
| Autosave and optimistic update | What is the commit boundary? How are pending, failed, conflicting, offline, and restored states communicated? |
| Pagination, load-more, and streaming | Is the task exploration, exhaustive review, comparison, return-to-position, or audit? How are total, order, updates, failure, and re-entry represented? |

## Tradeoff Examples

- Confirmation can reduce accidental irreversible action, but repeated confirmations can become automatic dismissal. Prefer a risk-matched barrier and preserve a recovery path where the domain permits it.
- Undo can improve recovery, but only when retention, authorization, synchronization, and user-visible time boundaries make restoration real.
- Infinite scroll can support exploration, but it can weaken location, comparison, footer access, completion sense, and re-entry. Pagination or load-more may fit bounded review better.
- Optimistic updates can improve perceived responsiveness, but they require truthful pending/failure/conflict behavior and must not imply a side effect committed when it did not.
- Wizards can sequence complex dependencies, but may hide overview, make branching awkward, and complicate interruption. A reviewable single flow or staged checklist may be better.

## Evidence and Revisit Gate

Use authorized task evidence, support/search data, domain constraints, accessibility evidence, production failures, and implementation feasibility. Do not count preference alone as task success. Define a revisit condition such as a recurring recovery failure, unexpected permission path, inability to resume, or observed comparison burden.

GOV.UK and USWDS are useful rolling government examples, not universal standards. Link to their live guidance through `source-index.md`; do not copy a component or infer that government context matches the product.

# Interface Contracts and Inclusive Responsive Behavior

An interface contract describes observable behavior, not visual styling, component names, or framework APIs. It lets design, content, accessibility, engineering, testing, operations, and product review the same boundary without assuming the mockup contains all behavior.

## Contract Fields

For each surface or meaningful state, specify:

- linked outcome, task, evidence, role, and entry conditions;
- content, source, freshness, formatting responsibility, and fallback;
- controls and their purpose, visible label, accessible name/role/state expectation, and enabled/disabled/hidden rules;
- allowed actions, validation timing, error placement, correction path, and preservation of input;
- transition trigger, destination, focus or orientation outcome, persistence, and re-entry;
- permission checks at view and action boundaries, including changed or expired authority;
- side effects, commit boundary, retry/deduplication behavior, cancellation, undo, and completion evidence;
- telemetry purpose and minimum event fields, without default content capture;
- assumptions, unresolved decisions, owners, and resolution gates.

The contract should describe what a person can observe and do. Leave layout coordinates, CSS, component props, and internal service calls to implementation artifacts unless they are externally constrained.

## Responsive Behavior as Constraints

Do not reduce responsiveness to named device breakpoints. For each relevant constraint, record what remains available, what changes, and how context survives:

| Constraint | Contract questions |
|---|---|
| Available width and zoom/reflow | What can wrap, stack, scroll, collapse, or remain pinned without losing order, labels, comparison, or actions? |
| Text expansion and localization | Which containers grow, which labels cannot truncate, and what happens to tables, controls, errors, and status? |
| Orientation and viewport change | Is work preserved? Does focus or reading position remain logical? |
| Keyboard, pointer, touch, switch, and voice input | Is every action reachable with appropriate target, order, naming, and non-drag alternative? |
| Reduced motion or animation failure | Is meaning preserved without motion, and can movement be suppressed where required? |
| Degraded connectivity and delayed work | What becomes unavailable, queued, stale, partial, retryable, or cancellable? |
| Interruption and re-entry | What draft, filters, step, ownership, permission, and conflict information is restored or revalidated? |

Only include constraints relevant to the supported product context, but record why a high-risk constraint was ruled out. Fixed pixel values may be implementation evidence, not the reasoning model.

## Accessibility Boundary

Carry keyboard reachability, focus outcome, accessible name/role/state expectations, text alternatives, error recovery, reflow, motion, and input alternatives into the interaction contract. Route exact success-criterion applicability, native semantics, ARIA selection, browser/assistive-technology matrices, and conformance evidence to [web-accessibility](../../web-accessibility/SKILL.md).

An accessibility field is useful only when it is observable. Replace “accessible control” with the intended name, role, state/value, keyboard behavior, focus outcome, error behavior, and evidence path.

## Contract Review

Review one contract against its task/state model and data/permission boundary. Reject it when a transition has no recovery, a mutation lacks completion evidence, a role can see but not understand an unavailable action, content ownership is missing, telemetry has no purpose/minimization rule, or responsive behavior is deferred to “the frontend.” Use `templates/interface-contract.md` to capture the result.

# Synthetic Scenario Probes

Use these probes to review a proposed design artifact. They use synthetic fixtures only and grade force coverage, traceability, privacy, accessibility routing, recovery, and observable evidence, not numbers of screens, states, or participants.

## Transactional Partial Commit

`Northstar Travel` reserves `DEMO-ITINERARY-42`. A submit may reserve an itinerary before payment confirmation times out. A later retry can duplicate a reservation. Cancellation becomes irreversible after a stated fulfillment boundary.

Expect entry conditions, validation preservation, pending/partial-commit visibility, retry and deduplication behavior, interruption/re-entry, cancellation, irreversible warning, recovery/support route, completion receipt, and no real payment fixture.

## Permissions-Heavy Workspace

`Atlas Review` has synthetic items owned by teams. Reviewers can annotate, owners can submit, administrators can archive, and auditors can only view history. Ownership can change while a reviewer has an item open; filters can return stale results and simultaneous edits can conflict.

Expect IA grounded in roles/findability, view versus action permissions, ownership change behavior, stale/conflict recovery, dense-data filtering tradeoffs, audit and recovery path, and completion evidence.

## Interrupted Responsive Flow

`Civic Permit Demo` saves a draft request. Content may be narrow or reflowed at zoom, localized text can expand, orientation can change, a keyboard/touch/assistive input method can be used, and connectivity can degrade before final submission.

Expect preserved context, save/re-entry, applicable offline/degraded behavior, text/reflow and input-mode contract, reduced-motion consideration, validation/recovery, and routing of detailed accessibility verification to `web-accessibility`.

## Review Questions

For each probe, ask: Which evidence supports the behavior? Which forces were considered or ruled out? What recovery is available? Which accessibility questions were routed? What data is synthetic? Which criterion can be observed after deployment?

# Source and Status Index

Use sources for their demonstrated scope. This skill synthesizes portable decision methods; it does not reproduce vendor component specifications or turn examples into universal requirements. Status and URLs were checked 2026-07-13.

| Source | Status | Use in this skill | Do not infer |
|---|---|---|---|
| [ISO 9241-210:2019](https://www.iso.org/standard/77520.html) | International Standard for human-centred design for interactive systems, second edition published 2019 and confirmed 2025 | Lifecycle framing: understand context, specify user requirements, produce design solutions, and evaluate them iteratively | A detailed interface-pattern catalog, fixed research protocol, or certification verdict |
| [WCAG 2.2](https://www.w3.org/TR/WCAG22/) | W3C Recommendation; current published page dated 2024-12-12 | Establish that accessibility criteria require a separate, scoped contract and evidence path | That a usability session, design review, or automated scan establishes conformance |
| [W3C Making Content Usable for People with Cognitive and Learning Disabilities](https://www.w3.org/TR/coga-usable/) | W3C Working Group Note whose status section describes the material as work in progress | Supplemental inclusive-content and interaction considerations for cognitive and learning disabilities | WCAG success criteria, legal requirements, or universally applicable prescriptions |
| [GOV.UK Government Design Principles](https://www.gov.uk/guidance/government-design-principles) | Rolling United Kingdom government guidance | Examples of user-need, whole-service, evidence, accessibility, and iteration framing | A universal product lifecycle or proof a pattern fits another domain |
| [GOV.UK moderated usability testing](https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing) | Rolling United Kingdom government service guidance | Example considerations for task-based, moderated observation and session conduct | A mandatory method, participant count, or success threshold |
| [GOV.UK research consent](https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research) | Rolling United Kingdom government service guidance | Example consent transparency, recording, withdrawal, and data-use considerations | Legal advice or a consent form valid in every organization or jurisdiction |
| [USWDS Design Principles](https://designsystem.digital.gov/design-principles/) | Rolling United States government design-system guidance | Examples of accessibility, continuity, trust, evidence, and device/context considerations | A mandatory component library, breakpoint model, or universal government policy |
| [Web Accessibility skill source index](../../web-accessibility/references/source-index.md) | Maintained local catalog source index | WCAG, ARIA, HTML, accessible-name, pattern, and accessibility-evidence authority | That this UX skill owns conformance interpretation |

## Source Discipline

1. Record the exact source, version or page status, retrieval date, and the decision it informed.
2. Separate normative requirements, informative guidance, examples, and this skill's synthesis.
3. Verify live status before making a current-standard claim. A rolling page can change without a versioned release.
4. If a source conflicts with user evidence, policy, legal advice, platform behavior, or the supported accessibility environment, preserve the conflict and route it to the accountable owner; do not silently choose the prettier rule.
5. Do not cite a source merely because its vocabulary resembles the decision. Show the link from source scope to the artifact field or acceptance criterion it supports.

# Task Flows and State Models

Model one meaningful outcome at a time. A flow starts with entry conditions and ends with observable completion evidence, not merely a button press. Include decisions, alternative and exception paths, cancellation, interruption and re-entry, recovery, irreversible actions, side effects, permissions, ownership changes, and stale or conflicting data where the system can create them.

## Force-Driven State Applicability

Do not require a fixed inventory. Consider a state only when a force makes it relevant:

| Force | States or questions to consider |
|---|---|
| First use, no records, or no results | Initial or empty; what explains the absence and next action? |
| Fetching, background work, or delayed commit | Loading, partial, pending, cancellation, and status visibility. |
| User input or business rules | Validation timing, preservation of input, correction path. |
| Role, ownership, or authorization changes | Permission denied, reduced capability, request/escalation, audit path. |
| Network, sync, or cache | Offline/degraded, stale, conflict, retry, deduplication, re-entry. |
| Mutation or destructive effect | Confirmation, undo, delayed commit, partial commit, irreversible warning, completion proof. |
| System failure | Recoverable or unrecoverable failure, support route, retained context. |

Record why a likely state is not applicable when its omission would create risk. Use `templates/task-flow-state-model.md` for transitions and `templates/screen-state-inventory.md` for the resulting inventory. Diagrams are optional; readable tables are sufficient.

## Completion across roles

Trace a task beyond the initiating person's submission when another person must act. Name each actor, the handoff, what that actor receives, required authentication or account setup, the acceptance or rejection decision, resulting permissions/state, and recovery if the handoff expires or fails. Separate delivery evidence from outcome evidence. For example, sending an invitation is intermediate; the recipient still needs a valid acceptance path and the intended membership/access state. If that part is outside the approved scope, identify its owner and dependency explicitly instead of declaring the whole task complete.

# Usability Testing and Privacy

Usability work answers a bounded design question by observing authorized people attempt representative tasks. It does not manufacture customer truth, establish population prevalence, prove business outcomes, or replace accessibility conformance evaluation.

## Authorization Gate

Before recruiting, recording, or collecting any participant data, identify the responsible owner and confirm:

- the decision the work may inform and who has authority to act on it;
- participant characteristics grounded in actual users or affected roles;
- recruitment and compensation rules, including conflicts or power dynamics;
- accommodations and accessible participation paths;
- informed-consent information, voluntary participation, withdrawal, recording/transcription, and data use;
- collection minimization, access, storage, retention, deletion, and incident handling appropriate to policy and jurisdiction;
- whether legal, ethics, privacy, security, or institutional review is required.

An agent can draft materials and synthesize supplied authorized evidence. It cannot consent for a participant, invent a participant, impersonate research, or decide that policy and law do not apply.

## Plan From the Decision

Define:

1. research or design question;
2. behavior or decision the evidence could change;
3. participant characteristics and excluded populations, with rationale;
4. method and session context;
5. task starting state, realistic goal, completion evidence, and safety boundary;
6. prototype fidelity, unavailable behavior, and synthetic or approved data environment;
7. observation and note-taking method;
8. analysis plan and disagreement handling;
9. limitations and claims the study cannot support.

Choose participation scope based on decision risk, task and participant variation, accessibility needs, uncertainty, and the cost of missed failure. Do not use a universal participant count, time target, success threshold, or severity scale.

## Task and Facilitation Design

Write tasks as goals with enough context to act, not step-by-step instructions that reveal the interface. Avoid leading language and product terminology that the design is supposed to test. Include realistic interruption, permission, failure, or recovery only when the research question requires it and the environment can do so safely.

During moderated work, use neutral follow-ups about expectations, observations, and decisions. Distinguish what the participant did, what they said, what the facilitator inferred, and what the team decided. A preference statement is not automatically a task barrier; a completed task is not automatically free of confusion or risk.

## Safe Prototypes and Data

Use clearly synthetic fixtures such as `DEMO-CARD-NOT-VALID`, `workspace-demo-7`, or reserved `.example`/`.test` identifiers. Do not ask participants to enter real credentials, payment data, financial access, secrets, health data, or personal data into an unsafe prototype. When realistic data is necessary, use an approved environment and document safeguards, fidelity, retention, and deletion.

Do not claim a prototype performed a side effect it cannot perform. Mark simulated notifications, persistence, payments, approvals, or external-system changes as simulation and account for the fidelity gap in findings.

## Analysis and Reporting

Retain an audit trail from observation to implication:

| Layer | Example form |
|---|---|
| Observation | What occurred in the task and context |
| Participant interpretation | Quote or paraphrase only when actually recorded and authorized |
| Researcher inference | Why the behavior may have occurred, with alternatives |
| Design implication | Contract or hypothesis that might change |
| Decision | Accepted, rejected, deferred, or needs more evidence, with owner |

Group findings by task force, failure/recovery pattern, role, and context rather than only by screen. Preserve disagreement and negative cases. State whose behavior was not studied, which paths were simulated, where facilitator intervention changed the task, and what evidence would be needed to generalize.

A usability session reports observed barriers and successes within its tasks, participants, and environment. It does not establish WCAG conformance, accessibility across disability contexts, population prevalence, analytics performance, preference at scale, or product outcome. Use `templates/usability-study.md` for the plan and results, and route accessibility test design to [web-accessibility](../../web-accessibility/SKILL.md).

# AI Interaction Contract

Use alongside `interface-contract.md`. Describe observable behavior and link every consequential choice to approved evidence or an explicit assumption.

## Identity and authority

- Contract ID, surface, linked outcome/task:
- Roles, entry conditions, decision owner:
- Evidence and assumptions:
- AI role: assist / draft / recommend / rank / predict / route / execute:
- Human review or approval boundary:
- Prohibited or out-of-scope side effects:
- System/model/prompt/retrieval/tool version:

## Context and grounding

| Input or source | Owner and permission | Freshness/availability | Missing, stale, or conflicting behavior | What the person can inspect |
|---|---|---|---|---|
|  |  |  |  |  |

## Output and control

| State or output | What is shown | User action and validation | Persistence/side effect | Recovery, fallback, or escalation |
|---|---|---|---|---|
| Pending/streaming |  |  |  |  |
| Partial |  |  |  |  |
| Complete |  |  |  |  |
| Unsupported/uncertain |  |  |  |  |
| Failed/blocked |  |  |  |  |
| Escalated/corrected/committed |  |  |  |  |

## Feedback and handoff

- Optional alternate or opt-out path and what changes:
- Escalation trigger, destination, status, and transferred context:
- Feedback signal and purpose:
- User notice/consent, minimization, retention, and owner:
- How preference, task completion, and correctness are distinguished:
- Triage, evaluation, and release trigger:

## Change acceptance fixtures

| Fixture/scenario and provenance | Version/change under test | Expected observable behavior | Evidence/result | Verdict | Limitation or follow-up |
|---|---|---|---|---|---|
| Normal input |  |  |  |  |  |
| Ambiguous or unsupported input |  |  |  |  |  |
| Stale/conflicting context |  |  |  |  |  |
| Permission/privacy/unsafe case |  |  |  |  |  |
| Interruption/partial action/re-entry |  |  |  |  |  |

Use one verdict per fixture: passed, failed, blocked, inconclusive, or not-applicable. Record the reason and missing evidence; an unrun or blocked fixture cannot pass.

## Open decisions

| Decision | Alternatives and tradeoff | Owner | Resolution/revisit gate |
|---|---|---|---|
|  |  |  |  |

Route WCAG/ARIA and conformance evidence to `web-accessibility`; route model-quality and statistical thresholds to `agent-evals-and-observability` or `data-scientist`; route telemetry implementation and privacy controls to the owning specialists.

# Engineering Handoff

## Scope and Evidence

- Approved outcome/scope:
- Traceability artifact:
- IA, task/state, and interface contract links:
- Usability evidence and limitations:
- Accessibility work routed to `web-accessibility`:

## Dependencies and Risks

| Dependency or risk | Provider/owner | Contract or content needed | Fallback/recovery | Verification path |
|---|---|---|---|---|
|  |  |  |  |  |

## Observable Acceptance Criteria

| ID | Given/entry condition | When/action | Then observable result | Evidence at deployed boundary |
|---|---|---|---|---|
| AC-01 |  |  |  |  |

Include relevant permissions, accessible name/role/state expectations, persistence, state transitions, failure/recovery, interruption/re-entry, reflow, side effects, and completion evidence.

## Unresolved Decisions

| Decision | Owner | Impact if unresolved | Resolution gate |
|---|---|---|---|
|  |  |  |  |

# Interface Contract

## Identity

- Contract ID, surface, and linked outcome/task:
- Entry conditions and permitted roles:
- Evidence and assumptions:

## Behavior

| Element/content | Control and accessible name/role/state expectation | Action and validation timing | Transition/persistence/side effect | Permission and recovery | Responsive/inclusive behavior | Telemetry purpose |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

## Open Decisions

| Decision | Options/tradeoff | Owner | Impact | Resolution gate |
|---|---|---|---|---|
|  |  |  |  |  |

Route semantic, ARIA, WCAG, and test details to `web-accessibility`; do not substitute this table for accessibility conformance evidence.

# Outcomes-to-Design Traceability

## Inputs

| ID | Validated evidence link | Source/limitation | Chosen outcome and scope | Role or context |
|---|---|---|---|---|
| E-01 |  |  | O-01:  |  |

## Design Trace

| Outcome | IA/findability decision | Task/contract IDs | Pattern hypothesis and evidence | Accessibility routing | Open decision, owner, gate |
|---|---|---|---|---|---|
| O-01 |  |  |  |  |  |

## Review

- Can every behavior trace to validated evidence or an explicit assumption?
- Can every outcome trace to observable completion evidence?
- Does any optional persona or job change a decision and cite evidence?

# Screen and State Inventory

| Surface/state ID | Goal and entry point | Content/permission dependency | Applicable force and state | Recovery or next action | Responsive/inclusive constraint | Contract/AC link |
|---|---|---|---|---|---|---|
| SS-01 |  |  |  |  |  |  |

## Omission Review

| Potential state omitted | Why not applicable | Risk if wrong | Owner/review gate |
|---|---|---|---|
|  |  |  |  |

# Task Flow and State Model

## Task

- ID and outcome:
- Role, permission, and entry conditions:
- Evidence/contract links:
- Completion evidence:

## Flow

| Step | Actor/system action | Decision or alternative | Side effect/persistence | Recovery, cancellation, or re-entry |
|---|---|---|---|---|
| 1 |  |  |  |  |

## State and Transition Model

| State | Force making it applicable | Entry trigger | User-visible behavior | Allowed actions | Exit/recovery | Evidence |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

## Risk Review

- Irreversible action and warning/alternative:
- Partial commit, retry, and deduplication behavior:
- Permission/ownership/stale/conflict behavior:
- States considered not applicable and why:

# Usability Study Plan and Results

## Authorization and Plan

- Responsible owner and authorization:
- Decision/research question:
- Participant characteristics grounded in actual users:
- Method, prototype fidelity, and synthetic or approved data environment:
- Accommodations and accessibility considerations:
- Consent, recording/transcription, access, retention, withdrawal, and deletion handling:
- Limitations and what this study cannot establish:

## Task Scripts

| Task | Starting context | Completion evidence | Safety/privacy constraint |
|---|---|---|---|
|  |  |  | Use no real credentials, payments, financial access, secrets, or personal data. |

## Authorized Observations and Synthesis

| Observation ID | Authorized evidence link | Task/context | Observed barrier or success | Design implication | Confidence/limitation | Owner and next action |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

Leave results empty until authorized observations exist. Do not fabricate participants, quotes, consent, or findings.