What is interaction design? The craft of how software responds

Interaction design is the design of the conversation between a person and a product: what they can do, what the product does in response, and how it makes the result understandable.

It sits between user experience and user interface. UX asks whether this flow should exist and in what order. UI decides the type, colour and layout. Interaction design owns the behaviour: the hover, the press, the loading, the empty state, the undo, the moment the network drops halfway through a save.

The reason the distinction is practical: a team can hire beautiful UI and still ship a product that feels frustrating, because nobody designed the second state, the failure state, or the wait.

The single highest-leverage habit in interaction design is enumerating states before building. Most quality problems in shipped software are undesigned states that a developer had to invent under time pressure.

• Empty: no data yet, and it is the first thing a new user sees. Design it as onboarding, not as an apology.
• Loading: is it under 300ms (show nothing), under a second (show a subtle indicator), or longer (show progress and what is happening)?
• Partial: some data arrived, some has not. Extremely common with real APIs and almost never drawn.
• Populated, and populated too much: what happens with three items, and with three thousand?
• Interactive: rest, hover, focus, active, disabled, and disabled with a reason the person can read.
• Error: recoverable, unrecoverable, and the one where the person lost work. That third one deserves real attention.
• Success: quiet confirmation, not a celebration on every save.

1. 01

   Acknowledge immediately

   Something must change within about 100ms of a press, even if the real work takes two seconds. Without that, people press again and you get duplicate submissions.

2. 02

   Show the work honestly

   A spinner says wait. A progress bar says wait this long. A skeleton in the shape of the result says wait, and here is what is coming. Pick the one that matches what you actually know.

3. 03

   Be optimistic where you can be

   For actions that almost always succeed, update the interface at once and reconcile in the background. This is the single biggest perceived-speed win available, and it obliges you to design the rare rollback properly.

4. 04

   Land the result where the eye already is

   Confirmation belongs next to the thing that changed, not in a corner toast a person has to hunt for.

Motion is not decoration. Its job is to explain what happened: where a panel came from, what turned into what, which element is now in charge. Motion that explains nothing should be deleted.

• Exits are faster than entrances. Waiting for something to leave feels like lag.
• Animate transform and opacity. Animating layout properties causes jank on mid-range phones.
• Never animate the same property from two places. Fights look like bugs, because they are.
• Respect reduced motion: keep the state change, drop the travel. This is accessibility, not a preference toggle.

The quality of an interaction is best measured when things go wrong. Two questions decide almost everything: how easily can a person recover, and how much do they lose if they cannot?

• Prefer undo over confirmation. A dialog asking are you sure trains people to click yes without reading.
• Reserve confirmation for the genuinely irreversible, and say what will be lost in specific terms.
• Validate at the moment of knowledge, not on submit. Tell someone the handle is taken while they are typing it.
• Write errors as instructions. Not invalid input, but card expiry must be in the future.
• Never lose typed work. Preserve form contents through a failed request. This one omission generates more anger than any visual flaw.

People forgive a plain interface. They do not forgive one that made them retype something.

• Touch: targets of at least 44 by 44 points, and nothing important within reach of a scrolling thumb.
• Keyboard: every action reachable in order, focus always visible, escape closes, enter commits. If you build a custom control, you own its keyboard behaviour.
• Pointer: hover can reveal, but it must never be the only path to something necessary.
• Screen reader: the state you show with colour or motion also has to be announced. Loading, error and selection all need text equivalents.
• Slow network on an old device: the most common real condition, and the rarest one in a design review.

• Are all states drawn: empty, loading, partial, error, success, too much data?
• Does every action acknowledge within about 100ms?
• Is there an undo for anything destructive, or a clearly worded confirmation?
• Does motion explain a relationship, and does it survive reduced-motion settings?
• Can the whole screen be operated by keyboard, with visible focus?
• Does typed work survive a failure?
• Is the primary action obviously the primary action, once, on the screen?
• Does it hold up on a slow connection and a small display?