Motion & Feel. How things move, and why it matters more than how they look.

Warm-up: what do you already feel?

You have used thousands of animated interfaces. You already have strong opinions about motion, you just have not put words to them yet. Before reading, answer the three questions below without looking anything up. Do not worry about getting them right. The point is to notice what your gut already knows, so the rest of the guide has something to attach to.

Then do one small thing: pick up your phone, open the app you use most, and do five ordinary actions (open, scroll, go back, delete, refresh). Watch only the motion. Write down one moment that felt good and one that felt wrong. Keep that note. You will diagnose it properly by chapter 6.

Good interface motion carries information the static screen cannot: where something came from, where it went, what caused it, and whether the system heard you. If removing an animation loses no information, it was decoration.

A screen is a series of states. Between any two states, something changed. Without motion, the change is a cut: one frame shows the old state, the next frame shows the new one, and the person has to compare them to work out what happened. That comparison costs attention. With well-designed motion, the change is shown instead of implied. The eye follows the object, and the brain gets the answer for free, through the same visual system that tracks a ball thrown across a room.

This is why motion is not a garnish you add at the end. It is part of the structure. When Mike Matas designed interfaces at Apple (he worked on the original iPhone and iPad software), then at Push Pop Press and on Facebook Paper (2014), his work was admired less for being flashy than for being legible: you always knew where a photo came from because it grew out of the thumbnail you touched, and you could push it back with your finger. The motion was the explanation.

The six jobs

Almost every useful animation in software does one or more of these six jobs. Learn the list; it is the test you will apply to every motion decision for the rest of your career.

Continuity

An object keeps its identity across a change. A thumbnail grows into the full photo, so you know it is the same photo. Without continuity, the person has to re-find things after every change.

Orientation

Motion builds a mental map of where screens live. If drilling in slides content from the right, then "back" must slide it to the right again. The map is only as good as its consistency.

Causality

Motion links an action to its result, especially when they are far apart. Add to cart, and the item visibly travels to the cart icon. Delete a row, and its neighbors close the gap so you see what moved.

Feedback

The system acknowledges input instantly, before the result is ready: the button depresses, the switch slides, the field shakes. This is the job most often skipped, and the one people notice most when it is missing.

Attention

Motion is the strongest attention signal in vision; our peripheral vision is tuned to it. One moving element on a still screen will be seen. Two moving elements fight. Use it for things that truly need eyes now.

Personality

The way something moves says a lot about its character. A crisp, quick settle feels precise. A soft spring feels friendly. Personality is real, but it is the last job, never the first.

Explains versus decorates

Here is the test. Imagine the animation replaced with an instant cut. Then ask: what does the person no longer know? If the answer is "where the item went" or "that my tap registered", the motion is doing work. If the answer is "nothing, but it looked nice", it is decoration. Decoration is not always wrong: a small moment of delight on a rare event (finishing a project, the first launch) can be worth it. But decoration on a frequent path is a tax. People pay it every time, and after the tenth time it stops being charming and starts being slow.

In the wild

• iOS app launchApple, since iPhone OS
  Opening an app zooms it out of its icon; closing it shrinks back to the icon's position. On a full home screen, this tells you which icon you just left. Continuity: the window and the icon are one object.
• macOS Dock minimizeApple, Mac OS X
  The Genie effect pours a window into its Dock slot. It is theatrical, but it answers "where did my window go?" for someone who has never used a Mac. Causality across distance. Scale is a separate question (the Scale effect does the same job more quietly).
• Facebook PaperFacebook, 2014
  Stories unfolded from cards you could pull up with a finger and push back down; the transition tracked the gesture continuously. Mike Matas was one of its lead designers. When motion is driven by the finger, it becomes the interface itself.
• Google MaterialGoogle, 2014 onward
  Material made "motion provides meaning" a core principle: surfaces grow from the point of touch, and shared elements carry identity between screens. A design system can make explanatory motion the default instead of an afterthought.

Animators spent a century learning what makes movement believable, and interface designers spent a decade learning which of those lessons survive on a screen people are trying to use. Borrow both vocabularies, but keep only what serves the person, not the show.

In 1981, two of Disney's senior animators, Frank Thomas and Ollie Johnston, published The Illusion of Life. In it they set out the twelve principles the studio had worked out since the 1930s for making drawings feel alive: squash and stretch, anticipation, staging, straight ahead and pose to pose, follow through and overlapping action, slow in and slow out, arcs, secondary action, timing, exaggeration, solid drawing, and appeal. Almost every motion designer since has learned them.

But a cartoon and an interface have opposite goals. A cartoon wants you to watch. An interface wants you to finish your task and forget it was there. So the principles translate unevenly. Some carry over almost directly (slow in and slow out is just easing). Some need to shrink by a factor of ten (exaggeration). And some, like squash and stretch on a text field, would be ridiculous.

The interface's own principles

In 2017 the designer Issara Willenskomer published "Creating Usability with Motion: The UX in Motion Manifesto", which named twelve principles specific to interfaces. Where Disney's list is about believability, his is about usability: how motion helps people understand relationships, hierarchy and change. The names are worth learning because they give you precise words for things you will see every day.

Two teachers worth reading in full

Val Head's Designing Interface Animation (2016) is the most practical book on choosing motion for interfaces: purpose, timing, easing and how to talk about animation with others (including your future self). She also wrote one of the first widely read pieces on motion sensitivity, "Designing Safer Web Animation for Motion Sensitivity" (A List Apart, 2015), which shaped how the industry thinks about reduced motion. Rachel Nabors' Animation at Work (2017) is short and sharp on why animation helps cognition, and on how to make it part of a design system instead of a one-off. Both treat animation as a tool for understanding, which is the stance of this whole guide.

Animation is not the art of drawings that move but the art of movements that are drawn.Norman McLaren, animator, National Film Board of Canada

McLaren's line is about film, but it fits interfaces well. The question is never "what should this look like while it moves?" It is "what is the movement, and what does it say?" Design the movement first; the visuals ride on it.

In the wild

• Apple MusicApple, iOS
  The mini player at the bottom expands into the full player, with the album art growing from its small position. Transformation and masking: the mini player and the full player are visibly the same object.
