Skip to main content

Hire interaction designers

A screen is not the interaction.

Interaction designers translate observed tasks and product rules into accessible behavior across states and input methods. The brief should cover actions, feedback, waiting, errors, recovery, content and technical boundaries. Werkon would assess design judgment, prototyping and collaboration against those needs, while accountable product and accessibility owners agree the acceptance evidence for the actual user journey.

Responsibility contract

Keep product, research, content, technical, and acceptance authority explicit.

An interaction designer can frame behavior, make states and consequences visible, prototype alternatives and improve patterns. They cannot manufacture a user need, make policy true, approve specialist evidence or turn a design file into production authority. Name the decisions and collaborators before assigning the work.

01

Client product and professional authority

Named client owners decide which outcome matters, which behavior is legitimate and what evidence is acceptable.

  • Product service policy and operations owners define the intended outcome, affected people, priority, business and operating rules, constraints, non-goals, decision rights, funding boundary and acceptable consequence of change.
  • User-research content accessibility engineering architecture data security privacy legal compliance quality analytics support and platform owners define and accept findings, language, semantics, feasibility, controls, evidence and risks in their domains.
  • Named product design accessibility technical and release owners approve the behavior baseline, unresolved tradeoffs, production implementation, residual risk and final acceptance. An interaction designer provides evidence and recommendations but does not silently inherit those authorities.
02

Interaction designer contribution

The designer makes product behavior understandable, testable and transferable. Scope varies by product, platform, complexity, seniority and delegated authority.

  • Translate observed tasks, user context, research and product rules into end-to-end flows and explicit state models; identify entry and exit conditions, available actions, content needs, decisions, dependencies, interruptions, permissions and unresolved assumptions before choosing a screen pattern.
  • Design navigation, controls, input, feedback, progress, confirmation, errors, empty states, partial success, cancellation, undo and recovery across relevant devices and input methods; use familiar semantic patterns when they fit and document why deviation is necessary.
  • Prototype the riskiest behavior at an appropriate fidelity; collaborate in research and implementation; specify states transitions content semantics keyboard focus motion and responsive behavior; review the built result on real targets; retain design decisions, evidence and a receiving-owner handoff.
03

Shared product-behavior operating model

Interaction quality remains a multidisciplinary outcome, not a handoff from a drawing tool to an implementation queue.

  • Users and researchers provide evidence about tasks and barriers; product service policy and operations owners decide outcomes and rules; content designers make language and information understandable; service and visual designers align wider journeys and expression.
  • Engineers and architects shape feasible native behavior, state ownership, latency and failure handling; accessibility and quality specialists define evidence; data security privacy legal support analytics and platform owners shape constraints, instrumentation and acceptance.
  • The team reviews design and implementation together, records meaningful divergence and validates production behavior; hiring owners confirm practical capability, collaboration, product and platform fit, engagement terms and current availability; accountable people decide whether to proceed.

Capability evidence

Assess one consequential transition across state, access, failure, and recovery.

A portfolio walkthrough can hide how the work was decided and whether it survived implementation. Use one real transition where delay, error or misunderstanding has a consequence. Ask the person to make every state and path inspectable.

01

Task, context, flow, navigation, and state model

Provide an important task that begins outside the product, crosses two channels, has several user types, a hidden prerequisite, incomplete research, internal terminology and a proposed navigation structure. Ask the person to frame behavior before drawing screens.

Confirm: The person names the actor, goal, trigger, prior knowledge, environment, device and access context; distinguishes observed evidence from assumptions; maps the whole task rather than one screen; identifies entry, exit, interruption and return points; separates user language from organizational structure; defines product states, state owners, freshness, permissions and available actions; exposes branching, loops, prerequisites, dependencies and irreversible points; chooses navigation that supports orientation and return; shows what the system knows and what remains unknown; records hypotheses and research questions; and keeps product and policy choices with accountable owners.

02

Actions, feedback, waiting, errors, and recovery

Provide a form with delayed validation, an asynchronous operation, duplicate submission risk, a destructive action, network loss, a permission failure, a partial result and a user returning later. Ask for the complete interaction contract.

Confirm: The person makes controls identifiable and consequences clear before activation; distinguishes selected, focused, pressed, disabled, unavailable and read-only states; gives immediate proportionate feedback without relying on color or motion alone; preserves user input; prevents or safely handles duplicate intent; designs progress, cancellation, timeout, retry and resume around actual system semantics; places specific errors near their source and summarizes when useful; separates user-correctable errors from service failures and access decisions; confirms success and changed state; provides undo or another recovery path where the consequence warrants it; covers stale data, conflicts, offline and partial success; and avoids optimistic behavior that contradicts server authority.

