Interaction Design

For a long time screens were handed over as pictures. A designer drew a screen, an engineer built what was drawn, and the drawing said nothing about what happened after a press. The position and color of a button were settled; the half second after the press was blank. Whoever was building filled that blank in on the spot, which is why two screens in the same product often answered differently.

Early Pagedeck worked exactly that way. You wrote a document, pressed save, and nothing on the screen changed. The save was working, but with no visible answer people pressed again within three seconds. The same document got saved twice and two identical titles sat next to each other in the list. The tickets reaching Sofia said saving was broken; when Theo checked the logs, both saves had succeeded. What was broken wasn't the feature. It was the half second with no answer in it.

What Noa put into that gap wasn't a new feature. The button turns gray on press so it can't be pressed again, the word saving appears next to it, and when the request returns the word becomes saved. The duplicate-save tickets stopped the following week. Nothing about how the document was stored changed; what changed was that the product said something during the wait.

Interaction design is the field that promoted that half second into something you design on purpose. Which elements look pressable, what appears the instant one is pressed, what the product says while a person waits, whether a wrong move can be undone — all of it gets decided while the screens are being drawn. The subject is what a person does and what the product answers, rather than how many screens there are, and that is where the work separates from drawing static pictures.

It also separates from information architecture, which sits directly above it. Information architecture is the skeleton deciding what goes where and what it is called. Interaction design decides what happens once a person actually touches the thing sitting in that place. Get either one wrong and the product is hard to use, though the two failures feel different: a bad skeleton leaves people unable to find things, while a bad response leaves them unsure whether anything happened.

The terms under this heading fall into six groups. Flows cover where a person travels. Principles are the reasoning behind a choice, and laws are the part of that reasoning that hardened into numbers and tendencies. States cover how one element changes with the situation, motion makes those changes visible, and input covers what a person operates the product with.

Flows are the group that spans several screens rather than one. There are three, and they differ in how much they take in.

1. User flow — the full path of screens and branches a person passes through to reach a goal. Lay out everything from signup to sharing a first document and the branch points appear: where the path splits on whether someone is logged in, where it stalls because no payment method exists. Gaps invisible in a screen-by-screen review show up once the screens are strung together.
2. Task flow — the same thing with the branches stripped out, leaving one route through a single task. It's what you use to count how many steps sharing a document actually takes. Decisions like cutting five steps to three come from here, and so does noticing that two of those steps only exist because of how the data happens to be stored.
3. Happy path — the route things take when nothing goes wrong. Design files usually contain only this route, and incidents happen everywhere else. If a file over the size limit, a dropped connection, or a missing permission isn't drawn, whoever builds it fills those in.

Principles are the group that supplies the reasoning. There are five.

4. Affordance — the property of a thing that suggests what can be done with it from its shape alone. A door with a handle gets pulled; a door with a flat plate gets pushed. On screen it shows up as whether a person can tell what's pressable from what's just text, without being told.
5. Signifier — a cue deliberately added to announce that something can be operated. If an affordance is a property of the object, this is a mark the designer places on it. Screens have no physical handles, so borders, shadows, underlines and a pointer that changes shape stand in for them.
6. Mental model — the way a user pictures the product working in their head. Someone who reads folders as physical filing means they expect a document moved elsewhere to disappear from where it was. Build the product to leave a copy behind and that expectation breaks, and people describe the result as a bug.
7. Feedback — answering an action on the spot, the group the Pagedeck save button belongs to. How fast the answer has to come has its own benchmark, the Doherty threshold, which holds that a response inside 0.4 seconds keeps a person from letting go of the thought they were holding.
8. Progressive disclosure — revealing information in stages, only when it's needed. The share dialog opens with one thing, a copy-link button, and the fine-grained permission settings live behind a more options control. It's the judgment that a feature nine users in ten never touch doesn't belong on the first layer. The tenth user still needs it, which is why the answer is a second layer rather than removal.