• Mail swipe actionsApple Mail, iOS
  Swiping a message reveals colored actions under the row; a full swipe commits the action and the row leaves. Overlay: the row is a layer over its actions.
• Google CalendarGoogle, Android and iOS
  Moving between month, week and day views scales the space rather than swapping screens. Dolly and zoom: time is a space you move closer to.

Most interface transitions should last between 150 and 300 milliseconds. Go shorter for small, nearby and frequent changes; go longer, up to about 500ms, only for large, far-traveling and rare ones. When in doubt, go shorter.

Duration is the first thing people feel and the last thing they can name. Too short and the eye cannot follow: the change reads as a jump, and continuity is lost. Too long and the person notices they are waiting for your animation to finish before they can act. Between those two failures there is a fairly narrow band, and it depends on three things: how far the element travels, how big it is, and how often people see it.

Why the band is where it is

A display at 60Hz draws a frame every 16.7ms. An animation of 100ms is only six frames: enough to register that something moved, not enough to see much of the path. At 200ms you get twelve frames at 60Hz (twenty-four on a 120Hz screen), which is enough for the eye to track an object smoothly. Beyond about 400 to 500ms, a transition starts to feel like a wait. That boundary is not arbitrary: in 1982, Walter Doherty and Ahrvind Thadani at IBM reported that people's productivity rose sharply when system response time fell below about 400ms, because they stayed in a flow of work instead of drifting while waiting. The "Doherty threshold" is about system response, not animation, but the same human clock is ticking in both cases. Your animation is part of the response time.

Rule 1: distance and size

An element that travels across a full screen needs more time than one that slides 20 pixels, or it will seem to teleport. A large surface (a full-screen sheet) needs more time than a small chip, because there is more to look at and more pixels changing. Material's older guidance put mobile transitions mostly between 200 and 300ms, made desktop transitions shorter (around 150 to 200ms, because pointer movements are quick and screens are seen at arm's length), and suggested longer durations on tablets, where elements travel further. You do not need precise rules; you need the habit of asking "how far, how big?"

Distance and duration do not scale in proportion, though. Doubling the distance does not mean doubling the time; it means adding a little. A sheet that rises 300px and a sheet that rises 700px might be 250ms and 320ms. If you scale linearly, long moves become sluggish.

Rule 2: frequency

This rule matters more than the first. Every animation is a tax paid each time it plays. A 300ms transition on an action people do twice a day is free. The same 300ms on an action people do 200 times a day (switching tabs, opening a command palette, moving between emails) is a minute of waiting, every day, made of tiny frustrations. So the more often something happens, the shorter its animation should be, down to zero.

Keyboard-triggered actions deserve special care. Someone pressing ⌘K to open a command palette, or J to move to the next email, has already decided; they want the result, not a show. macOS Spotlight appears essentially instantly for this reason. Fast email clients built around shortcuts move between messages without slide transitions. If you animate at all, keep it to a short fade under 100ms that never blocks the next keypress.

Rule 3: never block input

An animation that ignores taps while it plays turns duration into lag. If a person taps "back" during a 300ms push, the back should happen now, reversing from wherever the animation is, not after it finishes. This is called interruptibility, and it is the main reason springs (chapter 5) became the default on modern platforms.

In the wild

• macOS SpotlightApple
  The search bar appears on the keystroke with no visible entrance animation. Keyboard-summoned tools should feel like they were already there.
• iOS navigation pushApple, UIKit
  The standard push takes a fraction of a second, and you can grab the edge mid-transition to swipe back. Medium duration for a large move, made acceptable by being interruptible.
• Material 3 duration tokensGoogle
  Material 3 publishes named duration tokens in steps from short (tens of milliseconds) to long and extra long, so designers pick a token, not a number. A small, named scale beats ad hoc values. You will build one in chapter 15.

Nothing in the physical world starts or stops instantly, so constant-speed motion looks mechanical. Use ease-out (fast start, gentle stop) for things that enter or respond, ease-in (gentle start, fast finish) for things that leave, and ease-in-out for things that move from one place to another on screen.

An easing curve maps time to progress. The horizontal axis is time, from 0 (start) to 1 (end). The vertical axis is how far along the movement is. A straight diagonal line is linear: equal progress in equal time. Any curve that bends is easing. Where the curve is steep, the object is moving fast; where it is flat, it is moving slowly. That one idea lets you read any easing curve at a glance.

In the early 2000s the designer and developer Robert Penner published a set of easing equations (quad, cubic, quint, sine, expo, back, elastic, bounce) for Flash animation. They spread into nearly every animation library since, which is why you will see names like easeOutCubic everywhere. On the web and in most design tools, easing is usually expressed as a cubic Bézier curve with two control points, written cubic-bezier(x1, y1, x2, y2). The first point shapes the start; the second shapes the end.

Why ease-out for entering

When you tap something, you want a response now. Ease-out moves the most in the first few frames: by a third of the duration, a typical ease-out curve has covered well over half the distance. So the element appears to react instantly, then slows down so the eye can land on it and read it. This also mirrors physics: a thrown or pushed object starts at speed and is slowed by friction.

Why ease-in for exiting

An element that leaves is no longer interesting. Ease-in starts slowly (so the departure is visible and the person sees where it went) and then accelerates away, like a car pulling off. Exits are also usually shorter than entrances, often by 20 to 30%. Material's older guidance, for example, used about 225ms for elements entering and about 195ms for elements leaving on mobile. The asymmetry is a feature: we care about arrivals more than departures.

Why ease-in-out for moving on screen

When an element is visible both before and after (a card moving to a new slot, a panel resizing), it should start gently, move, and land gently. Pure ease-in-out can feel a little slow to start, so many systems use an asymmetric "standard" curve that accelerates quickly and decelerates for longer. Material's long-standing standard curve, cubic-bezier(0.4, 0, 0.2, 1), is that shape.

Where linear belongs

Linear is not banned; it is specialized. Use it for things that loop or represent time: a spinning loader, a progress bar filling at a known rate, a marquee. Use it for color and opacity changes too, where there is no physical movement to ease (though a short ease-out fade looks fine as well). Avoid it for anything that travels.

