Motion in Product Design

This module changes register. Modules 1 to 3 covered video — explainers, decks, narrated sequences — where motion is the medium and more of it is often fine. Product motion is the opposite: every transition and micro-interaction sits between a person and the task they came to do, and it has to pay rent in clarity. Make that contrast explicit at the start, because the failure mode this module exists to prevent comes directly from agents trained on a web full of motion made for watching, not for using.

The organising rule is the one in this school's own DESIGN.md: motion clarifies hierarchy; no decorative or looping animation. The whole module is an expansion of that single sentence into something an agent can actually follow — durations, easings, what may move, what may never move, and the review pass that catches violations.

Set expectations on tooling too. There is no Remotion or Hyperframes in this module. Product motion lives in CSS transitions, the Web Animations API, and component libraries — the same materials agents already write when they generate UI. The skill being taught is not a new tool; it is writing rules into the harness and tokens so that the motion an agent produces belongs to your product.

These three jobs — orientation, causality, feedback — are the test that everything else in the module hangs off. They are deliberately narrow. Orientation covers motion that preserves a sense of place: a drawer sliding in from the edge it lives on, a detail view expanding from the row that opened it. Causality covers motion that connects an action to its consequence: the deleted row collapsing rather than vanishing, so the user's eye is not left searching for what changed. Feedback covers motion that acknowledges input: the pressed state, the spinner, the brief confirmation.

The fourth bullet is the controversial one and worth defending. Decorative motion is not always wrong in marketing pages or brand moments — but in product UI it competes with the user's task for attention, it accumulates across a session, and it is the single most common thing agents add uninvited. Treating decoration as guilty until a human explicitly approves it is a practical default, not an aesthetic absolutism.

A useful exercise when reviewing any animated element: ask what question the motion answers for the user. Where am I, what did I cause, did it hear me. If the honest answer is none of those, the motion is there because someone — or some agent — thought the screen looked static.

The numbers on this slide come from this school's own DESIGN.md, and they are presented as a worked example of the shape, not as universal constants. Plenty of respectable systems use 100 to 400 milliseconds with a couple more steps, or name their curves differently. What matters is the structure: a tiny set of named durations, easing tied to event type rather than preference, an explicit position on distance, an explicit default of no motion, and one hard restraint rule written as a sentence.

Spend a moment on the when to use none row, because it is the one teams skip. Most product state changes — a number updating, a filter applying, a validation message appearing — are better instant. Animating them adds latency to information the user asked for. Writing the default is no motion into the system means the agent has to find a reason to animate, instead of finding a reason not to.

The hard rule row is the bridge to the next slide. Durations and easings can live as tokens. The restraint rule — what motion is for, what is forbidden — has to live as written instruction in the harness, because no token format expresses no decorative or looping animation.

This is the tokens-as-agent-instructions pattern from earlier in the curriculum applied to motion. The token file answers what values exist: the named durations and easing curves, exposed as CSS variables the agent can read before generating UI and that a reviewer can grep for afterwards. A motion duration is just another token type alongside colour and spacing — the DTCG format and the usual build tools handle it the same way.

But tokens alone reproduce the same gap they have for colour: an agent that can see three durations still has to guess whether this dropdown should animate at all. That judgment lives in the harness — DESIGN.md or its equivalent — as short, checkable sentences: use only these tokens, motion exists for orientation, causality, and feedback, default is no motion, no decorative or looping animation, respect reduced motion. Each sentence is something a reviewer can verify and an agent can be held to.

The practical payoff is reviewability. When every legitimate duration is a named variable, raw values like 437ms or a hand-rolled cubic-bezier in component code are drift you can find mechanically — the same way a token audit finds raw hex colours. The verification script from the design-systems material extends to motion with two more patterns.

Walk the diagram left to right. The motion system on the left is the slide-three content made durable: durations, easings, what may move and why, the no-motion default, and the restraint rule. It is human-authored and lives in the design system — token files plus the harness sentences from the previous slide.

