Inspect before downloading
See what is inside
These previews come from the published bundle files, so you can judge the method and writing before using it.
Role guide
Interaction Designer Role Guide
Record the intended user group, task, product or service touchpoint, platform, environment, outcome, known evidence, constraints, and decision to support.
Read the fileOverview
Overview
Interaction design defines how people move through an interactive product or service and how elements behave in response to input, system events, errors, interruptions, and recovery.
Read the fileQuality rubric
Interaction Designer Quality Check
- Role grounding: Distinguishes interaction design from visual design, research, service design, content, and engineering while preserving legitimate overlap.
Read the fileBundle file
Interaction Design Review Workflow
1. Record the request, intended audience, decision, user and task scope, product or service context, platform, evidence supplied, and evidence date. 2.
Read the fileIs this bundle right for your task?
Who it is for
- People performing or supporting Interaction Designer work, plus teams reviewing its decisions and outputs
- Teams working in software, digital services, web applications
When to use it
- An Interaction Designer task needs a structured plan, evidence checklist, or review-ready output.
- A recommendation needs its assumptions, owners, risks, dependencies, and success measures made explicit.
What you need to provide
- The task objective, intended audience, working context, constraints, source material, and decision owner.
- Relevant reports, exports, examples, policies, prior decisions, and success measures available for the task.
Tasks and expected outputs
Questions it helps answer
- define interaction behavior and state coverage
- distinguish interaction design from neighboring disciplines
- review accessible interaction evidence without unsupported conformance claims
What it helps produce
- interaction model brief
- state and transition specification
- accessible flow review
- prototype and testing handoff
Practical example
Use it with an agent
Load the bundle as context, provide the evidence named above, then adapt this example to your situation.
Provide the task objective, intended audience, working context, constraints, source material, and decision owner. Ask the agent to approach Interaction Designer work by producing interaction model brief with a prioritized plan, evidence checks, owners, risks, and unresolved questions. Begin with UK Government interaction designer, then confirm that the reference is current and applicable. Inspect Interaction Designer Role Guide before drafting.
Context path: bundles/roles/interaction-designer
What the bundle includes
Frameworks
- interaction-role boundary map
- state-transition-interruption model
- evidence-and-conformance ledger
Evaluations
- Interaction Designer quality check
Sources used to build this bundle
These are the public references behind the role definition and operating guidance. The bundle does not replace current documentation or evidence from your site.
Limitations and safe use
Do not use this for
- Treating the bundle as a substitute for organization-specific authority, firsthand evidence, or accountable review.
Known limitations
- Role-support bundle only; not authority to conduct research, contact participants, own visual or service design, change a design system, access repositories or analytics, implement production behavior, release a product, or certify accessibility.
- Interaction Designer scope varies by organization, role level, product or service model, team composition, platform, and local charter; neighboring disciplines overlap.
- O*NET 15-1255.00, SOC 15-1255, ISCO-08 2513, and the user interface developer ESCO mapping are broad or adjacent taxonomy proxies, not exact role standards.
Safety notes
- Protect participant, customer, employee, usage, accessibility, health, authentication, security, product, roadmap, and unreleased-design information.
- Verify user evidence, business rules, supported contexts, selected accessibility standard and scope, systems, permissions, owners, and approval paths before relying on a deliverable.
- Require explicit confirmation before participant contact, data or repository access, design-system or production changes, publication, release, procurement, or conformance claims.