In the wild

• CSS keywordsW3C
  ease is cubic-bezier(0.25, 0.1, 0.25, 1), ease-in is (0.42, 0, 1, 1), ease-out is (0, 0, 0.58, 1), ease-in-out is (0.42, 0, 0.58, 1). The built-in ease-out is gentle; many designers prefer a stronger one for snappier responses.
• Material 3Google
  Publishes named easing tokens (standard, emphasized, with accelerate and decelerate variants) and, with Material 3 Expressive (2025), a spring-based motion system. Even a system built on Bézier curves moved toward springs for interactive motion.
• LinearLinear, 2019 onward
  The issue tracker is known for crisp, quick transitions with fast starts and short settles, and for keyboard actions that do not wait on animation. Strong ease-out plus short durations reads as "fast software".

A spring has no fixed duration. It pulls an element toward a target with a force, and the motion ends when the energy runs out. That makes springs naturally interruptible: they can change target mid-flight and carry their current velocity with them, which a fixed-duration curve cannot do.

A Bézier curve is a timeline: at 40% of the time, be at 70% of the distance. That works perfectly until something interrupts it. Suppose a sheet is halfway up and moving fast when the person flicks it down. A timeline animation has two bad options: finish going up first (ignoring the person), or start a new animation downward from zero velocity, which makes the sheet stop dead and then start again. Either way, the motion has a visible kink. In the real world, a moving object you push the other way slows down, reverses and accelerates; its velocity changes smoothly.

A spring simulation models exactly that. At every frame it asks: how far am I from the target, and how fast am I moving? The spring force pulls toward the target in proportion to the distance; the damping force resists motion in proportion to the speed. Change the target, and the same simulation just keeps running from the current position and velocity. No kink.

The three knobs, and the one that matters

Stiffness (k) is the strength of the pull. Higher stiffness means faster motion. Damping (c) is friction. Higher damping means less bounce and, past a point, slower settling. Mass (m) is inertia. Higher mass makes the object slower to start and slower to stop, as if it were heavier.

Designers rarely think in those raw numbers. The useful derived quantity is the damping ratio, usually written ζ (zeta): ζ = c ÷ (2 × √(k × m)). When ζ = 1, the spring is critically damped: it reaches the target as fast as possible without overshooting. Below 1 it overshoots and oscillates; the lower, the bouncier. Above 1 it creeps in slowly. For most interface motion you want ζ between about 0.8 and 1: a hint of liveliness, or none, and no visible wobble.

Apple's designers, in the WWDC 2018 talk "Designing Fluid Interfaces", recommended thinking in two designer-friendly parameters instead of three physical ones: damping ratio (how bouncy) and response (roughly how quickly it gets there). SwiftUI follows the same idea; since iOS 17 you can write a spring as a perceived duration and a bounce, and use presets named .smooth (no bounce), .snappy (a little) and .bouncy (more). You still get a physically correct spring, but you specify it in words a designer would use.

Duration-based or spring?

Use a spring when the motion is connected to a gesture, can be interrupted, or is triggered by something the person might immediately reverse (open and close, expand and collapse). Use a duration and curve when the motion is short, not interactive and needs to be exactly synchronized with something else, like a crossfade that must end at a specific time, or a loading progress indicator. Most modern platforms default to springs for interactive transitions; SwiftUI's default animation became a spring in iOS 17.