03

Inclusive input, semantics, focus, reflow, and motion

Provide a custom interactive pattern expected to work with touch, mouse, keyboard, voice, switch and screen-reading software at narrow width, high zoom, large text, high contrast and reduced motion. Ask whether to use it and how equivalent behavior will be accepted.

Confirm: The person starts with native elements and familiar patterns when they meet the need; defines role, name, value, state, relationship and status communication only as required; specifies logical reading and focus order, visible focus, keyboard operation, focus entry restoration and escape; does not infer keyboard support from pointer events; provides alternatives to gestures and drag; keeps targets and spacing usable; preserves meaning without color, shape, position, sound or motion alone; supports reflow, text enlargement, orientation and platform settings; removes or replaces nonessential motion under user preference; makes time limits controllable where possible; includes cognitive needs such as clear purpose, consistent controls, preserved context, error prevention and help; and plans human testing with relevant disabled users and assistive technologies rather than treating a checklist as complete acceptance.

04

Prototypes, patterns, implementation, validation, and continuity

Provide a design-system component that almost fits, a high-fidelity prototype, engineering constraints, changed content, analytics with ambiguous drop-off, an implementation that diverges and an absent designer. Ask what should be reused, tested, built and retained.

Confirm: The person states the uncertainty each prototype must answer and chooses the lowest useful fidelity; protects prototype access and data; never treats prototype code as production-ready; compares existing patterns against task, content, state and access needs before reuse; documents justified extensions with anatomy, variants, properties, states, transitions, keyboard behavior, content rules and examples; brings engineers content researchers accessibility and quality specialists into decisions early; reviews the built behavior on real browsers devices and assistive paths; distinguishes design fidelity from task success; connects findings and product signals without inventing causation; records accepted divergence and open risk; versions the interaction contract alongside implementation; and leaves another owner able to reconstruct, test and change the behavior.

Assessment sequence

Take one risky transition from observed task to accepted product behavior.

Interaction design becomes screenable when state, consequence, access and evidence remain visible. Start with the point where people currently lose context, work or control.

  1. 01

    Frame the task and authority

    Record people, goal, trigger, context, current path, evidence, constraints, relevant rules, content and data sources, product research design accessibility technical and release owners, assumptions and the consequential transition to resolve.

  2. 02

    Model states and complete paths

    Define entry and exit, system and user state, permissions, available actions, branches, waits, interruptions, returns, empty and partial states, error classes, recovery, cross-channel seams and the exact decisions still needing authority.

  3. 03

    Prototype the riskiest behavior

    Choose the lowest fidelity that can test the uncertainty; use or adapt familiar patterns deliberately; include realistic content data timing and failures; cover required input and access paths; record hypotheses and discard unsupported options.

  4. 04

    Specify and inspect the implementation

    Transfer anatomy, variants, states, transitions, feedback, content, semantics, focus, keyboard, motion, responsive behavior, errors and acceptance examples; pair with engineers and specialists; review real target behavior and record justified divergence.

  5. 05

    Validate the task and transfer control

    Observe task completion and barriers across required people and access paths; distinguish findings from interpretation; update the pattern and decision record; link released behavior to product signals with limits; then let another owner run the next review.

Operating loops

Keep every control attached to a task, state, consequence, and observed result.

Interfaces drift when controls lose their purpose, feedback stops matching system state, accessible paths split from the main behavior or design records stop at handoff. These loops keep product behavior legible.

  1. 01

    Task, context, and state loop

    Can each proposed interaction show what the person is trying to do and what state they enter?

    Working evidence: Actor, goal, trigger, physical social technical and emotional context, prior step, current behavior, research source, assumption, product rule, entry state, state owner and freshness, permissions, available action, desired outcome, non-goal and unresolved question.

  2. 02

    Action, feedback, and recovery loop

    Can each action show its consequence, immediate response and safe route through delay or failure?

    Working evidence: Control purpose and label, enabled and unavailable conditions, action input, authority, immediate feedback, pending state, progress, duplicate handling, timeout, cancellation, error class, preserved work, correction, retry, undo, return path, success confirmation and resulting state.

  3. 03

    Access, input, and equivalence loop

    Can people complete the same task across every required input and access condition?

    Working evidence: Native element or pattern rationale, role name value and state, reading and focus order, keyboard commands, focus restoration, target size and spacing, pointer gesture alternative, voice and switch path, status announcement, reflow and text-size behavior, contrast mode, motion preference, time control, assistive-technology result and human acceptance owner.

  4. 04

    Prototype, release, and learning loop

    Can a shipped interaction show which uncertainty was tested and what changed after real use?

    Working evidence: Hypothesis, prototype fidelity and limits, participants and access needs, observed behavior, finding and interpretation, design decision, reused or changed pattern, implementation contract, accepted divergence, target evidence, release identity, product signal, causal limit, open risk, next experiment and receiving owner.

