Shots in this scene

← scene 17 · Creative Motion → scene 19 · Interviews and Capstone ▦ the storyboard

SHOT 18.2Advanced ~17 min · shot 2 of 6

Motion in a Design System

In one line

A design system records how motion is used so many people build one product, not many: principles, tokens, component specs, reduced-motion rules, documentation and a review checklist. How you build it matters as much as the files.

0/6 · 0%

Think of it like this

A city's road rules. Speed limits and signs look the same everywhere, so strangers behave in ways other strangers can predict. Without them every driver invents rules. A motion spec is the road rules for animation.

Words you'll meet

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

design system: The shared rules, tokens, components and documents a team uses so its product looks and behaves as one.
component spec: A few lines per component: purpose, tokens, properties, interruption, reduced-motion version, accessibility.
audit: Listing every animation that exists (component, property, duration, easing) before deciding anything.
linter: A program that reads code and reports rule breaks without running it.

Step by step

01Audit what moves

List every animation: component, property, duration, easing. The grep of Topic 18.1 starts it. Two copies of one job with different numbers are the first to merge.

Audit what movesdiagram

Rendering diagram…

02Write three principles

Lumen's: quick (feedback is over in 200 ms), calm (one thing moves at a time, big moves are rare) and kind (reduce motion, never remove the information). Each should be able to settle a review argument.

03Write the spec rows

Add a table to docs/motion-spec.md (toast, drawer, gallery, button) with purpose, tokens, properties, interruption and reduced version.

04Add the checklist and the lint

Put the five questions in your pull-request template and run a lint like the first example on your stylesheets in your tests.

Try it yourself

1
Make Team Gallery pass
In "A small motion linter" replace the lightbox rule with .lightbox { animation: zoom var(--motion-emphasis-duration) var(--motion-emphasis-ease); } and add @media (prefers-reduced-motion: reduce) { .lightbox { animation: none; } }. The report says Team Gallery: clean.
2
Add a third team
Add .menu { transition: opacity 0.2s var(--ease-out); } to the teams object as "Team Menu". The report says Team Menu: 2 problem(s): 0.2s is 200 ms, which is not on the scale, and no reduced-motion rule.

Code & diagrams

A small motion linter

Two teams' stylesheets are checked against four rules. Edit a stylesheet in the first lines of the script and run again.

Press Run to see the page.

00:00.000

animations

0.00s0.10s0.20s0.30s0.40s0.50s0.60s0.70s0.80s0.90s

Nothing is moving yet. Hover, click or scroll the page: every animation it starts shows up here as a track.

frames

Console

Nothing logged yet.

Expected console output

Team Cart: 5 problem(s)
  - transition: 180 ms is not on the scale 120/220/400
  - transition: hard-coded easing in "transform 180ms ease-out"
  - transition: 350 ms is not on the scale 120/220/400
  - transition: hard-coded easing in "width 350ms cubic-bezier(0.4, 0, 0.2, 1)"
  - transition: animates width (layout)
Team Gallery: 3 problem(s)
  - no prefers-reduced-motion rule
  - animation: 500 ms is not on the scale 120/220/400
  - animation: hard-coded easing in "zoom 0.5s ease-in-out"

Break it on purpose

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

Break #1

Split a transition on every comma

In "A small motion linter" change value.split(/,(?![^(]*\))/) to value.split(",").

terminal

$ Run the example

── what you'll see ──

Team Cart: 5 problem(s)

- transition: 180 ms is not on the scale 120/220/400

- transition: hard-coded easing in "transform 180ms ease-out"

- transition: 350 ms is not on the scale 120/220/400

- transition: hard-coded easing in "width 350ms cubic-bezier(0.4"

- transition: animates width (layout)

Myth vs fact

Myth

A motion system makes every animation look the same.

Fact

It makes the shared parts the same: durations, curves and rules. A hero or a logo can have its own choreography; the spec says where.

Pro corner

Extra depth for experienced readers. New to this? Skip it for now and come back later.

▸
The linter misses a duration set from JavaScript, a fallback that is on the scale but contradicts its token (var(--dur-base, 120ms)), and transition: all, which animates layout properties too (practice question 1 adds a rule for it). Its layout rule reads only transition lists, not the properties inside @keyframes. For serious checks use a CSS parser (PostCSS or Stylelint).

Remember this

1
The problem this solves: Lumen now has two teams. The cart team writes 180ms ease-out, the gallery team 350ms ease-in-out. Each is fine alone; together the product feels like two products, and every review becomes an argument about taste. A system answers it once, in writing, so a review asks "does it follow the spec?" instead of "do I like it?".
2
Build it in this order. Val Head's "Including Animation In Your Design System" (Smashing Magazine, February 2019) gives the process, and it still holds: talk to the people who build and design the product and look at other systems; write motion principles in plain words, before any number; set defaults (duration ranges, a few easing curves, optional named effects); call out performance and accessibility; and ship version one small: durations and easings alone are a start. An audit of the motion you already have, which she covers in her book *Designing Interface Animation*, is a good first step too. The article has no code; the tokens of Topic 18.1 are the code half.
3
What a component spec holds. Its purpose (Topic 0.1's five jobs), the tokens it uses, the properties it animates (composite ones, from the measured table of Topic 6.2), what interrupts it and what happens then, its reduced-motion version (Topic 7.2) and its focus and screen-reader behaviour (Topic 7.6). docs/motion-spec.md, started in Phase 2, holds the rows. A row is three short lines, not a page.
4
Rules a machine can check. Durations come from the scale, easings from tokens, no layout property is animated (Topic 6.2: width, height, top, left, margin, padding, font-size, border-width and text-shadow cost layout in headless Chromium 153), and a file that animates has a reduced-motion rule. The first example lints for these four. It is a regular expression: it misses some mistakes (see the pro notes), and a person reviews the rest.
5
Documentation and review. Show each token with a live demo, and put five questions in the pull-request template: what is it for, which token, which properties, what is the reduced-motion version, what happens on interruption? Changing a token changes the whole site: announce it and run the tests of Topic 18.4.

Explain it without notes

Why write principles before choosing numbers?

Which parts of a motion spec can a machine check, and which need a person?

Practice

Extend the linter with a fifth rule: report transition: all.

Write the docs/motion-spec.md row for the cart drawer.

Done when you can

You can describe the steps of building motion into a design system, in order
You can write a component spec row and a five-question review checklist
You can name which spec rules a linter can check and which need a person