On the web, CSS transitions are timeline-based, but you can fake a spring with the linear() easing function, which accepts many points and can approximate any curve (including a spring's settle). It is still a timeline, so it will not preserve velocity when interrupted. For real interruptible springs on the web, use a library such as Motion (chapter 14) or a small simulation like the one in the lab above, which is about 30 lines of JavaScript.

In the wild

• Facebook Pop and OrigamiFacebook, 2014
  Built alongside Paper, Pop was an open-source animation engine with springs and decay, and Origami was the prototyping tool its designers used to tune them. Springs went mainstream in app design partly because designers had tools to feel them before engineering them.
• iOS sheets and app switcherApple, iOS
  Sheets, the app switcher and home gesture track your finger and hand off to springs on release, carrying your flick's velocity. The gesture and the animation are one continuous motion.
• SwiftUI springsApple, iOS 17 and later
  Spring presets .smooth, .snappy and .bouncy, and springs defined by duration and bounce. The platform made the designer-friendly vocabulary the default API.

When a person drags something, it must stay under their finger, exactly, every frame. At the edges, it should resist rather than stop. When they let go, it should keep the speed they gave it. Those three rules (1:1 tracking, rubber-banding, momentum) are what make a touch interface feel like a physical object instead of a picture of one.

Ben Shneiderman coined "direct manipulation" in 1983 to describe interfaces where you act on visible objects with continuous, reversible actions and see the results immediately. Touch screens made the idea literal. And the moment the finger is on the glass, the bar for motion rises. With a mouse, a few milliseconds of lag hide in the gap between hand and pointer. With a finger, any lag is visible as the content sliding away from your fingertip, and the illusion breaks.

Rule 1: track 1:1, with no smoothing

During a drag, set the element's position from the pointer position directly. Do not ease toward it, do not animate to it, do not smooth it. Smoothing is tempting because it hides jittery input, but it turns into lag: the content trails the finger like it is on a rubber leash. Also preserve the grab point: if the person grabbed the card 30px from its left edge, it should stay 30px from its left edge under the finger, rather than jumping to center itself.

Rule 2: resist at the edges (rubber-banding)

What should happen when you drag a list past its end? A hard stop feels broken: your finger keeps moving and the content refuses, so you wonder whether the app froze. The iPhone answer, credited to Apple designer Bas Ording and central to one of the patents in Apple's 2012 case against Samsung, is rubber-banding: the content keeps moving, but with increasing resistance, so it travels a fraction of your finger's distance and the fraction shrinks the further you pull. Let go, and it springs back. You learn the boundary physically, without an error message.

A widely shared approximation of the iOS curve, reverse-engineered by developers, is offset = (1 − 1 ÷ (distance × 0.55 ÷ size + 1)) × size, where size is the height of the view. It starts close to 1:1 for small pulls and flattens toward a limit for big ones. The exact constant matters less than the shape.

Rule 3: keep the momentum, and project it

When the finger lifts, the content is moving at some speed. Throwing that speed away (stopping dead) feels like the content hit glue. Keeping it means letting the content glide and decelerate by friction. iOS scroll views decelerate by multiplying velocity by a constant every millisecond (0.998 at the normal rate, 0.99 at the "fast" rate used for paging-like views).

Apple's fluid interfaces talk added a subtle, powerful idea: projection. When someone flicks a sheet or a picture-in-picture video, do not choose where it lands from where the finger let go. Choose it from where the motion would come to rest, given the release velocity. A gentle flick near the middle should go back; a fast flick from the same position should carry through. This is how the iOS app switcher and PiP window feel like they read your intent.

In the wild

• iPhone scrollingApple, 2007
  From the first iPhone, lists tracked the finger, carried momentum and bounced at the ends. It was one of the moments in the original keynote that made the device feel physical. Feel can be the product's first impression.
• Picture in PictureApple, iOS 14 and later
  Flick a PiP video toward a corner and it lands in the corner your throw was heading to, not the nearest one to your finger. Projection reads intent from velocity.
• MapsApple Maps, Google Maps
  Pan, pinch and rotate all track 1:1, glide on release, and resist at zoom limits. Rubber-banding works for any bounded value, including zoom level.

When several things move, they need a director. Decide where every screen lives in space, move things in an order that tells one story, and offset related items by a few tens of milliseconds so the eye can follow them as a group without waiting for them.

A spatial model: where screens live

Every navigation animation makes a claim about space. A push from the right says "the new screen was to the right, and you moved deeper". A sheet from the bottom says "this is a temporary layer on top; dismiss it downward". A crossfade says "this replaced that, in the same place". People build a mental map from these claims, and they use it to predict where "back" goes. The map only works if your claims are consistent.

The z-axis deserves a note. A layer above (sheet, popover, dialog) should come from where it is anchored and cast a shadow or dim what is behind, so you know the base is still there underneath (Willenskomer's "obscuration"). It leaves the way it came. If a sheet slides up, it slides down; a sheet that fades out after sliding in breaks the model.

Sequence: one story at a time

When a change involves several elements, order them by cause and effect. The thing the person touched responds first. The thing that results comes next. Supporting elements (counts, badges, secondary content) follow. If everything starts at once, the eye does not know where to look; if the order is wrong, causality reads backwards. Keep the whole sequence short: a choreographed transition that takes longer than about 400 to 500ms in total is usually showing off.

Stagger: related, but separate

When a group of similar items appears (list rows, grid cards, menu items), animating them all together makes the group read as one blob. Animating them one fully after another makes the person wait. Staggering each item's start by a small offset, usually 20 to 50ms, gives the best of both: the eye perceives a wave that reveals the order and grouping, and the whole group is visible within a quarter of a second. Cap the number of staggered items (the first six to ten); anything below the fold should simply appear with the last one, or the stagger becomes a slow drip.

Shared elements

The strongest continuity tool is the shared element transition: an element present on both screens (a photo, a title, an avatar) moves and resizes from its old position to its new one, while the rest of the screen changes around it. The person's eye stays on the thing they tapped, and the new screen assembles around it. Photos opening from a grid, an album cover growing into a player, a card expanding into a detail page: all shared-element transitions. Material calls this the "container transform". On the web, the View Transitions API makes it a few lines of code (chapter 14).

In the wild

• iOS PhotosApple
  Tapping a thumbnail grows it into the full photo; swiping down shrinks it back into its exact grid cell, which may have scrolled. Shared elements must land back where they came from, even if that place moved.
• Material container transformGoogle
  A card or button expands into the full screen it opens, keeping its edges continuous. A container can become the page.
• Things 3Cultured Code, 2017
  A to-do expands in place into an editable card, pushing neighbors aside, rather than navigating to a new screen. Sometimes the best spatial claim is "it opens right here".

When content reflows (an item is removed, a list is filtered, a card resizes), animate each element from its old position to its new one. The FLIP technique makes this cheap: measure where things were, measure where they are, and animate the difference with transforms.

Most interface changes are not navigation; they are layout changes within one screen. A row is deleted and the rows below jump up. A filter hides half a grid and the rest snap into new places. A panel opens and the content beside it jumps sideways. Each jump breaks continuity: the person has to find their place again. Animating the reflow fixes that, but it used to be hard, because layout positions are computed by the browser or UI framework, not by you.

FLIP: First, Last, Invert, Play

In 2015, Paul Lewis (then at Google) described a technique he called FLIP. It turns any layout change into a smooth animation using only transforms, which are cheap to animate (chapter 14).

// FLIP for any set of elements (vanilla JS, Web Animations API)
const first = new Map([...items].map(el => [el, el.getBoundingClientRect()]));
applyTheLayoutChange();                       // e.g. reorder, filter, remove
for (const el of items) {
  const a = first.get(el), b = el.getBoundingClientRect();
  const dx = a.left - b.left, dy = a.top - b.top;
  if (!dx && !dy) continue;
  el.animate(
    [{ transform: `translate(${dx}px, ${dy}px)` }, { transform: 'none' }],
    { duration: 260, easing: 'cubic-bezier(.2, 0, 0, 1)' }
  );
}

Morphing: one thing becoming another

Transformation (chapter 2) is the UX in Motion name for an element that changes into another element while staying recognizably itself. Icon morphs are the small version: a play triangle becoming a pause pair, a hamburger becoming a close cross, a "Send" button shrinking into a spinner and then a check. They work because the control stays where your eye already is and tells you its new state without a separate message. They fail when the morph is slow (anything over about 250ms for an icon), or when the two states have nothing in common visually, so the in-between frames are a mess.

In the wild

• iOS Mail deleteApple
  Deleting a message collapses its row while the rest slide up. The collapse is the confirmation.
• Trello and Linear boardsAtlassian; Linear
  Dragging a card makes the other cards in the column slide apart to make room, live, as you move. Animated reflow previews the result before you drop.
• SwiftUI matchedGeometryEffectApple, iOS 14 and later
  Marks two views as the same element so SwiftUI animates position and size between them. Platforms now treat "this is the same thing" as a first-class idea.

The smallest motions do the most work: a button that depresses on touch-down, a switch that slides, a field that shakes on a wrong entry, a check that draws itself on success. They are fast (50 to 200ms), they answer the person directly, and they are where most products feel cheap or crafted.

Dan Saffer's book Microinteractions (2013) breaks every small interaction into a trigger, rules, feedback, and loops and modes. Motion lives mostly in the feedback part: it is how the control says "got it" and "here is the new state". Because microinteractions happen hundreds of times a day, they must be fast, quiet and completely consistent. A good press state is never noticed; a missing one is noticed every time.

Press: respond on touch-down

The most important microinteraction is the press state, and the most important rule is when it appears: on touch-down (or mouse-down), not on release. The press state is the acknowledgement. It must happen within a frame or two of contact, before the action runs. A slight darkening, a scale to about 0.96 to 0.98, or both, over 50 to 100ms in, and a slightly slower release. On release, the action fires.

Toggles, checkboxes and selection

A switch should slide its knob (about 150 to 200ms, ease-out or a crisp spring) and change color with it, so the new state is unmistakable. A checkbox can draw its check quickly (a 100 to 150ms stroke animation) instead of popping in. Selection in a list (highlighting a row) should be near-instant; it is a very frequent action. None of these should bounce in productivity software. A tiny overshoot in a switch is tolerable; more is noise.

Success and errors

Success is usually best shown in place: the button becomes a check, the row gets a brief tint. Avoid modal celebrations for ordinary actions. Errors should also appear where the problem is. The classic motion for "no" is a short horizontal shake, the way a head shakes. macOS has shaken its login password field on a wrong entry for many years. A shake works because it is fast (about 300 to 400ms, three or four oscillations of a few pixels), localized, and universally understood. It must come with a text explanation for anyone who cannot see the motion or has motion turned off.

Loaders inside controls

When an action takes more than about a second, the control that started it should show that it is working: the button label replaced by a small spinner, the button kept the same width so the layout does not jump, and the button disabled to prevent double submission. When the action completes, morph to a check briefly, then return to normal. Chapter 10 covers the bigger question of what to show while whole screens load.

Attention cues, used sparingly

Sometimes you need the person to notice something: a new message, a required field, a feature they have not found. Motion is the strongest way to do it, which is exactly why it must be rationed. Rules: one cue at a time; play it once or twice, never loop forever; tie it to an event the person cares about; and stop the moment they have seen it. A badge that pulses until clicked is a nag. A badge that scales up once when it changes is information.

In the wild

• macOS loginApple
  A wrong password shakes the password field side to side. A shake is a fast, culturally obvious "no", right where the problem is.
• iOS switchesApple
  The knob slides and the track fills with color; you can also drag the knob. Even a toggle can be directly manipulated.
• Material rippleGoogle, 2014 onward
  A ripple spreads from the touch point, showing exactly where the surface was touched. Feedback can carry location, not just "pressed".
• Stripe CheckoutStripe
  The pay button shows progress in place and then a check on success, without navigating away. The control that started the action reports its result.

How fast software feels matters more than how fast it is. Respond within 100ms, show progress after about a second, keep people oriented past ten seconds, and wherever you can, do the work before or behind the moment instead of in front of it.

Three numbers have guided interface speed for decades. Robert Miller described them in 1968, and Jakob Nielsen popularized them in Usability Engineering (1993). About 0.1 second is the limit for feeling that the system reacts instantly, as if you were acting on a physical object. About 1 second is the limit for your flow of thought staying uninterrupted, though you notice the delay. About 10 seconds is the limit for keeping attention on the task at all; beyond it, people switch to something else. Doherty's 400ms (chapter 3) sits between the first two.

Optimistic UI: assume success

Most actions in most apps succeed. Likes, stars, marking as read, reordering, renaming, checking off a to-do: their failure rate is tiny. So instead of waiting for the server, update the interface immediately as if the action succeeded, send the request in the background, and only if it fails, roll back and say so clearly. The person feels zero latency. In early Instagram, Mike Krieger described a related trick: the photo upload started in the background while people were still writing the caption, so by the time they pressed share, much of the work was done.

Spinner, skeleton or progress bar?

When you must wait, pick the indicator by what you know about the wait. A spinner (indeterminate) says "working, no idea how long"; fine for short, unknown waits, but it focuses the eye on the waiting itself. A skeleton screen shows the shape of the content that is coming (grey blocks where text and images will be); the term was popularized by Luke Wroblewski around 2013. Skeletons make waits feel shorter because the page appears to be already loading in place, and because nothing jumps when content arrives. A determinate progress bar says "this much done, this much left"; use it whenever you can estimate progress and the wait exceeds a few seconds, such as uploads, exports and imports.

Two refinements matter as much as the choice. First, delay the indicator: if most loads finish in under about 300 to 500ms, showing a spinner immediately produces a flash that makes things feel slower. Start it after a short delay. Second, once an indicator appears, keep it for a minimum time (around 300 to 500ms) so it does not flicker on and off.

Do the work before the moment

The best loading state is the one that never appears. Prefetch the next likely screen. Start loading a link's page when the pointer hovers over it or a finger touches down (people usually hover for a few hundred milliseconds before clicking; tools like instant.page are built on this idea). Cache aggressively and show cached content first, then update. Do heavy work in the background and notify when done. Superhuman, the email client, made "every action within 100ms" a design principle: it keeps mail locally so most actions never wait on the network at all.

Never let the page jump

Layout shift is when content moves after it first appears because something above it loaded late: an image without dimensions, an ad, a banner, a font swap. It is the worst kind of unrequested motion, because it often moves the thing you were about to tap. Google's Core Web Vitals measure it as Cumulative Layout Shift, and treat a score of 0.1 or lower as good. The fix is not animation; it is reserving space. Give images and embeds explicit dimensions or an aspect ratio, reserve slots for late content, and use skeletons that match the real layout.

In the wild

• SuperhumanSuperhuman, late 2010s onward
  Built around speed as a feature: actions aim to complete within about 100ms, with mail stored locally so most actions do not wait for the network. Perceived speed is architecture, not animation.
• Instagram uploadsInstagram, early 2010s
  Started uploading a photo while the person was still writing the caption, so sharing felt instant. Do the work during the moment people are busy anyway.
• YouTube, LinkedIn, Facebook feeds2010s onward
  Grey content-shaped placeholders appear first and fill in as data arrives. Skeletons became the default for content feeds.
• Things 3, Apple NotesCultured Code; Apple
  Local-first: everything you do is saved on the device instantly and synced later. The fastest network request is the one the person never waits for.

Haptics and sound are motion you feel and hear. Used well, they confirm a moment the eye might miss (a snap, a success, a boundary). Used badly, they are a buzzing, beeping nuisance. Keep them rare, tied to meaningful events, consistent with what the eye sees, and always optional.

Since the iPhone 7 (2016) and its Taptic Engine, phones can produce crisp, short taps rather than the old rattling buzz. That changed haptics from an alarm into a design material. A good haptic is like a good press state: you feel a detent when a picker ticks over a value, a soft knock when a sheet snaps into place, a distinct double tap when something succeeds. The best haptics are synchronized exactly with a visual event; a tap that arrives 50ms after the snap feels wrong in the same way as a lagging drag.

The vocabulary on each platform

// SwiftUI: tick when the selection changes, success when saved
Picker("Size", selection: $size) { … }
  .sensoryFeedback(.selection, trigger: size)
Button("Save") { save() }
  .sensoryFeedback(.success, trigger: savedCount)

// Kotlin: confirm a successful action
view.performHapticFeedback(HapticFeedbackConstants.CONFIRM)

Sound: subtle, synchronized, optional

Sound is the most intrusive feedback channel: it leaves the device and reaches everyone in the room. So in most software, sound should be reserved for a few events where it truly helps (a message sent, a payment completed, a timer finished), quiet, short, and off when the device is silenced. Good UI sounds share a family: the same timbre and tone, like a typeface for the ear. A sound must be perfectly synchronized with the visual; even small offsets feel like a dubbed film. Always provide a setting to turn sounds off, and never put information only in sound.

In the wild

• iOS pickersApple
  The date and time wheels tick with a light selection haptic as each value passes the center line. A detent you can feel, like a physical dial.
• Apple PayApple
  A completed payment combines a check animation, a success haptic and a short chime. For a consequential success, all three channels agree, once.
• Long press menusiOS and Android
  A haptic marks the moment a long press becomes a menu or a drag. Haptics mark mode changes the finger cannot see.

"Feel" is what happens when timing, easing, physics, feedback and gesture all agree. You cannot add it at the end; it comes from one idea about how the product should behave in the hand, applied everywhere. Three small products show how.

The earlier starter guide met Loren Brichter as a teacher of focus. Here we look at his most copied idea purely as motion, alongside two other products whose reputations were built largely on feel. For each, notice the same pattern: one gesture, designed with care for every frame, that teaches itself.

Pull-to-refresh: a gesture that explains itself

1. Reuse an existing motion. Scrolling past the top already rubber-banded on iPhone. Brichter gave that overscroll a meaning instead of inventing a new gesture. Cost: it is invisible until you try it, which early users learned by accident or from friends.
2. A visible threshold that changes state mid-gesture. The arrow flips and the label changes at the trigger distance. You know what will happen before you commit, and you can cancel by pushing back up. Cost: an extra state to design and animate.
3. Hold the list open while loading. The strip stays at its height with a spinner, so the cause (your pull) stays connected to the effect (loading). Cost: content is pushed down briefly.
4. Insert new items at the top, then collapse. New content arrives where you are already looking. Later versions in other apps added a haptic at the threshold, which is the same idea in another sense.

Paper by FiftyThree: undo as a gesture in time

1. Continuous over discrete. A button press is one step; a circling gesture is a dial, so you can go back ten strokes in one motion and stop exactly where you want. Cost: it must be discovered and learned.
2. Every gesture tracks. Pinching a journal open follows your fingers the whole way and finishes with a spring on release. Nothing plays as a canned animation once the finger is involved.
3. Minimal chrome. With almost no buttons on screen, motion and gesture carry most of the interface. That only works because every motion is consistent and reversible.

Things 3's Magic Plus: create exactly where you mean

1. Preview by reflow. The list making room is chapter 8's animated reflow used as a live preview. Cost: smooth reflow on every pointer move must be fast, even with long lists.
2. Progressive depth. Beginners tap; experts drag. The same object serves both, with no settings or modes.
3. Motion matches the brand. Things' transitions are quick, soft, rarely bouncy. The calm feel of the whole app comes from many small consistent choices rather than one show-piece.

For some people, motion on screen causes dizziness, nausea, migraines or worse. Every operating system lets people ask for less. Honoring that request is not about removing all animation; it is about replacing large spatial motion with gentle alternatives, while keeping the feedback and meaning.

The vestibular system in the inner ear senses balance and movement. When the eyes report large motion that the inner ear does not feel (a screen zooming toward you, a background sliding at a different speed than the foreground, a whole page swooping sideways), people with vestibular disorders can experience real physical symptoms that last hours. Vestibular problems are not rare: one US study (Agrawal and colleagues, 2009) estimated that about a third of adults over 40 had some evidence of vestibular dysfunction. Motion sensitivity also comes with migraines, concussion recovery, some attention conditions and simply age.

In 2013, iOS 7 introduced heavy zoom transitions and a parallax home screen. Many people reported feeling sick, and Apple soon added a Reduce Motion setting. Today every major platform has an equivalent: Reduce Motion on iOS and macOS, Remove animations on Android, an animation effects switch on Windows. Browsers expose all of them through one CSS media query, prefers-reduced-motion.

Reduce, do not remove

A common mistake is to treat reduced motion as "no motion". That throws away feedback and continuity that everyone needs. The better model: identify which motion is spatial and large (the triggers) and swap it for something calmer, usually a crossfade or an instant change, while keeping small, non-spatial feedback.

Flashing: the hard limit

Separate from vestibular sensitivity, flashing content can trigger seizures in people with photosensitive epilepsy. WCAG success criterion 2.3.1 (Level A, the baseline) says content must not flash more than three times in any one-second period, unless the flash is below specific size and brightness thresholds. In practice: never flash. No strobing loaders, no rapidly blinking alerts, no full-screen color flips for celebrations. WCAG 2.2.2 also requires that anything that moves, blinks or scrolls automatically for more than five seconds alongside other content can be paused, stopped or hidden, and 2.3.3 (Level AAA) asks that motion triggered by interaction can be disabled.

How to implement it

/* Motion is opt-in: define it only when there is no preference against it */
.sheet { transition: opacity 150ms ease-out; }
@media (prefers-reduced-motion: no-preference) {
  .sheet { transition: transform 260ms cubic-bezier(.2,0,0,1),
                       opacity 200ms ease-out; }
}
/* View Transitions: swap the zoom for a fade */
@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*) { animation-duration: 0s; }
}