The middle column is everything downstream that the agent produces with motion in it. Product UI is the focus of this module, but the same tokens should reach prototypes and the code-defined videos from Modules 1 to 3 — a brand whose product eases at 200 milliseconds and whose explainers bounce with springs at 800 reads as two different companies. One source, several outputs, the same principle as the content-source slide in Module 3.

The review pass on the right is the gate, and its checklist is short and mechanical where it can be: every motion names its job, every duration and easing resolves to a token, decorative and looping animation is removed, reduced motion is verified, jank is checked. The dashed feedback line matters most over time: when the same correction comes up in review twice, it stops being feedback and becomes a rule — a new token, or a new sentence in the harness. That is how the system gets sharper instead of the reviewer getting tired.

This failure mode deserves its own slide because it is so consistent. Ask an agent to make a dashboard feel polished or modern and the odds are good you get staggered entrance animations, a scroll reveal or two, and at least one looping element. The reason is the training distribution: the most visible, most copied animation code on the public web comes from marketing sites, portfolio pieces, and component showcase demos — contexts where motion is the product. Working software, where restraint is the norm, is under-represented in what the model has seen celebrated.

The practical consequence is that vague quality language makes it worse. Words like polished, delightful, engaging, and dynamic in a brief are read by the agent as an invitation to animate. If the brief instead says calm, instant, and dense, and the harness says no decorative or looping animation, the same model produces far quieter output. This is the same lesson as the token modules: agents follow explicit constraints well and fill vague gaps with the centre of the web.

The last bullet — motion as polish — is the one to watch in your own behaviour too. It is tempting to accept decorative animation because it makes a demo land better. The cost shows up later, spread across every user session and every future screen the agent builds by imitating the one you approved.

Micro-interactions are where the duration tokens earn their keep, because frequency changes the maths. A 300-millisecond panel transition that a user meets a few times a session is fine; a 300-millisecond delay on every button press is a tax collected hundreds of times a day. That is why hover and press feedback sit on the fast token and stay within the element — the user already knows where their cursor is, so the motion only needs to acknowledge, not perform.

Two of these bullets are judgment calls worth defending. Loading indication is a legitimate exception to the no-looping rule when work is genuinely happening, but it is also where shimmering skeletons and decorative spinners creep in — prefer honest progress where you can measure it, and keep indeterminate states visually quiet. Errors appearing instantly is deliberate: easing in a validation message adds latency to exactly the information the user needs most urgently, and gentle motion on bad news reads as evasive.

The consistency bullet is the agent-specific one. When an agent generates components one conversation at a time, each button can end up with its own personality unless the interaction states are defined once — in the component library and the tokens — and reused. Micro-interaction consistency is a system property, not a per-screen decision, and it is one of the things the review pass should compare across screens rather than within one.

Performance is part of the motion system because a stuttering transition fails at the only job motion has. The user notices the movement — motion is attention-grabbing by design — and then the movement fails to read, so they get the cost without the clarity. The first bullet is the rule that prevents most of it: transform and opacity can be composited by the browser without recalculating layout, while animating width, height, position offsets, or margins forces layout work on every frame. This is a rule an agent can follow mechanically, and it belongs in the harness next to the duration tokens.

Layout shift is the adjacent problem: content that pops in and pushes the page around is unintentional motion, and it is often worse than anything deliberately animated. Reserving space for images, async panels, and skeletons is a motion decision even though nothing is technically animating.

The testing bullet is about honesty. Agent-generated motion is usually reviewed on a fast development machine where everything is smooth. The users who hit jank are on mid-range phones and old laptops with twenty tabs open. Throttling the CPU in browser devtools during the review pass takes seconds and catches the difference. The last bullet is a heuristic rather than a law: plenty of legitimate motion is CSS-only, and a motion that needs per-frame JavaScript in product UI is often trying to do something the no-decoration rule would have stopped anyway.

