- Scene
- 18
- Take
- 01
- Level
- Advanced
- Runtime
- ~2 h
Motion Systems in Production
Turn one-off animations into a system: motion tokens, a design-system spec, the right tool for the job, tests that run animations, and field monitoring.
Until now each phase added one animation to the Lumen site. This phase is about what happens after: the next person who edits the toast, the second team that builds the gallery, the library update that arrives on a Friday. You turn a pile of animations into a system that stays the same when many people touch it.
You name motion by purpose with tokens that CSS and JavaScript share, write the spec and review checklist that keeps two teams on one scale, and choose tools by measured cost. Then you test motion for real: fake timers, seeking in a real browser, reduced motion in Playwright, a snapshot and a leak check. Finally you watch it in production with INP, Long Animation Frames, a budget and a flag.
Everything here was run for real in a scratch copy of the Lumen project (Vitest 5.0.5, Playwright 1.63.0, web-vitals 6.2.3, esbuild 0.28.2, Node 24), and the numbers are the ones we got.
Scene 18 · the brief from Lumen
Kofi, frontend engineer at Lumen Bikes
“Everything moves now. I need it to keep moving the same way when someone else edits it, and I need to find out when it breaks before a customer does.”
Ten days before launch, Tomás asks for a second page for the partner shops, built by two contractors. Kofi reads their first pull request and finds a 180 ms toast beside a 350 ms drawer, a curve nobody chose, and no reduced-motion rule. Nothing is wrong, exactly. It is just not Lumen any more.
Lena has a different worry. Her one animation test waits 300 ms and fails every fourth run on the build machine, so the team has started to ignore it. Mei wants a written spec, so her storyboards survive contact with other people's code. And Tomás asks the question nobody can answer yet: if an update makes the site slower on cheap phones, how would we know?
In this phase Kofi gives the site tokens, a spec, tests that jump to a moment instead of waiting, and numbers from real visitors. By the end the launch site can be changed by someone who was not in the room, and it tells you when it got worse.
In this scene
You will learn
- Name motion by purpose and read the same tokens in CSS and JavaScript
- Write a motion spec and a review checklist, and choose a tool by what it costs
- Test animations by seeking them (Vitest, Playwright), including reduced motion
- Measure motion from real visitors with INP and Long Animation Frames, and set a budget
You write code in
In your lumen-motion project (npm run dev) and in the editor on this page
Files you touch
- src/styles/tokens.css
- src/js/motion/tokens.js
- tests/motion.test.js
- tests/launch.spec.js
- vitest.config.js
- playwright.config.js
- package.json
Shot list · 6 shots, widths by reading time
- 18.1Motion TokensA motion token is a named value (a duration, an easing or a spring) that components use instead of typing the number. Change it once and every component follows; name it by purpose (enter, exit, emphasis) and nobody has to remember numbers. 23 min 3 live
- 18.2Motion in a Design SystemA 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. 17 min 1 live
- 18.3Choosing a Tool and Its CostCSS, the Web Animations API, GSAP, Motion, React Spring, Lottie, Rive and canvas each do some jobs best. Choose by what you need to control, then check the cost: bytes over the network, who runs the animation, and what the page does when the tool fails to load. 20 min 2 live
- 18.4Testing AnimationsTest what the motion does, not how long it takes: the end state, the reduced-motion version, what happens on an interruption, and that nothing keeps running. Seek an animation to a time instead of waiting, run timer logic under fake timers, and use a real browser for what a simulated DOM cannot animate. 23 min 3 live
- 18.5Monitoring Motion in ProductionLab tests show that motion works on your machine; field data shows it works for your visitors. Measure Interaction to Next Paint and Long Animation Frames from real users with
web-vitals, set a motion budget, put heavy effects behind a flag, and make a regression after a library update show up as a failed number. 20 min 2 live - 18.6Build: The Tokens File and the Test SuitebuildFinish
tokens.csswith purpose and spring tokens and a JavaScript mirror, then add a Vitest suite (fake timers) and a Playwright suite (seeking, reduced motion, a token change, a snapshot) that check the toast, the drawer and reduced motion. The real output of both runs is below. 24 min 1 live
Dailies · 4 checked exercises
A film crew watches the day's shots every evening. Build each one yourself and press Check: the page freezes its clock and checks your motion at exact moments, its cost, and its reduced-motion version.
220ms ease-out typed into it. Add the purpose tokens --motion-enter-duration and --motion-enter-ease, pointing at the primitives --dur-base and --ease-out, and make the toast use them.IntermediateD02Seek an animation to a timeWrite opacityAt(animation, ms): it jumps the animation to ms and returns the box's opacity as a number.IntermediateD03A calm version for reduced motionThe filters panel slides down 20 px while it fades in. Add a rule so that for a visitor who asked for reduced motion it only fades.IntermediateD04A budget gateWrite checkBudget(measured, budget). It returns a list of strings, one per problem, in the budget's key order: inp 260 > 200 for a number over its limit and inp missing for a metric that was not measured.Advanced