const rm = matchMedia('(prefers-reduced-motion: reduce)');
function open(el) {
  if (rm.matches) return el.animate({ opacity: [0, 1] }, 150);
  return el.animate({ transform: ['scale(.9)', 'none'], opacity: [0, 1] },
                    { duration: 260, easing: 'cubic-bezier(.2,0,0,1)' });
}
rm.addEventListener('change', () => { /* update running effects */ });

@Environment(\.accessibilityReduceMotion) var reduceMotion

withAnimation(reduceMotion ? .easeOut(duration: 0.15) : .snappy) {
  isOpen.toggle()
}
// and pick a transition, not just a duration
.transition(reduceMotion ? .opacity : .scale.combined(with: .opacity))

// Animator duration scale is 0 when "Remove animations" is on
val off = Settings.Global.getFloat(
  context.contentResolver,
  Settings.Global.ANIMATOR_DURATION_SCALE, 1f) == 0f
// or ValueAnimator.areAnimatorsEnabled() on API 26+

Notice the CSS pattern: motion is defined inside no-preference, so the default is calm and motion is the enhancement. That way, if you forget a case, it fails safe. This "no-motion-first" approach has been advocated by accessibility writers such as Tatiana Mac and Eric Bailey.

In the wild

• iOS Reduce MotionApple, since 2013
  Replaces zooming app transitions with dissolves and turns off parallax. iOS also offers an option to prefer cross-fade transitions in navigation. The platform's own reduced mode swaps, it does not delete.