Continuity controls

Recover without one designer, private prototype, or stale frame library.

Continuity belongs to the client product-behavior system, not a promise about one designer. Tasks, states, decisions and acceptance evidence should survive role and provider change.

Client-held task and authority record
Affected people, tasks, context, research evidence, product and policy rules, current path, desired outcome, constraints, non-goals, assumptions, decision owners and professional acceptance responsibilities remain reviewable by the client.
Versioned state and interaction contract
Flows, navigation, state models, actions, permissions, content, data dependencies, feedback, loading, empty, error, offline, interruption, cancellation, recovery and success behavior retain identifiers, rationale, versions and owners beyond individual screens.
Accessible pattern and implementation evidence
Component anatomy, variants, properties, semantics, keyboard and focus behavior, pointer alternatives, responsive and text-size behavior, motion preferences, acceptance examples, prototypes, findings, implementation divergence, target results and open defects remain linked in client-controlled systems.
Demonstrated handoff and pattern exit
A receiving owner can reconstruct one transition, explain the task and current state, find the responsible product and specialist owners, operate the prototype, test error and access paths, locate accepted implementation evidence, revise the pattern when it no longer fits and run the next review.

Fit check

Use an interaction designer when product behavior must become understandable and testable.

Good reason to begin

  • The product has accountable owners and evidence about user tasks, but flows, state, controls, feedback, recovery, accessibility, pattern use or implementation behavior need sustained specialist design.
  • The team can involve real users and relevant disabled participants, expose product rules and technical constraints, collaborate across content engineering research quality and accessibility, and provide a safe consequential scenario.
  • The client wants fewer avoidable errors and dead ends, accepts that attractive frames are not acceptance evidence, and will retain design decisions, implementation records and product authority.

Resolve before beginning

  • The request is only for visual styling, asset production, a Figma operator, a design-system skin or more screens, with no task evidence, behavior problem, engineering collaboration or acceptance path.
  • There is no accountable product owner, no access to users or research, no content or technical owner, no way to test relevant access needs, no implementation review or no authority to resolve contradictory rules.
  • The designer is expected to invent user findings, approve policy, content truth, architecture security privacy accessibility or release, conceal a known barrier, copy a competitor or make prototype behavior appear production-ready.
  • The answer begins with a fashionable gesture, animation, component library, design tool or visual treatment before the task, state, consequence, platform constraints and evidence are understood.

Source basis