Laws are the principles that hardened into figures. There are six.

9. Fitts's law — the larger and closer a target, the faster it gets hit. It's the reasoning behind making frequent buttons big and putting them where the hand already is. Making a destructive action small and distant is the same law applied in reverse.
10. Hick's law — the more options there are, the longer the decision takes. Seven plans on a pricing page take longer to get through than three, and some of the people counting the difference give up instead of choosing.
11. Miller's law — a person can hold roughly seven items in mind at once. It's the reasoning behind grouping menus and steps rather than listing them flat.
12. Jakob's law — users expect the conventions they learned on other sites to hold here too. Break the promise that a logo returns you to the home screen and the impression left is confusion rather than novelty.
13. Doherty threshold — a response inside 0.4 seconds keeps attention from breaking. Plenty of real work can't finish that fast, which is where designs that show a finished state first and reconcile later come from.
14. Gestalt principles — people perceive things that sit close together, or look alike, as one group. It's why adjusting nothing but the spacing between items changes which items appear to belong together, with no lines or boxes drawn anywhere.

The last three groups hold one term each. UI state covers how a single element differs by situation. One button has a default, a pressed, a disabled and a loading form; one list has a populated, an empty, a loading and a failed form. When only the default is drawn, everything else gets decided during the build, which is how one screen ends up showing nothing for an empty list while another shows an error message.

Motion design is the group that explains the transitions between those states through movement. A 0.2-second movement says where a panel came from, or where a deleted item went. The baseline for this group is that the purpose is explanation rather than decoration.

Gesture covers operations made with the hand — tap, swipe, long press. Gestures leave no trace on screen, so they're hard to discover, and the accompanying judgment is usually to keep a visible control that does the same job. Drag and drop and infinite scroll sit in this input group too. Dragging feels natural for reordering but is difficult for anyone with unsteady hands or no mouse, and a list that keeps appending is comfortable to browse but hard to return to at the twentieth item.

The six groups line up in order. Flows set which points a person passes through, principles and laws supply the reasoning for what appears at each point, states spell out every form a screen can take, motion connects them, and input decides how a person's hand reaches the whole thing.

"There's no screen for after this button. What happens when you press it?"

Only a static picture came over, and the answer hasn't been decided. Ship it this way and the engineer decides it.

"Can you send the empty state and the failure state too?"

Only the populated case was drawn, and the rest of the states need filling in.

"The affordance is weak here. Nobody's going to know that's pressable."

The shape alone doesn't announce that it can be operated, so it needs more of a cue.

At Pagedeck the phrase comes up most in the review where Noa and Theo look at design files together. Noa puts a screen up and Theo asks about the spaces between screens rather than the screen itself. What shows when this list is empty, where the message goes when a file passes the 20 MB limit, what the button looks like while a share link is being generated.

Anything the file doesn't answer gets decided in the room. Left undecided, Theo decides it while building, and that screen is the one another designer opens next quarter and asks why this one place behaves differently. Noa started keeping separate frames for each state in the source file after a few of those reviews. The file got longer and the review got shorter, which is the trade most teams end up making here.

The most common mistake is reading the field as adding flashy movement. The examples that circulate are usually eye-catching animations, so the reading is understandable. Most of what the work actually handles isn't movement, though — it's answers. Confirming that a press registered, saying a wait is underway, naming what went wrong when something fails. Invert the priority and you get a product with lovely transitions where nobody can tell whether the document saved.

The second is treating it as the last step after the screens are finished. In teams used to producing design files first and layering responses on top, that order feels natural. In practice, deciding the responses changes the screens. Deciding what a failure says requires somewhere to put the message, and if there's no room the layout has to be rebuilt. Push it to the end and the discovery arrives after the build has started, at which point the message gets bolted on as a dialog box. Bolted-on fixes usually stay, because the release that would clean them up never has room for work nobody can point at on a screen.