• macOSApple
  With Reduce Motion on, switching full-screen spaces fades instead of sliding. Large lateral movement is the first thing to go.
• prefers-reduced-motionAll major browsers
  Safari shipped it first, in 2017; it is now supported across modern browsers. There is no technical excuse on the web.

Animate only transform and opacity, finish every frame within its budget (16.7ms at 60Hz, 8.3ms at 120Hz), and pick the simplest tool that does the job: CSS for state changes, the Web Animations API or a spring library for interactive motion, View Transitions for page changes, SwiftUI's built-in springs on Apple platforms, and Lottie or Rive only for illustrative animation.

Why transform and opacity

To draw a frame, a browser (and, in similar ways, a native UI framework) goes through stages: compute styles, lay out boxes, paint pixels into layers, and composite the layers onto the screen. Changing width, height, top or margin forces layout, which can ripple through the whole page, then paint, then composite, every frame. Changing transform or opacity on an element with its own layer skips straight to compositing, which the GPU handles cheaply and often off the main thread. That is the difference between a smooth sheet and a stuttering one on a mid-range phone.

The toolbox

:root {
  --dur-fast: 120ms; --dur-base: 220ms; --dur-slow: 340ms;
  --ease-enter: cubic-bezier(.2, 0, 0, 1);
  --ease-exit:  cubic-bezier(.4, 0, 1, 1);
}
.menu { opacity: 0; transform: translateY(-4px) scale(.98); pointer-events: none;
        transition: opacity var(--dur-fast) var(--ease-exit),
                    transform var(--dur-fast) var(--ease-exit); }
