In a design system's motion scale, why does a small nearby change get a shorter duration than a large panel crossing the screen?
answer
- the eye has to follow it
- distance and area changed
- too slow feels sluggish
- too fast reads as a jump
- a few named steps, not per-component values
basics
~20 sDuration grows with how far something moves and how much of the screen changes: a small change is understood at once, a large panel needs time for the eye to follow. Too long feels sluggish; too short reads as a jump.
solid answer
~40 sMotion exists to show a user what changed and where it went, so its duration has to match the **distance travelled and the area affected**. A checkbox tick or a small icon swap is understood almost instantly; giving it a long duration just makes the interface feel slow. A panel crossing the whole screen covers far more ground; squeezed into a very short time it reads as a jump the eye cannot track. So a design system defines a small **duration scale** — common practice is roughly 100 milliseconds for small, near changes, around 200–300 for medium ones like expanding a section, and 300–500 for large, full-screen movement — and every component picks a step from it. Frequently repeated interactions sit at the short end, because users meet them many times per task.
go deeper
Recall that durations grow with distance and size of the change, and pick the right step from the scale: short for toggles, medium for expansions, long for panels crossing the screen.
Explain why too-long motion feels sluggish and too-short motion reads as a jump, and why frequently repeated interactions sit at the short end.
Show how you would audit a product where motion delays tasks, and retune the scale centrally instead of patching component values.
Discuss how to set the scale's values with evidence, such as testing with real users at full speed, and how to govern exceptions without eroding the scale.
## What a duration is for Interface motion has a job: it shows **what changed and where it went**. When a section of a benefits application expands to show the eligibility rules, the movement tells the user that the new content came from the heading they pressed. That only works if the movement is long enough to be perceived and short enough not to delay the task. The **duration** — how long the motion takes from start to finish — is the dial that balances the two. ## Why distance and size set the duration The eye has to follow a moving element. The further it travels, and the larger the area that changes, the more time the eye needs to track it. So durations scale with the size of the change: - **Small, near changes** — a checkbox tick, a switch thumb, an icon swapping, a small fade — are understood almost at once. Long durations here only make the interface feel slow. - **Medium changes** — a section expanding, a card growing, a menu appearing next to its trigger — need a little more time to read as connected to their source. - **Large, far movement** — a side panel with the user's saved answers sliding across the screen, a full-screen view replacing another — needs the most time, or it reads as a jump. The goal is roughly **consistent perceived speed**: a small change and a large change should feel like they belong to the same interface, not like one is lazy and the other frantic. ## A typical scale, stated as practice No standard mandates specific numbers; these are common ranges, with their reasons: | Step | Typical range | Used for | Reason | |---|---|---|---| | Short | about 100 milliseconds | Toggles, small fades, icon swaps | Near the threshold where a change still reads as motion rather than a cut | | Medium | about 200–300 milliseconds | Expanding a section, a menu opening | Enough for the eye to connect content to its trigger | | Long | about 300–500 milliseconds | Panels crossing the screen, full-view changes | Large distance needs tracking time | | Extra long | above that, rarely | Deliberate, one-off emphasis | Beyond about half a second, interface motion tends to feel like waiting | Many systems also note two adjustments as practice: larger screens often use slightly longer durations because elements travel further, and very small screens slightly shorter ones. ## Frequency matters too A transition a user sees once per session can afford more time than one they trigger twenty times per task. In a benefits application, the confirmation that an answer was saved may appear after every question; it belongs at the short end even if it animates a moderately large area, because a person completing a long application should never wait on decoration. A useful review question is: **does this motion ever make the user wait before they can act?** If it does, it is too long. ## Why a scale instead of per-component values A design system stores durations as a **small, named scale** rather than letting each component choose a number: 1. **Consistency.** Movements of similar size feel the same everywhere, which makes the interface feel coherent. 2. **Fewer decisions.** A designer picks “medium” instead of debating 240 versus 260 milliseconds. 3. **One place to retune.** If research shows the product feels slow, the scale changes and every component follows. 4. **A hook for user settings.** When a user asks the platform to reduce motion, the system can adjust or replace motion centrally rather than component by component. ## Common mistakes - Using one medium duration for everything, so small toggles feel sluggish and large panels feel rushed. - Choosing durations by what looks nice in a slowed-down demo; real users see motion at full speed, many times over. - Making motion longer to seem “smooth”; smoothness comes from easing and frame rate, not from extra time. - Leaving motion on the critical path of a task, so a form cannot be used until an animation finishes. ## Checking a duration in review When a new animation comes up for review, a few questions settle most debates: - How far does the element travel, and how much of the screen changes? That picks the step. - How often will a user see it in one task? Frequent motion moves one step shorter. - Can the user act while it runs, or does it block them? Blocking motion must be short. - Does it still read clearly at full speed on a real device, not only in a slowed-down preview?
- Should an interaction the user repeats many times get a longer or shorter duration?Shorter. A transition seen twenty times per task accumulates into real waiting, and the user already knows what it means after the first few times. Repeated feedback, such as a saved-answer confirmation in a long application, belongs at the short end of the scale even when it moves a moderately large area.
- Why do some systems lengthen durations slightly on large screens?Because elements travel further on a larger screen. The same panel crossing a wide display covers more distance than on a phone, so a slightly longer duration keeps its perceived speed similar. It is a common practice with a reason, not a rule; the scale steps stay the same and only their values adjust per size class.
saying these in an interview costs you the question
- Every animation in the product should use one standard duration.
- Longer durations always make an interface feel smoother.
- A full-screen panel should move as quickly as a checkbox tick.
- Each component should pick its own duration to fit its own feel.
- Some accessibility standard requires motion to last exactly 300 milliseconds.