How a UX designer thinks

The twelve principles of animation were written in the 1930s by people animating characters with faces, weight and intent. An interface has none of those. It is a grid of rectangles that never acts on its own and only ever responds.

So the interesting question is not what the twelve principles are — Raphael Salaja has already written that page, and it is better than a summary of it would be. The interesting question is which ones survive the translation, which ones arrive damaged, and which two do not make the trip at all.

Every demo below is the same 24px square on the same 184px track. If a principle needs a mascot to be legible, it was never an interface principle.

Squash and stretch

Deform the container, never the words

Deformation is how the eye reads weight. The rigid block on the left could be made of anything; the one on the right is heavy, and you know that without being told.

The catch is that interfaces are mostly rectangles with words inside them, and words do not squash. Deform a container by 30% and whatever it contains gets sheared with it — the fastest way to make a considered interface look cheap.

What survives is the small version: a button that dips under a press, a sheet that overshoots by a few pixels before settling, a toggle knob that stretches slightly as it crosses. Deform the container, never the contents, and keep it under about 5% anywhere text is involved.

Anticipation

The hover state is the wind-up you already have

Six pixels backwards before a hundred and sixty forwards. The wind-up tells you the movement is coming, so the eye is already travelling when the thing does.

In an interface you are paying for that in latency, which changes the maths. A wind-up before a menu opens is 80ms you have added to every single use, forever. The honest version is almost always already there and free: the hover state is anticipation, the pressed state is anticipation, a delete button that turns red before you release is anticipation.

Spend real milliseconds on it only where the outcome is destructive or genuinely surprising. Everywhere else, let the pointer do the work.

Staging

Staging is deciding what holds still

Three rows arrive on the left and none of them leads, because they all do. On the right one row moves and the other two stay where they are, so the eye has somewhere to go.

This is the principle I reach for most and the one that is least about motion. Staging is mostly a decision about what doesn't animate. A dimmed backdrop, a row that holds still while its neighbours settle, a panel that arrives after the thing behind it has receded — in each case the effect comes from the restraint, not the movement.

If everything on screen is animating, you have not staged anything. You have just made the page busy and left the reader to work out where to look.

Straight ahead and pose to pose

Two poses and a curve, until that is not enough

No demo for this one, because it describes how you work rather than what anyone sees.

Straight ahead means drawing every frame in order and finding the motion as you go. Pose to pose means fixing the key positions first and filling the gaps afterwards. CSS makes the second one the default: you declare two states, name a curve, and the browser invents everything between them.

Straight ahead is what you are doing the moment you hand-write eleven keyframe percentages. Sometimes that is right — the shake further down this page is eleven hand-placed numbers, because a shake has no in-between worth interpolating. But every percentage you write is a number someone has to maintain. Two poses and a curve until that provably isn't enough.

Follow through and overlapping action

Cap the cascade, not the step

Sixty milliseconds between three rows, and a stack that arrived as a block now arrives as a sequence. Nothing else changed.

It is the cheapest sophistication available in interface motion, and the easiest to overdo, because the cost is multiplied by the number of things on screen. Sixty milliseconds across three rows is 120ms of tail. Across twenty rows it is 1.2 seconds, and the twentieth row is now arriving long after the reader has started reading the first.

Cap the total, not the step. Decide the whole cascade gets 200ms and divide by however many items you have — and stop staggering entirely past a dozen, where nobody can perceive the sequence anyway.

Slow in and slow out

Easing is the principle the others are built on

The one everybody already knows, and the one with the largest return. I have written about it before, so: nothing you have ever touched moves at a constant speed, cubic-bezier(0.2, 0, 0, 1) covers almost everything, and ease in is for things leaving.

Worth adding here: this is the principle the other eleven are built on. Anticipation, follow-through and arcs are all just easing applied to more than one property at a time.

Arcs

Two timing curves make an arc

Both squares travel the same 160px right and 32px up. The left one interpolates both axes on the same curve, which is the definition of a straight line. The right one runs the vertical axis on an ease-out and the horizontal on a linear ramp — two curves, and the path bends.

That is the whole implementation. No path maths, no motion library. Any two properties on two different timing functions will describe a curve.

It is also the principle with the narrowest application here. Most interface motion runs along a single axis, and a curve on an 8px slide is a curve nobody can see. Arcs earn their keep on long diagonal travel — something flying to a corner, a card returning to a stack — and nowhere else.

Secondary action

The second thing must be smaller and later

On the left, two marks of the same size at the same moment: two primaries, no hierarchy, and the eye has to pick. On the right the second mark is smaller and 160ms late, so it reads as consequence rather than event.

Secondary action is the flourish that confirms the main one — the tick after the save, the count that ticks up after the row lands. The rule is that it must be subordinate in both size and time. Something equally large and equally prompt is not a secondary action, it is a second thing happening, and two things happening at once is how a screen becomes noise.