.menu.open { opacity: 1; transform: none; pointer-events: auto;
        transition-duration: var(--dur-base);
        transition-timing-function: var(--ease-enter); }

const anim = toast.animate(
  [{ transform: 'translateY(100%)', opacity: 0 }, { transform: 'none', opacity: 1 }],
  { duration: 220, easing: 'cubic-bezier(.2,0,0,1)', fill: 'both' }
);
await anim.finished;
// later: play the exit by reversing, interruptible at any point
anim.updatePlaybackRate(-1.25);   // exit a little faster than enter

// Same-document transition with a shared element
thumb.style.viewTransitionName = 'hero';
document.startViewTransition(() => {
  thumb.style.viewTransitionName = '';
  showDetail();                       // detail image has view-transition-name: hero
});
/* CSS: tune it */
::view-transition-group(hero) { animation-duration: 280ms;
  animation-timing-function: cubic-bezier(.2,0,0,1); }

enum Motion {
  static let snappy = Animation.snappy          // small things
  static let smooth = Animation.smooth          // large surfaces
}
Button { withAnimation(Motion.snappy) { expanded.toggle() } } label: { … }

// Shared element between two views
Image(item.image).matchedGeometryEffect(id: item.id, in: ns)

import { motion, AnimatePresence } from "motion/react";

<AnimatePresence>
  {open && (
    <motion.div
      initial={{ opacity: 0, y: 8 }}
      animate={{ opacity: 1, y: 0 }}
      exit={{ opacity: 0, y: 4, transition: { duration: 0.12 } }}
      transition={{ type: "spring", visualDuration: 0.25, bounce: 0 }}
    />
  )}
</AnimatePresence>

Profiling in ten minutes

1. Throttle. In Chrome DevTools, set CPU throttling to 4x or 6x slowdown to simulate a mid-range phone.
2. Record. Use the Performance panel, trigger the animation, stop. Look for long purple (layout) and green (paint) blocks inside the animation.
3. Show repaints. The Rendering panel's paint flashing highlights what repaints each frame. A sheet sliding should not repaint the page under it.
4. On iOS, use Instruments (the Animation Hitches template) or simply record the screen at 120fps and count stutters.
5. Fix by changing what animates, not by adding will-change everywhere. Use will-change: transform only on elements about to animate, and remove it after.

In the wild

