{"course":{"slug":"motion-and-audio","title":"Motion, Sound and Music","url":"https://addaly.com/learn/motion-and-audio","level":"intermediate","track":"create"},"lesson":{"slug":"motion-as-feedback","title":"The three jobs an animation can do","url":"https://addaly.com/learn/motion-and-audio/motion-as-feedback","position":10,"of":72,"minutes":9,"answer":"Interface motion earns its place only by answering what just happened, where a thing came from, or whether the system is alive.","keyIdea":"Interface motion earns its place only by answering what just happened, where a thing came from, or whether the system is alive, and the causal reading depends on the movement starting within roughly a tenth of a second of the action that caused it."},"body":{"format":"markdown","text":"## Motion in an interface is not decoration\n\nAn animation on a screen is doing one of three jobs, and if it is doing none of them it is costing time and giving nothing back.\n\n1. **It says what just happened.** A row slides out and the rows below close the gap: deleted. The same row vanishing instantly could have been deleted, filtered, or a rendering bug.\n2. **It says where a thing came from.** A panel that grows out of the button you pressed is understood as belonging to that button. The same panel fading in at the centre of the screen is a new, unexplained object.\n3. **It says the system is alive.** Something moving is the cheapest possible evidence that your tap was received, and it buys the server a few hundred milliseconds of goodwill.\n\nEverything else (the logo that spins on load, the card that wobbles on hover) is being paid for out of the user's attention with no return.\n\n## The numbers that make this concrete\n\nThree thresholds have survived four decades of testing and are worth memorising.\n\n- **Around 100ms.** Below this, a response feels instantaneous: the result feels caused by your own action rather than reported to you afterwards.\n- **Around 1 second.** The limit for uninterrupted thought. Up to a second, attention stays on the task; past it, people notice they are waiting.\n- **Around 10 seconds.** The limit for keeping attention on a dialogue at all. Past this, people switch to something else and come back.\n\nThese come from Jakob Nielsen's 1993 summary of much older human-factors work, and they are about human perception rather than about any particular device, which is why they have not moved.\n\nThere is a fourth number worth knowing: the **Doherty threshold**, from an IBM study in 1982. When a system responded in under 400ms, operators did not just work faster: they entered a different working state, kept going, and productivity rose out of proportion to the time saved. This is the honest argument for keeping interface motion short: past roughly 400ms of total response, you have pushed the user out of a flow state to show them an animation.\n\n## The trap: animation time is added to waiting time\n\nMost people building interfaces think of an animation as filling time that was already being spent. It usually is not.\n\nIf a modal opens in 300ms and the data inside it arrives in 200ms, the user waited 300ms, not 200ms. Your animation was the slow part. The fix is not a faster animation; it is starting the network request when the button is pressed rather than when the animation finishes, and letting the content arrive during the transition.\n\nTest this the honest way: record your screen at 60fps, then step through the recording frame by frame and count from the frame where your finger touches to the frame where the content is readable. Most interfaces come in 200 to 400ms slower than their developers believe. On a phone, a 240fps slow-motion video of a real device is better still, because it includes the touch latency the simulator hides.\n\n## Causality is the thing you are actually buying\n\nThere is a well-documented perceptual effect behind all of this. When object A moves, stops next to B, and B immediately moves off, people do not see two events: they see A cause B to move. This is Michotte's launching effect, and it holds only within a tight timing window. Insert a gap of more than roughly 100 to 150ms between the two movements and the impression of causation collapses into two unrelated events.\n\nThat is the whole mechanism behind \"the panel should come from the button\". If the panel's growth starts within about a tenth of a second of the press and starts from the button's position, the two are perceived as one causal event. Delay it or move its origin and the user has to reason about the connection instead of seeing it.\n\n## What to do when you have nothing to animate\n\nSometimes the honest answer is no motion.\n\n- **A state change with no spatial relationship** (a toggle flipping a setting somewhere else) is better served by a cross-fade or by updating, not by sliding something across the screen to imply a journey that did not happen.\n- **A destructive action** wants a pause, not a flourish. Motion that reads as smooth and pleasant on a delete confirmation is working against you.\n- **Data that changes because of somebody else** (a live figure updating) deserves a small, non-competing highlight, not the same treatment as the user's own action.\n\n## The free path\n\nEvery idea here is free to practise.\n\n- **The browser's own DevTools** show you frame timing, with no plugin and no licence. Chrome and Firefox both let you slow animations down and inspect the easing curve applied to a running element.\n- **Penpot** and **Figma's** free tier both do enough prototyping to test whether a transition reads. **Penpot** is open source and self-hostable if you need that.\n- **Motion** (formerly Framer Motion) and **GSAP** are both usable free for most work, and plain CSS transitions cover the majority of interface motion without any library at all.\n\n## The limitation\n\nMotion cannot fix a structure that does not make sense. If people cannot find the settings page, animating the drawer that contains it changes nothing: you have made a confusing journey smoother, and smoothness is not the same as comprehension. Motion is very good at explaining a relationship that exists in your model, and very bad at inventing one that does not. When a transition is hard to design, that is usually the interface telling you the two states are not actually related."},"check":{"question":"A modal takes 300ms to animate open, and the data inside it arrives from the server 200ms after the button is pressed. The team argues about whether to shorten the animation. What is the actual situation?","options":[{"text":"The animation is free because the network request is already running at the same moment, so the user is only ever waiting the 200ms the server takes and shortening the transition would gain nobody anything at all.","correct":false,"tempting":"Assumes overlapping work means the shorter of the two is the wait; the user cannot read the content until the slower of the two finishes."},{"text":"The user waits 300ms, not 200ms, because the animation is the slower of the two: the fix is to start the request on press so the data arrives during the transition, not to cut the animation.","correct":true},{"text":"The user waits 500ms, because an animation and a network request cannot overlap in a browser and must run one after the other.","correct":false,"tempting":"Believes animation and network work are serialised; the network stack runs independently of the compositor."},{"text":"The wait is irrelevant because 300ms is below the Doherty threshold of 400ms, so no perceptible cost exists and the team should stop discussing it and ship whichever version looks better.","correct":false,"tempting":"Treats a threshold as a budget that can be spent freely rather than as a ceiling on the total response."}]},"prev":{"slug":"where-the-eye-is","title":"Where the eye already is","url":"https://addaly.com/learn/motion-and-audio/where-the-eye-is"},"next":{"slug":"how-long-should-it-take","title":"How long an animation should take","url":"https://addaly.com/learn/motion-and-audio/how-long-should-it-take"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The three jobs an animation can do', in Motion, Sound and Music. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/motion-and-audio/motion-as-feedback (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The three jobs an animation can do","courseTitle":"Motion, Sound and Music","module":{"index":2,"slug":"motion-that-carries-meaning","title":"Motion that carries meaning"},"answer":null,"keyIdea":"Interface motion earns its place only by answering what just happened, where a thing came from, or whether the system is alive, and the causal reading depends on the movement starting within roughly a tenth of a second of the action that caused it.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"motion-in-an-interface-is-not-decoration","runs":[{"text":"Motion in an interface is not decoration"}]},{"t":"p","runs":[{"text":"An animation on a screen is doing one of three jobs, and if it is doing none of them it is costing time and giving nothing back."}]},{"t":"ol","start":1,"items":[[{"text":"It says what just happened.","b":true},{"text":" A row slides out and the rows below close the gap: deleted. The same row vanishing instantly could have been deleted, filtered, or a rendering bug."}],[{"text":"It says where a thing came from.","b":true},{"text":" A panel that grows out of the button you pressed is understood as belonging to that button. The same panel fading in at the centre of the screen is a new, unexplained object."}],[{"text":"It says the system is alive.","b":true},{"text":" Something moving is the cheapest possible evidence that your tap was received, and it buys the server a few hundred milliseconds of goodwill."}]]},{"t":"p","runs":[{"text":"Everything else (the logo that spins on load, the card that wobbles on hover) is being paid for out of the user’s attention with no return."}]},{"t":"h2","id":"the-numbers-that-make-this-concrete","runs":[{"text":"The numbers that make this concrete"}]},{"t":"p","runs":[{"text":"Three thresholds have survived four decades of testing and are worth memorising."}]},{"t":"ul","items":[[{"text":"Around 100ms.","b":true},{"text":" Below this, a response feels instantaneous: the result feels caused by your own action rather than reported to you afterwards."}],[{"text":"Around 1 second.","b":true},{"text":" The limit for uninterrupted thought. Up to a second, attention stays on the task; past it, people notice they are waiting."}],[{"text":"Around 10 seconds.","b":true},{"text":" The limit for keeping attention on a dialogue at all. Past this, people switch to something else and come back."}]]},{"t":"p","runs":[{"text":"These come from Jakob Nielsen’s 1993 summary of much older human-factors work, and they are about human perception rather than about any particular device, which is why they have not moved."}]},{"t":"p","runs":[{"text":"There is a fourth number worth knowing: the "},{"text":"Doherty threshold","b":true},{"text":", from an IBM study in 1982. When a system responded in under 400ms, operators did not just work faster: they entered a different working state, kept going, and productivity rose out of proportion to the time saved. This is the honest argument for keeping interface motion short: past roughly 400ms of total response, you have pushed the user out of a flow state to show them an animation."}]},{"t":"h2","id":"the-trap-animation-time-is-added-to-waiting-time","runs":[{"text":"The trap: animation time is added to waiting time"}]},{"t":"p","runs":[{"text":"Most people building interfaces think of an animation as filling time that was already being spent. It usually is not."}]},{"t":"p","runs":[{"text":"If a modal opens in 300ms and the data inside it arrives in 200ms, the user waited 300ms, not 200ms. Your animation was the slow part. The fix is not a faster animation; it is starting the network request when the button is pressed rather than when the animation finishes, and letting the content arrive during the transition."}]},{"t":"p","runs":[{"text":"Test this the honest way: record your screen at 60fps, then step through the recording frame by frame and count from the frame where your finger touches to the frame where the content is readable. Most interfaces come in 200 to 400ms slower than their developers believe. On a phone, a 240fps slow-motion video of a real device is better still, because it includes the touch latency the simulator hides."}]},{"t":"h2","id":"causality-is-the-thing-you-are-actually-buying","runs":[{"text":"Causality is the thing you are actually buying"}]},{"t":"p","runs":[{"text":"There is a well-documented perceptual effect behind all of this. When object A moves, stops next to B, and B immediately moves off, people do not see two events: they see A cause B to move. This is Michotte’s launching effect, and it holds only within a tight timing window. Insert a gap of more than roughly 100 to 150ms between the two movements and the impression of causation collapses into two unrelated events."}]},{"t":"p","runs":[{"text":"That is the whole mechanism behind “the panel should come from the button”. If the panel’s growth starts within about a tenth of a second of the press and starts from the button’s position, the two are perceived as one causal event. Delay it or move its origin and the user has to reason about the connection instead of seeing it."}]},{"t":"h2","id":"what-to-do-when-you-have-nothing-to-animate","runs":[{"text":"What to do when you have nothing to animate"}]},{"t":"p","runs":[{"text":"Sometimes the honest answer is no motion."}]},{"t":"ul","items":[[{"text":"A state change with no spatial relationship","b":true},{"text":" (a toggle flipping a setting somewhere else) is better served by a cross-fade or by updating, not by sliding something across the screen to imply a journey that did not happen."}],[{"text":"A destructive action","b":true},{"text":" wants a pause, not a flourish. Motion that reads as smooth and pleasant on a delete confirmation is working against you."}],[{"text":"Data that changes because of somebody else","b":true},{"text":" (a live figure updating) deserves a small, non-competing highlight, not the same treatment as the user’s own action."}]]},{"t":"h2","id":"the-free-path","runs":[{"text":"The free path"}],"role":"free"},{"t":"p","runs":[{"text":"Every idea here is free to practise."}]},{"t":"ul","items":[[{"text":"The browser’s own DevTools","b":true},{"text":" show you frame timing, with no plugin and no licence. Chrome and Firefox both let you slow animations down and inspect the easing curve applied to a running element."}],[{"text":"Penpot","b":true},{"text":" and "},{"text":"Figma’s","b":true},{"text":" free tier both do enough prototyping to test whether a transition reads. "},{"text":"Penpot","b":true},{"text":" is open source and self-hostable if you need that."}],[{"text":"Motion","b":true},{"text":" (formerly Framer Motion) and "},{"text":"GSAP","b":true},{"text":" are both usable free for most work, and plain CSS transitions cover the majority of interface motion without any library at all."}]]},{"t":"h2","id":"the-limitation","runs":[{"text":"The limitation"}],"role":"limit"},{"t":"p","runs":[{"text":"Motion cannot fix a structure that does not make sense. If people cannot find the settings page, animating the drawer that contains it changes nothing: you have made a confusing journey smoother, and smoothness is not the same as comprehension. Motion is very good at explaining a relationship that exists in your model, and very bad at inventing one that does not. When a transition is hard to design, that is usually the interface telling you the two states are not actually related."}]}],"check":{"question":[{"text":"A modal takes 300ms to animate open, and the data inside it arrives from the server 200ms after the button is pressed. The team argues about whether to shorten the animation. What is the actual situation?"}],"options":[{"text":[{"text":"The animation is free because the network request is already running at the same moment, so the user is only ever waiting the 200ms the server takes and shortening the transition would gain nobody anything at all."}],"correct":false,"tempting":[{"text":"Assumes overlapping work means the shorter of the two is the wait; the user cannot read the content until the slower of the two finishes."}]},{"text":[{"text":"The user waits 300ms, not 200ms, because the animation is the slower of the two: the fix is to start the request on press so the data arrives during the transition, not to cut the animation."}],"correct":true,"tempting":null},{"text":[{"text":"The user waits 500ms, because an animation and a network request cannot overlap in a browser and must run one after the other."}],"correct":false,"tempting":[{"text":"Believes animation and network work are serialised; the network stack runs independently of the compositor."}]},{"text":[{"text":"The wait is irrelevant because 300ms is below the Doherty threshold of 400ms, so no perceptible cost exists and the team should stop discussing it and ship whichever version looks better."}],"correct":false,"tempting":[{"text":"Treats a threshold as a budget that can be spent freely rather than as a ceiling on the total response."}]}],"order":[3,2,0,1],"why":null},"prev":{"slug":"where-the-eye-is","title":"Where the eye already is","minutes":8},"next":{"slug":"how-long-should-it-take","title":"How long an animation should take","minutes":9}}}