Motion Design

Screens teleport by default. Press a button and the next screen is simply there; delete an item and the list redraws on the spot. Human eyes can't follow a swap that fast, and no amount of attention fixes that. You register that something changed without registering what changed or where it went, and the difference between those two sounds small until you watch someone hesitate over a screen they can no longer read.

At Pagedeck the problem showed up in the support queue first. Deleting one document from the list redrew the list instantly, and more than ten tickets a month said things like "I'm not sure the delete went through" or "I think a different document disappeared." Nothing was actually wrong. The deleted document, and only that one, had been removed. The gap it left was filled in zero seconds, so nobody got a chance to watch it go. Noa changed the row to fade and fold upward over 0.2 seconds and those tickets stopped.

The settings panel had the same shape of problem. Press the gear and the panel appeared dead center, which left people unsure where they now were. Several pressed the browser back button and landed outside the editor entirely, losing the document they had open. Once the panel grew out of the gear icon it came from, back-button presses dropped noticeably.

There was a handoff problem underneath both of those. Design files hand over a stack of still screens. The first screen is drawn and the next screen is drawn, but the change between them isn't, so Theo picked values screen by screen on his own judgment. One product ended up with panels that popped in at 0.1 seconds and panels that slid in over 0.6. Nobody experiences that as two different animation choices. To users it reads as a product whose response time is inconsistent, and inconsistent response reads as unreliable.

Motion design promotes that in-between stretch into something designed on purpose. It has one baseline: the purpose is explanation, not decoration. Interaction design above it covers action and response as a whole; this group takes only the moment when one UI state hands over to another — default to pressed, empty to filled — and carries it across at a speed a person can watch. The scope is narrow, and so is the test. If someone can tell what happened without the movement, drop the movement. If they can't, that spot needs an explanation, and how long and how fast to explain it becomes the next question.

The terms under this heading fall into three groups. Units decide what size of change counts as one movement, properties describe each movement in values, and accessibility covers the people for whom movement itself is the problem.

Units split by how large a piece of change you treat at once. There are two, and they do different jobs.

1. Micro-interaction — the short answer attached to one small action. Press a heart and it swells slightly before settling back; flip a toggle and the knob slides to the other side. The job here is feedback, saying on the spot that the press registered, which is why these run 0.1 to 0.2 seconds. Without even that much, people press again, and at Pagedeck that is how the same document once got shared twice. Push it out to 0.4 seconds and the reassurance turns into waiting, because now there is a stretch of time spent watching for the answer instead of moving on.
2. Transition — the movement bridging a whole state or screen change. Press a document card in the list and the card grows into the document screen. What survives is the fact that the screen you are looking at came out of that card, plus the promise that going back returns you to it. These usually run 0.2 to 0.3 seconds, and wider areas run a little longer. Distance counts as well. Give a panel rising from the bottom of the screen and a card swelling slightly in place the same duration, and the first feels rushed while the second drags. That is why a spec carries what moves how far rather than a number of milliseconds on its own.

Properties are the values that describe a single movement. A movement is settled once three things are: what changes (position, size, opacity), how long it changes for, and how the speed varies in between. The last two are terms of their own, and there is one more way of setting all three at once.

1. Duration — how long a movement runs, usually written in milliseconds. The size of the value tracks the area being moved. A button changing color takes 100 to 200; a full screen change takes 300 to 400. Zero gives you the teleport described above, and past 500 people start to feel they are waiting. For an action performed twenty times a day, a half-second movement adds up to ten seconds daily, which is the arithmetic that turns a pleasant detail into a complaint.
2. Easing — the curve describing how speed changes across that duration. Hold speed constant and the movement looks machine-pushed, because real objects slow down as they come to a stop. So things entering the screen start fast and ease to a halt, and things leaving start slow and vanish quickly. Leaving is fast because there is no reason to keep showing something a person is finished with. A few named curves cover almost every case: ease-out on the way in, ease-in on the way out, ease-in-out for moving between positions inside one screen. Fixing the set at three and writing down which goes where evens out the feel of a whole product better than adding more curves does.
3. Spring animation — describing a movement in physical values instead of a time and a curve. Give it weight, stiffness and damping and it overshoots the target slightly, comes back, and settles, the way a spring does. Because no duration is fixed in advance, a target that changes mid-movement doesn't cut the movement off. Letting go of a card you have been dragging and watching it carry your speed into its resting place is the signature case. The flip side is that you can't say when it ends, so it fits poorly where several elements have to move in a set order. Movement that follows a finger gets a spring; a screen changing in a fixed sequence gets a duration and a curve.