The version on this site is the sound a tab makes when you tap it. It carries nothing the icon's hop does not already carry. It just makes the hop feel like it happened.

Timing

One kind of event, one duration

Duration is the difference between snappy and sluggish, and the numbers are smaller than instinct suggests. Small things moving short distances: 150–200ms. Larger surfaces: up to 300. Beyond that you are charging the reader for a performance they did not ask to see.

The part that gets missed is consistency. Every animation of the same class should take the same time — every row entry, every panel, every page. Two durations for the same kind of event is not variety, it is a bug that nobody can name but everyone can feel. On this site a press always takes 120ms, a tab hop 240ms and a surface opening 300ms, whatever set it off.

Exaggeration

One exaggerated moment per screen

The left square changes colour. You would not notice it in a form you were filling in, and neither would anyone else. The right one moves four pixels, four times, and cannot be missed.

Exaggeration is what you have left when your palette is two greys and a black. It is also the most expensive thing in this list, because it is a loan taken against the reader's attention: it works precisely as long as it is rare. A form that shakes on error is helpful. A form that shakes, bounces and pulses through every field is a form nobody trusts.

One exaggerated moment per screen. If you need two, the screen is the problem.

Solid drawing

Depth is only for things that really float

No demo, because this site uses the principle almost nowhere.

Solid drawing is about volume and weight — shadows, layering, perspective, the sense that a thing has a back as well as a front. It is the principle behind every elevation scale you have ever used.

Depth is a promise about layers, and this site is a 640px column on one flat layer. So the column gets no shadows, no z-axis and no perspective: a shadow there would imply a hierarchy that does not exist. The only things that cast one are the few that genuinely float above the page — the dock, the AI composer, a zoomed image — and their shadow is a single soft 5% drop, the same everywhere.

The cost is real: on the page itself there is no way to say this sits above that, so I say it with position and contrast instead. If you do use depth, the only thing that matters is that the light comes from one place and stays there.

Appeal

Appeal is the part nobody asked for

The last one cannot be specified, which is why it is last and why it has no demo. The nearest thing to one is at the bottom of this page: tap a tab and its icon hops, and a small sound plays.

None of that is necessary. The site would pass every test it passes now without it. It survives because appeal is the difference between something that works and something somebody made, and that difference is most of why anyone comes back to a personal site at all.

It is also the first thing that should go the moment it gets in the way of reading. Appeal that costs the reader something is not appeal, it is decoration with a better name.

Verdict

Ten of the twelve translate

The other two — squash and solid drawing — arrive damaged for the same reason: they describe bodies, and an interface does not have one.

The ones that survive intact are the least glamorous of the set. Timing, staging, follow-through. Nobody has ever complimented an interface on its staging. They just find what they were looking for slightly faster than they expected to, and never think about the page again.

A page change is the largest thing an interface does. Every pixel below the masthead is replaced at once. It is also, on most sites, the only thing nobody designed — the router does it, and whatever falls out is what the reader gets.

Raphael Salaja's 12 principles of animation is the best short account I know of where these ideas come from, and it covers all twelve. This is the narrow version of one of them, and it starts with a question: is the quarter second between one page and the next worth spending anything on at all?

A cut makes the reader start over

Switch pages on the left. The new content is simply there. Nothing tells you the page changed, or which part of it changed, so the eye goes back to the top and re-reads the column to find out.

Switch pages on the right and you know within a frame. Eight pixels of travel and a fifth of a second is enough to say this is new content in the same place rather than here is a document you have never seen.

That is the entire argument, and it is not an aesthetic one. Motion is the cheapest way to preserve the reader's place. Everything else about a transition — the curve, the blur, the exact millisecond — is detail work on top of that one job.

Direction is information

Watch which way the right-hand box arrives. Gallery sits to the right of Experience in the dock, so it enters from the right. Going back brings the page in from the left.

Eight pixels, and it maps the dock onto the page. The reader never articulates it, but after two or three switches they know which way the site is laid out, and a swipe back feels like it should go somewhere they have already been.

Get it backwards and it is worse than nothing — the interface is now lying about where you are. A transition that carries no information is decoration. One that carries wrong information is a bug that never gets filed, because nobody can name what felt off.

Time it against the tap, not the clock

The transition here runs for 240ms. Not because research settled on that number, but because the tap that starts it already takes 240ms: the tab's icon hops up 2px and settles in that time, so the page lands exactly as the icon does. Two animations sharing a rhythm read as one event. Two that don't read as a glitch.

The ceiling is set by the navigation itself. Every route is prerendered and prefetched, so the content is ready before the finger lifts — which means the entire transition is a delay I have chosen to impose. It has to be short enough that it never becomes the reason the site feels slow, and it has to survive the fiftieth tap, not just the first.