Sources behind the control model.

  • 01

    Government Digital and Data Profession

    Interaction designer capability framework

    The role record, updated 28 August 2026, defines interaction design across overall service flow and individual elements, with evidence-based, inclusive, strategic, collaborative and iterative design skills at distinct levels. A government capability framework does not prove a particular person's fit or transfer every responsibility to the role.

  • 02

    ISO

    ISO 9241-110:2020 interaction principles

    ISO's second edition was confirmed current in 2025 and provides technology-independent principles for interaction between users and systems. The public abstract excludes detailed domain specifics, aesthetics and corporate identity and does not establish local conformance.

  • 03

    ISO

    ISO 9241-210:2019 human-centred design

    ISO's confirmed current record covers human-centered design principles and activities across the lifecycle of interactive systems. Its public abstract does not provide every method or detailed accessibility, usability, health or safety requirement.

  • 04

    GOV.UK Service Manual

    Designing good government services

    The guidance treats a service as an end-to-end task with no dead ends, clear decisions, familiar behavior, accessible use and respectful handling of information. Its government-service context is not a universal product specification.

  • 05

    GOV.UK Service Manual

    Making prototypes

    The guidance recommends selecting prototype fidelity for the learning need, testing alternatives and keeping protected prototypes distinct from live services. Prototype code is explicitly not production evidence by itself.

  • 06

    GOV.UK Service Manual

    Make the service simple to use

    The Service Standard calls for simple, intuitive, comprehensible end-to-end behavior tested with users across relevant devices. Its requirements apply to the stated public-service setting and do not prove another product usable.

  • 07

    GOV.UK Service Manual

    Make sure everyone can use the service

    The guidance includes disabled people, protected characteristics, digital skills, connectivity and assisted support, and calls for representative research. Local audience, law and acceptance still require accountable review.

  • 08

    GOV.UK Design System

    Patterns

    The catalog describes patterns as reusable solutions for specific user-focused tasks and page types that must be adapted to context. A pattern is not automatically suitable outside its evidence, service and implementation conditions.

  • 09

    GOV.UK Design System

    Components

    The catalog supplies documented reusable interface parts and coded examples for consistent government services. Reuse still needs task fit, correct content, complete states, integration and local accessibility testing.

  • 10

    GOV.UK Design System

    Error message component

    The component guidance distinguishes validation errors users can correct from eligibility, permission, capacity and service failures, and connects messages to affected questions. Its wording and visual treatment remain context-specific.

  • 11

    W3C

    Web Content Accessibility Guidelines 2.2

    The current Recommendation provides testable accessibility criteria for perceivable, operable, understandable and robust web content and acknowledges that conformance does not cover every user need.

  • 12

    W3C

    WAI-ARIA 1.2

    The Recommendation defines roles, states and properties that expose dynamic interface semantics to assistive technology. ARIA complements a host language and does not create native behavior, keyboard operation or usability automatically.

  • 13

    W3C

    Using ARIA

    The practical guide makes native HTML the first choice when it supplies the required semantics and behavior. Additional ARIA should repair a real semantic gap, not restyle or replace working native interaction.

  • 14

    W3C Web Accessibility Initiative

    ARIA Authoring Practices Guide introduction

    APG synthesizes accessible widget and keyboard guidance but explicitly states that it is non-normative and not a user-interface design system. Examples require production-quality review and testing.

  • 15

    WHATWG

    HTML Living Standard: User interaction

    The living standard defines focus, sequential navigation, activation, inertness, dialogs and related browser behavior. User-agent variation and platform preferences remain part of real acceptance testing.

  • 16

    W3C

    Pointer Events Level 3

    The June 2026 Recommendation defines hardware-independent pointer input for mouse, pen and touch while explicitly excluding keyboard and keyboard-like assistive interfaces. Pointer support therefore cannot stand in for equivalent keyboard behavior.

  • 17

    W3C

    Media Queries Level 5

    The current specification defines user-preference features including reduced motion, contrast, color scheme, reduced transparency and reduced data. Detecting a preference still requires a suitable product response and browser testing.

  • 18

    W3C Web Accessibility Initiative

    Making Content Usable for People with Cognitive and Learning Disabilities

    The Working Group Note adds user needs, patterns and testing guidance for cognitive accessibility beyond WCAG conformance. It is supplemental non-normative guidance and should be applied with people in the intended audience.

  • 19

    Apple

    Human Interface Guidelines: Accessibility

    Apple's current platform guidance covers familiar interactions, multiple sensory and physical paths, larger text, control targets, gesture alternatives, keyboard access, assistive technologies, cognitive load and motion comfort. It is platform-specific and not proof of implementation support.

  • 20

    Android Developers

    Principles for improving app accessibility

    Current Android guidance requires meaningful interactive elements to expose understandable purpose and supports testing with platform accessibility services. Compose and Views implementations differ and require target-app evidence.

[ WORKFLOW / SYSTEMS AUDIT ]
THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the WorkflowStart with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Choose the next useful path.

Stay with the operating question. The technology can wait until the work is clear.

01

Hire HTML and CSS specialists

Join interface implementation to visual design, interaction behavior, and accessibility.

Open path02

Browse the hire map

Compare interaction-design capability with product, research, content, analysis, engineering, quality and accessibility roles before fixing the title.

Open path03

Review how Werkon works

Use the delivery model to inspect how authority, evidence, scope, implementation, verification, handoff and client ownership fit together.

Open path04

Review product design

Start with the broader product-design path when problem framing, product structure, interaction and visual direction need one integrated engagement.

Open path05

Review quality assurance and testing

Start with quality assurance when test strategy, environments, automation, risk coverage, release gates and defect learning need their own professional owner.

Open path