The design discipline that determines how a product feels to use, not just how it looks

UI design and interaction design are often treated as synonyms. They're not.

UI design is primarily concerned with the visual layer: layout, colour, typography, iconography, spacing. It answers 'what does the product look like?'

Interaction design is concerned with the behavioural layer: what happens when a user clicks, hovers, submits, or waits. It answers 'what does the product do?' — and, critically, 'how does it communicate what just happened?'

A button's size, colour, and label are UI decisions. What the button does when pressed, what state it shows while an action is processing, how the system communicates success or failure — those are interaction design decisions. The visual design can be excellent while the interaction design is broken, and vice versa.

In practice, many product designers work across both disciplines. But treating them as the same thing leads teams to evaluate design work on visual quality while shipping products that confuse users at the moment of actual use — when they're doing something, not just looking at it.

The Interaction Design Foundation's overview covers the disciplinary history for those who want context, but the practical distinction above is what matters day to day.

A useful framework for thinking about what interaction design actually covers comes from Gillian Crampton Smith, later expanded by Kevin Silver. The five dimensions are:

1. Words — the language used in labels, error messages, instructions, and prompts. Language is interaction: it sets expectations, communicates state, and tells users what to do next
2. Visual representations — icons, images, and typography as communicators of meaning, not decoration. A loading spinner is interaction design. A progress bar is interaction design
3. Physical objects or space — the input method: touchscreen, mouse, keyboard, voice. Each has different affordances and conventions that IxD must account for
4. Time — duration, transitions, animation. How long before a loading state needs to give feedback? What easing curve communicates 'this happened instantly' vs 'this is a significant action'? Time is a dimension of design
5. Behaviour — the rules and logic of how the system responds: what triggers what, when, and under what conditions

Most design reviews focus on dimensions one and two. The experience often breaks at three, four, and five.

Dan Saffer defines a microinteraction as a contained product moment that does one thing. Toggling a setting on. Liking a post. Pulling to refresh. Setting an alarm.

Each has four components: a trigger, a set of rules, feedback, and loops or modes (what happens if you repeat it, or how it changes over time).

Microinteractions matter because they make up the majority of time users spend in a product. The main flows get attention in design reviews. Microinteractions get shipped at the end of a sprint when everyone's running out of time. And yet they determine whether a product feels polished or rough — whether actions feel confirmed or uncertain, whether users trust the system.

A file upload that shows no progress while processing. A form submission with no loading state. A toggle that changes value but doesn't visually confirm it. These aren't minor annoyances — they create {{LINK:cognitive-load}} because the user can't tell whether something worked. So they click again. Or they wait. Or they assume it failed and start over.

The teams that get this right are the ones where interaction states are reviewed with the same rigour as visual design — not treated as implementation detail.

Four patterns show up consistently:

Ambiguous states. The product doesn't communicate what's happening. A save button that looks identical before and after saving. A list that might be loading or might just be empty. Users in an ambiguous state either wait indefinitely or take a second action — clicking again, refreshing — that may cause unintended consequences.

Broken feedback loops. The user takes an action and gets no confirmation it worked. This is especially damaging in high-stakes contexts — financial transactions, data deletion, multi-step form submissions — where the cost of uncertainty is high.

Inconsistent behaviour. The same gesture or input produces different results depending on context, with no signal to the user that this is intentional. This breaks the {{LINK:mental-models}} users are trying to build and forces them to stay in a constant state of uncertainty.

Missing error recovery. Error states are designed as dead ends instead of recovery paths. The user hits a validation error, reads the message, and has no clear path forward. Good interaction design treats every error as a teaching moment — one that explains what happened and what to do next.

A {{LINK:heuristic-evaluation}} will surface most of these. Deciding which to fix first is where {{LINK:ux-benchmarking}} data helps prioritise.

The easiest way to recognise good interaction design: you don't notice it. The product responds the way you expect, feedback is immediate and clear, errors explain themselves, and nothing requires you to stop and think about whether something worked.

Stripe's dashboard is a commonly cited example in B2B SaaS — every action has clear feedback, errors are explanatory rather than cryptic, and complex data loads with states that communicate progress rather than silence. That didn't happen by accident; it reflects consistent investment in the interaction layer across every component.

For most product teams, the right starting point isn't a redesign. It's an audit of existing states: hover, active, focus, loading, empty, error, success, disabled. Mapping those states across every component will surface gaps faster than any other exercise. What doesn't have a defined state gets shipped with undefined behaviour — and undefined behaviour is what makes products feel unfinished even when the visual design is solid.

This is foundational in any {{INTERNAL:/services/product-design}} engagement. It's also where {{LINK:design-system}} components earn their value — they make consistent interaction behaviour the default rather than the exception.

Related: {{LINK:cognitive-load}}, {{LINK:progressive-disclosure}}, {{LINK:mental-models}}