Vestibular disorders, migraine triggers, and motion sensitivity are common enough that every major operating system ships a reduce-motion setting, and the prefers-reduced-motion media query exposes it to the web. The design position this module takes is that honouring it is part of the definition of done for any motion work, not an enhancement to schedule later. Practically, reduced motion rarely means a frozen interface: orientation and feedback still need to be communicated, so the usual substitution is an instant state change or a brief opacity fade in place of movement — the information survives, the travel does not.

The risk is not evenly distributed. Small, contained micro-interactions are rarely a problem; the harm concentrates in large-scale movement — full-screen route transitions, parallax backgrounds, zooming and scaling effects, anything that moves a large fraction of the viewport. A motion system that already enforces short distances and the no-decoration rule has removed most of the high-risk motion before the media query is even consulted, which is a useful argument for the restraint rules with stakeholders who see them as purely aesthetic.

The last bullet repeats the curriculum's standing caution about claims. An agent's report saying reduced motion is supported should be backed by the specific flows where it was actually toggled and observed — in the review evidence, with the OS or emulated setting on. Precise, narrow claims; no certification language.

Walk the columns the same way as the briefing examples earlier in the curriculum: the difference between the runs is entirely in what the agent was given, and the example is a constructed but representative trace of the failure patterns from slide six meeting the rules from slides three and four — present it as that, not as a benchmark.

In the unbriefed run the agent was asked to add the detail panel and resolve flow and make it feel responsive and polished. The output is exactly the slide-six list in miniature: an invented 400-millisecond entrance with a hand-rolled curve, celebration motion on a routine action, and a list that re-animates wholesale on every update — which on a queue that refreshes often is both janky and exhausting. Nothing respected reduced motion because nothing was asked to.

The second run had the motion tokens in the project, the DESIGN.md motion section from slide four, and a brief that named the three legitimate jobs for this flow: orientation when the panel opens, causality when the ticket leaves the queue, feedback on the resolve action. The review pass still earned its place — it caught a leftover decorative fade on the empty state, which is the kind of small drift that turns into precedent if it ships. The lesson to land: the rules did the heavy lifting, and the gate caught the remainder. Neither alone is enough.

The deliverable is deliberately small: a motion section for the design harness, not a motion design language document. The constraint of one screen forces the prioritisation that makes rules followable — if everything is a rule, nothing is. Steer participants towards their actual product; the durations that suit a dense operations tool are not the ones that suit a consumer onboarding flow, and the what motion is for sentence should reflect that difference rather than copying this school's version verbatim.

The two tests in the highlight are the marking scheme. Could an agent follow it filters out taste statements with no operational content — motion should feel premium fails, ease-in-out at 200 ms for state changes passes. Could a reviewer verify it filters out rules that sound firm but cannot be checked — use motion sparingly fails, no looping animation and no animated layout properties passes, because both can be found in code or on a screen recording.

The third bullet's review checks are the bridge to Module 5: they are the seed of the QA gate that the production-pipeline module formalises. If running this live, have participants swap drafts and attempt to find one rule in someone else's draft that they could not verify — that exchange surfaces vague rules faster than self-review does.

Recap by connecting the bullets rather than re-reading them. The three jobs give you the test for whether motion belongs at all; the small system gives the agent values it cannot drift far from; the tokens-plus-harness split is the same pattern used for colour and spacing, which is exactly why it works — the team already knows how to maintain and audit it. The failure-mode slide explains why the rules are necessary rather than fussy, and the performance and reduced-motion slides define what done means before anything reaches the review pass.

If participants did the exercise, the draft motion section is a real artifact: it can go into their harness this week, and the three review checks they wrote become the starting point for Module 5's QA gates.

Preview Module 5 concretely. This module ended at one flow reviewed once. The final module is about doing motion work repeatedly at brand quality: render and delivery pipelines for recurring video formats, versioning video sources and outputs, QA gates that cover brand, factual accuracy, captions, and platform specs, and the honest assessment of where agent-produced motion still needs a specialist — craft animation, character work, and campaign-level film remain firmly on that list as of mid-2026.