In a design system, when do you use standard, decelerate and accelerate easing, and why does linear easing look mechanical for interface movement?

## What easing is A duration says how long motion takes; **easing** says how the progress is spread across that time. With **linear** easing, an element covers equal distance in every instant — it starts at full speed, moves at a constant rate and stops dead. Nothing in the physical world moves like that: objects have mass, so they speed up from rest and slow down before stopping. That is why linear motion of a panel or a card looks mechanical, and why easing curves exist. Easing curves are usually defined as **cubic Bézier curves** — a curve from start to end shaped by two control points — and stored as tokens. The Design Tokens Community Group format draft has a `cubicBezier` type for exactly this: an array of four numbers, the two control points' coordinates. How those numbers are authored on each platform belongs to the platform documentation; the design system's decision is which **role** each curve plays. ## The three roles | Role | Shape of the motion | Use it for | Example in a benefits application | |---|---|---|---| | **Standard** | Speeds up, then slows down | Elements moving or resizing within the screen | The “Why we ask this” section expanding in place | | **Decelerate** | Starts fast, eases into rest | Elements entering the screen | A panel of saved answers sliding in from the edge | | **Accelerate** | Starts slowly, speeds away | Elements leaving the screen for good | A dismissed notice sliding out of view | ### Why decelerate for entering An element that enters with a decelerating curve moves most in the first moments, so the interface **responds immediately** to the user's tap — then settles gently, which is easy on the eye. An element entering with an accelerating curve starts slowly, so the first moments after the tap show almost nothing: it feels laggy, as if the interface did not hear the input. ### Why accelerate for leaving An element leaving the screen permanently does not need a gentle landing, because it never lands in view. Starting slowly keeps the departure readable; speeding up gets it out of the way. Using decelerate for an exit wastes time at the end of the motion, when the element is already nearly gone. ### Why standard for moves within the screen An element that starts and ends in view — a card reordering, a section growing — both departs from rest and arrives at rest, so it needs both halves: speed up, then slow down. ## Where linear is right Linear is not wrong everywhere. It is the right choice when the motion is **not a physical movement between two resting positions**: - a spinner's continuous rotation, where any easing would make it pulse; - a progress bar that tracks real progress, where the fill should reflect the actual fraction done; - some color or opacity changes, where many teams find easing makes little visible difference. ## Emphasis and variants Many systems add an **emphasized** variant of each role — a more pronounced curve for important, attention-worthy transitions — and keep the plain version for everyday motion. A government benefits application usually needs little emphasis: calm, predictable motion suits a task people may find stressful. The emphasized curves might be reserved for one or two moments, such as confirming that an application was submitted, where drawing the eye is the point. Everything else — expanding help text, moving between questions, opening a summary panel — uses the plain roles, so motion never competes with the content people came to read. ## Encoding the roles as tokens Components should refer to a role, never to raw curve numbers: 1. Define one curve token per role (standard, decelerate, accelerate, plus any emphasized variants). 2. Components reference the role token, so every entering element across the product shares the same curve. 3. If research shows motion feels abrupt, the curve changes once and every component follows. ## Common mistakes - Using accelerate for entrances because the element is “coming in” — it makes the interface feel slow to respond. - Using the same curve for everything, so exits linger and entrances lag. - Linear motion for panels and cards, which looks mechanical. - Heavily bouncing curves in a serious service, which draw attention to the motion rather than the content.