← Go Back

Interaction Design (IxD)

What is interaction design?

Interaction design (IxD) is the practice of defining how users interact with a product: what happens when they tap, click, or type, how the system responds, and how the flow supports their goals. It covers behaviour, feedback, affordances, and the feel of the interface, not only how it looks.

Use it when: you’re defining or refining flows, controls, and feedback so the product feels predictable, responsive, and usable. IxD sits between information architecture and UI design.

Copy/paste checklist (one interaction or flow)

  • [ ] Trigger – What user action starts it? (tap, scroll, submit, etc.)
  • [ ] Feedback – What does the user see or hear immediately? (loading, success, error.)
  • [ ] State – What states exist? (default, hover, focus, disabled, loading, error.)
  • [ ] Outcome – What happens next? (next screen, message, or nothing.)
  • [ ] Error and recovery – What if something goes wrong? Can the user undo or correct?

Why interaction design matters

  • Makes interfaces predictable so users know what to do and what to expect.
  • Reduces errors through clear feedback and recovery.
  • Supports usability and accessibility (e.g. focus, keyboard, screen readers).
  • Turns wireframes and user flows into concrete behaviour.

What good interaction design includes

Checklist

  • [ ] Visible feedback – Every meaningful action has a visible (or announced) response. See usability and accessibility.
  • [ ] Clear affordances – Controls look like what they do. See affordance.
  • [ ] Consistency – Same action, same behaviour across the product.
  • [ ] Error prevention and recovery – Constraints and confirmations where needed; clear errors and undo where possible.
  • [ ] Keyboard and focus – Keyboard navigation and focus management considered from the start.

Common formats

  • State diagrams: Default, hover, focus, active, disabled, loading, error. Use for buttons, inputs, and key components.
  • Flow + feedback: User flow with notes on feedback and states at each step.
  • Prototype: Prototype with real interactions so you can test behaviour with users.

Examples

Example (the realistic one)

Interaction: “Submit” on a form. Trigger: User taps Submit. Feedback: Button shows loading (spinner or disabled state); form doesn’t double-submit. Outcome: Success → confirmation message and next step; error → message near the field or at top, form still editable. Recovery: User can correct and resubmit; no dead end. You document states (default, loading, success, error) and ensure accessibility (e.g. live region for success/error). You test in a prototype with usability testing.

Common pitfalls

  • No feedback: User taps and nothing visible happens. → Do this instead: Always show loading, success, or error; respect accessibility (e.g. announcements).
  • Unclear affordances: Buttons that don’t look clickable or inputs that don’t look editable. → Do this instead: Use affordance and convention so users know what’s interactive.
  • Ignoring keyboard and focus: Mouse-only interaction. → Do this instead: Design keyboard navigation and focus management so everyone can use the product.
  • No error state: Only the happy path is designed. → Do this instead: Define error and recovery for every critical action.
  • IxD vs UI design: UI design is the visual and layout layer; IxD is the behaviour and feedback layer. They work together.
  • IxD vs user flow: User flow is the path (steps); IxD is how each step behaves (states, feedback, controls).
  • IxD vs microinteractions: Microinteractions are small, local feedback (e.g. button press); IxD is the broader design of behaviour and flow.

Next step

Pick one critical flow (e.g. submit, or “add to cart”), document trigger, feedback, states, and error recovery, and test it in a prototype with usability testing. Check keyboard navigation and focus for the same flow.

Related Terms