Interaction Designer

For a long time screens were handed over as still pictures. A designer drew one frame with buttons and a list on it, and an engineer turned that frame into code. A picture holds only the finished moment. The half second right after a button is pressed, the list before anything has been added to it, what appears when the network drops — none of that is in any frame.

Somebody had to fill those gaps, and usually it was whoever was writing the code that week. The save button snaps back to its normal color immediately. The delete button on this screen opens a confirmation dialog; the delete button on that screen just deletes. None of those choices were wrong on their own; they were simply made separately, weeks apart, by different people under deadline. That is how one product ends up answering the same gesture differently depending on which screen you happen to be standing on.

Save was where it broke most often. Press it, see nothing happen, and people press again within about three seconds. The same document gets saved twice and the list shows two identical rows. The designer drew the button and the engineer built exactly what was drawn, and it still failed, because nobody ever decided what should appear between the press and the result.

An interaction designer owns that decision. The unit of the job is not the number of screens but the number of action-and-response pairs, and the whole territory the role covers is interaction design.

Given a screen, the first move is to write down everything that could happen on it, because one picture always turns out to be several.

1. List the states. The different forms one element takes depending on circumstance are its UI states, and a single list already splits five ways: loading, empty, populated, errored, and not permitted. Whichever one is missing here comes back later as a bug, because the situation still occurs whether or not anyone designed for it.
2. Pair every action with a response. The button turns gray and reads "saving" on press; a three-second notice appears when it finishes. Each of these small responses is a micro-interaction.
3. Set the rules for movement. What travels from where to where, over how many milliseconds — this overlaps with motion design. A panel that rises from the bottom teaches people to dismiss it by pushing it back down.
4. Build something clickable. Rather than describing it, wire the frames so people can press them and feel the response. The difference between 200 and 400 milliseconds is not a judgment anyone can make by reading about it, and the same goes for whether a panel sliding in feels responsive or sluggish.
5. Write the document engineering receives. Passing designs into implementation is handoff, and this one has to carry durations, easing curves, and what happens when someone presses twice in a row — as values, not adjectives.

After it ships, the role goes through the built version looking for places it diverged, and sends those back. Skip that pass and the 200 milliseconds agreed on in step four arrives in production as 600.

The closest partner is the UI designer, who owns the visual elements and their arrangement. One decides the size and color of a button while the other decides the 300 milliseconds after it is pressed, so the two split the same screen along different axes. The boundary with the UX designer, who designs the whole path, is a continuation rather than a wall: how many steps it takes to get from signup to a first document is that side's call, and what happens when a button in one of those steps is pressed is this side's.

Conversations with engineers happen in values. "Smoother" cannot be implemented; "250 milliseconds, bottom to top" can. So the role has to design while knowing what is buildable and what isn't, and the role that lives even deeper in that boundary is the design engineer.

Repetition gets reduced by recording decisions in the design system. Settle the loading indicator and the notice duration once per component, and the next screen inherits both instead of reopening the discussion from the beginning. Without that record, three years later the product dismisses notices on five different timings.

"Four of the five states on this screen are covered — the error one isn't. Can interaction fill it in?"

One of the forms the screen can take was left out of the design, and someone is asking for it to be specified.

"We don't have a separate interaction designer, so the product designer covers it."

A description of an organization where the roles haven't split apart yet.

"Double-press handling should probably be written into the interaction spec."

A request to document what happens on repeated presses, so implementation doesn't decide it on its own.

Pagedeck has nobody with this title, so Noa covers it. Building the new document-sharing screen, the first thing Noa did was not draw anything — it was to write down the six states the permission list could be in: loading, nobody invited yet, populated, invite failed, insufficient permission, and link expired.

Two of the six were not in the product spec, so they went to Mia for a decision. Whether an expired link should be regenerated or should prompt a request is a product question, not a design one. Listing the states forced the question into the open early, while it was still cheap to answer. That the design work surfaced a product decision before a single frame was drawn is a fair description of what the role does.

The most common assumption is that this is the person who makes animations. Movement is the most visible part of the output, so it stands in for the whole. But most of what the role decides doesn't move at all: what gets locked while something else is pressed, whether a failure reverts to the previous state or holds, what a second press on the same button does. Hand over only the movement and the screens get handsome while the press-twice-save-twice failure stays exactly where it was.

The second is that the title only exists at large companies. Below about a hundred people the work usually does sit with the product designer. But having no title is not the same as having no work. With nobody assigned, decisions about action and response don't disappear — they get distributed one at a time to whoever implements them, and the product grows up answering the same gesture differently on every screen.