• View TransitionsChrome 111 (2023), Safari 18 (2024)
  Same-document view transitions shipped first in Chromium, then Safari; cross-document transitions followed. Shared-element page transitions became a few lines of code on the web.
• MotionMatt Perry, 2024
  Framer Motion became an independent project named Motion, with React and vanilla JavaScript APIs. Library names change; the concepts (springs, layout animation, exit animation) do not.
• LottieAirbnb, 2017
  Renders After Effects animations exported as JSON on iOS, Android and the web. The right tool when a designer's illustration must play natively and crisply.

Motion that is not written down drifts. A small set of named tokens (durations, curves, springs) and a one-line spec per transition (trigger, what moves, from and to, timing, reduced-motion alternative) keeps your product feeling like one product, even when the only person on the team is you, months apart.

Teams write motion specs so designers and engineers agree. As a solo creator you might think you do not need them. But your future self is a different person who has forgotten why the sheet uses 260ms and the menu 180ms. Without a record, each new feature invents its own motion, and within a year the product feels like six apps. Rachel Nabors and Val Head both argue for treating motion as part of the design system rather than one-off decisions; IBM's Carbon design system, for example, documents "productive" motion (quick, efficient) and "expressive" motion (for significant moments) as two named modes.

Layer 1: tokens

Layer 2: one line per transition

For each important transition, write a single structured line. It takes a minute and saves an hour later.

Sheet open   | tap "Filter" | sheet: translateY 100% → 0, ease.enter, dur.slow
             | scrim: opacity 0 → .4, linear, dur.base, delay 0
             | interruptible: yes (spring.smooth when dragged)
             | reduced: sheet + scrim fade, dur.fast
             | haptic: none | job: orientation (layer above)

Layer 3: a motion principle in one sentence

Finally, write one sentence that describes how your product moves, and use it to settle arguments with yourself. For a calm reading app: "Motion is quick, quiet and physical: it explains changes and then gets out of the way." For a playful kids' app it might say "springy and generous". The sentence ties motion to the product's personality (chapter 1's sixth job) without letting personality outrank the other five.

In the wild

• IBM CarbonIBM
  Separates productive motion for routine tasks from expressive motion for significant moments, with token-based durations and curves. Two modes, clearly named, cover most decisions.
• Material 3Google
  Ships duration and easing tokens, and newer spring-based motion schemes, in its design kits and code libraries. Motion tokens belong in the same system as color and type.
• Apple HIG, MotionApple
  Short principles rather than numbers: purposeful motion, brief and precise feedback, optional motion, consistency with the platform. Principles plus platform defaults can be a spec.

Wrap-up

Go back to the note you wrote in the warm-up: one moment that felt good and one that felt wrong in your most-used app. You can now name what was happening. Maybe the good moment was a spring carrying your flick's velocity, and the bad one was a menu easing in, a spinner flashing for 200ms, or a list hard-stopping at its end. That shift, from "it feels off" to "the exit is as long as the entrance and uses the wrong curve", is the skill this guide set out to build.

Practice assignment for the next two weeks

About 30 minutes a day, on your own product, in code. Motion is learned by tuning, so the rule is: change a value, use the real thing ten times, then decide.

1. Days 1 and 2: inventory. Exercise 1.1 (motion inventory) and 7.1 (spatial map). Remove every decorative animation on a frequent path.
2. Days 3 and 4: tokens. Exercises 3.1 and 4.1. Create your motion file with durations and curves, and replace every magic number.
3. Day 5: feedback. Exercise 9.1. Press, busy and error states in shared components.
4. Days 6 and 7: speed. Exercise 10.1. Make your two most frequent actions optimistic, delay your loaders, kill layout shift.
5. Day 8: springs. Exercise 5.1. Replace your most-reversed transition with a spring.
6. Day 9: reflow. Exercise 8.1. FLIP your busiest list.
7. Day 10: safety. Exercise 13.1. A full day with Reduce Motion on; fix what you find.
8. Days 11 and 12: signature. Exercise 12.1. Prototype one signature interaction with tracking, threshold, release and cancel.
9. Day 13: performance. Exercise 14.1 on a throttled device.
10. Day 14: write it down. Exercise 15.1. Your spec and the audit checklist. Record a 60-second screen video of your product before and after the two weeks, and watch them side by side.

Reading and watching list

• The Illusion of Life: Disney Animation
  Frank Thomas and Ollie Johnston, 1981 · The source of the twelve principles. Read the chapter on the principles; skim the rest for the drawings.
• Designing Interface Animation
  Val Head, Rosenfeld Media, 2016 · The most practical book on purpose, timing, easing and communicating motion for interfaces.
• Animation at Work
  Rachel Nabors, A Book Apart, 2017 · Short; why animation helps cognition and how to make it part of a system.
• Microinteractions
  Dan Saffer, O'Reilly, 2013 · Triggers, rules, feedback and loops; the anatomy behind chapter 9.
• Creating Usability with Motion: The UX in Motion Manifesto
  Issara Willenskomer, 2017 · The twelve interface-specific principles, each with clear animated examples.
• Designing Fluid Interfaces
  Apple, WWDC 2018 · Interruptibility, velocity, projection, rubber-banding, spring parameters. Watch it twice.
• Animate with springs
  Apple, WWDC 2023 · How SwiftUI's springs work and how to think in duration and bounce.
• FLIP Your Animations
  Paul Lewis, 2015 · The original explanation of First, Last, Invert, Play.
• Designing Safer Web Animation for Motion Sensitivity
  Val Head, A List Apart, 2015 · What triggers vestibular symptoms and how to design around it.
• Response Times: The 3 Important Limits
  Jakob Nielsen, Nielsen Norman Group · The 0.1, 1 and 10 second limits, with their history.
• Material Design: Motion
  Google, m3.material.io · A complete, public motion system with tokens, easing, springs and transition patterns to compare against.
• Apple Human Interface Guidelines: Motion, and Playing haptics
  Apple · Short platform principles and the semantic haptic vocabulary.

Next: Words, where the feedback you designed here gets its language. For how motion fits into a full design system, see Systems & Platforms; for the wider accessibility picture, Accessible & Inclusive.