Move the page, not the furniture

What stays still does more work than what moves. The name, the signature, the intro and the dock do not shift by a single pixel during a page change. Only the content beneath them moves.

That fixed point is what makes eight pixels legible. If the whole column slid, there would be nothing to measure the movement against, and the reader would be tracking the entire screen instead of the one part that changed.

It is also the thing most likely to break silently, so I check it by measuring rather than by looking: sample the masthead's bounding box every frame across a navigation and assert it never moves. Thirty-eight frames, zero movement. A screenshot would not have caught a one-pixel reflow, and a one-pixel reflow is exactly what a reader feels without being able to name.

Blur costs more than distance

The recipe I started from used a 3px blur on the incoming page. At 16px that dissolves the letterforms into grey for most of the transition, and reading is the one thing the page is for.

2px softens the arrival without breaking the letters. That is the trade: a little less softness for type that stays legible the whole way in. Any blur also forces the browser to re-rasterise the entire page every frame, which on a gallery a few thousand pixels tall is real work for something on screen for a fifth of a second. Distance is nearly free. Blur is not, and not only to the GPU.

The exit you don't get

Being honest about the mechanism: in an App Router site the outgoing page is unmounted in the same commit that mounts the new one. There is never a frame holding both. So this animates arrivals only — nothing slides out, because by the time anything could, it is gone.

For a while I read that as a limitation to work around. It mostly isn't. The eye is already looking for what arrives, not grieving what left. There is a way to have both, and one day I will probably take it, but it means running a second animation system for a half of the transition the reader was never watching.

Then take it away twice

Two cases get nothing at all.

The first landing does not animate. There is no previous page, so there is no direction, and sliding the content in from an arbitrary side would be motion for its own sake — the exact thing this post is arguing against.

And prefers-reduced-motion turns all of it off. For some people the transition I have just spent a thousand words on is a headache. It carries information, so I would rather it stayed; it is not important enough to make anyone ill.

The test for a page transition is not whether anyone compliments it. Nobody will. It is whether taking it out makes the site feel abruptly cheaper — and it does, which is the only evidence I have that it was doing anything.

What is taste, once you take the mystery out of it? A few years in, most of what I thought was taste turned out to be a handful of rules I now apply without thinking. They are unglamorous. They are also the difference between an interface that feels considered and one that feels assembled.

These are the ones I reach for first. The motion ones you can play with.

Ease everything out

Nothing you have ever touched moves at a constant speed. Things build momentum and shed it. Linear motion reads as mechanical for exactly that reason — it is the one curve with no physical referent.

Decelerating into the destination is the cheapest change you can make to an interface. One curve covers almost everything: cubic-bezier(0.2, 0, 0, 1). Fast at the start, slow at the finish, arrives without a bump.

Save easing into a motion for things leaving the screen. Something on its way out has no destination worth landing on.

The trade is small: you give up a motion that looks perfectly even, and you get one that looks like it has weight.

Make it shorter than you think

An animation is a delay you have chosen to impose. That framing kills most of the long ones.

Small things moving short distances want 150–200ms. Larger surfaces can take 300ms. Past that you are asking the reader to wait so you can show them a transition, which is a bad trade the second time they see it.

The test is whether it still feels good on the fiftieth use, not the first.

Answer immediately, settle gently

Feedback to a press should be instant. Not 100ms — instant, on the frame the finger lands. Any delay between touching a thing and it acknowledging you reads as the interface thinking, and a thinking interface feels slow no matter how fast it actually is.

Coming back can take its time. Down at 0ms, up over 160ms. That asymmetry is most of what makes a control feel physical, and it costs one line of CSS.

Nine smaller rules do the rest

• Optical alignment beats mathematical alignment. A triangle centred by its bounding box looks off-centre, because the eye measures mass, not boxes. Nudge it and trust your eye over the number.
• Line length wants 45 to 75 characters. Wider and the eye loses the return; narrower and it never gets going.
• Hit areas want 44px even when the thing you can see is 16px. Pad the target, not the icon.
• Never remove a focus ring without replacing it. Keyboard users are navigating your interface blindfolded if you do.
• Honour prefers-reduced-motion. For some people the animation you are proud of is a headache.
• Two greys and a black go further than a palette. Colour is the loudest tool you have and most interfaces spend it on decoration rather than meaning.
• Give hierarchy through colour and position before you reach for size and weight. Once everything is shouting, nothing is.
• Write button labels as the action they perform. "Save changes" over "OK" — a person skimming a dialog reads the button first and the sentence second.
• Empty states are a design surface, not an oversight. It is the first thing a new user sees and the one screen you can guarantee they will hit.

None of these will be noticed when they are there. Every one of them is noticed when it is missing.