Accessibility is the group most easily left out. Reduced motion is the setting that cuts animation for users who find movement uncomfortable. Large sliding and zooming movements cause real nausea and dizziness in people with sensitive vestibular systems, which is a physical response rather than a preference. Operating systems carry the setting, and web and native apps can read it and pull their own movement back. Pulling back doesn't mean removing everything. Drop the long travel and the scaling, keep the fade, and the job of saying what changed survives. Pagedeck handles the setting with a single value. Rather than branching on every animation, the durations live in one place, and when the setting is on only the values used for large travel drop near zero. Fades stay as they are. With that in place, whoever builds the next screen doesn't have to remember accessibility for the rule to apply to their work.

The three groups chain into one sentence, and the order in that sentence is the order the decisions get made in. Units decide what moves, properties decide how long and how fast it moves, and accessibility decides how much of that movement to show, and to whom.

"Four hundred on this transition drags. Cut it to 250 and switch the easing to ease-out."

Too long to sit through, so shorten the time and keep only the sense of settling.

"Right now it just appears. Nobody can see where the panel came from, so they hit back."

The missing movement has cut the link between two screens.

"For users with reduced motion on, I dropped the slide and left the fade."

The operating system setting gets read, and only the large movement is stripped out.

At Pagedeck a motion spec travels with the design file. Noa puts a table next to the screen listing what changes, how many milliseconds it runs, and which curve it uses. Before that table existed, Theo guessed values screen by screen, and design QA produced the same question every time: why is this one so fast?

Having the table doesn't settle everything. Theo built list insertion so that sixty rows animated at once, and the screen stuttered visibly. Movements that change size and spacing make the browser recompute the whole layout from scratch, and sixty simultaneous recomputations are more than a frame can hold. Rewritten to change only position and opacity, the same sixty rows moved smoothly. So the spec now works in two hands: Noa decides what moves, and which properties carry it is settled with Theo.

Picking the numbers used to eat meeting time too, because everyone had a different instinct about them. The table now allows three durations and three curves. Small things get 150, ordinary ones 250, whole screens 350, and nothing in between is used. Arguments over whether a screen wants 240 or 260 disappeared, and someone new can pick a value from the table without asking anyone.

Reading movement as decoration is the most common mistake. Portfolios and promo reels are where most people meet elaborate motion first, which is where the assumption comes from. Inside a product the job is explanation: where the deleted item went, where the open panel came from, whether the thing just pressed responded at all. Treat it as decoration and it slides to the end of the schedule, and when time runs short it comes out entirely. The gap doesn't disappear when the work does. Whoever is building fills it in, and the product ends up answering at a different speed on every screen, which is exactly the state motion design was supposed to end.

Believing that longer and smoother is always better is the other one. Stretching a movement makes a design file look carefully made, and in a review that impression is what gets praised. But a design file gets watched once and a product gets used daily. Give opening a document 0.6 seconds and someone who opens twenty a day waits twelve seconds every day. That is why users who called it nice in the first week call it slow a month later. The test isn't whether it looks good but what the movement explains, and with nothing to explain, zero is the better number. Cutting isn't automatically right either. Take a full screen change down to 0.1 seconds and all that survives is the fact that something moved; what went where is invisible again. The floor is the shortest time an eye can follow, and going under it amounts to removing the movement while still paying for it.