Specifying Motion: How PMs Brief Animation Without Killing the Craft

Specify motion by intent, not implementation: name the purpose (feedback, orientation, continuity, or delight), set the constraints (performance budget, prefers-reduced-motion support), and let designers and engineers own easing curves and exact timing. This keeps specs useful without turning a PRD into an animation tutorial you're not qualified to write.

Quick answer: Brief motion by function and constraint, never by frame-by-frame timing. Name what the animation must accomplish for the user, set a performance ceiling, and require a reduced-motion fallback — then get out of the craft's way.

Motion is one of the last places PMs still over-specify out of anxiety. You've seen a spec that says "fade in over 300ms with ease-in-out" and wondered whether that number came from a design system or a guess. Usually it's a guess. And it's a guess that outlives its usefulness the moment a designer discovers the same transition needs 220ms on a slower device or a completely different curve to feel right next to a new component.

The fix isn't to stop specifying motion. It's to specify the right layer of it — the layer a PM is actually qualified to own.

Why PMs Should Brief Motion by Purpose, Not by Milliseconds

PMs should specify the job an animation does — signal success, show where content came from, connect two states, or add polish — and leave timing curves to designers and motion engineers who have the tools and training to tune them. Purpose is durable across redesigns; a millisecond value isn't.

This isn't about staying out of the weeds for politeness. It's about where expertise actually lives. A PM specifying cubic-bezier(0.4, 0.0, 0.2, 1) is guessing at a craft skill the same way an engineer specifying pixel-perfect copy would be guessing at yours.

Google's Material Design motion guidelines and Apple's Human Interface Guidelines both treat timing curves as a system-level decision, not a per-feature one — set once by a design system team and inherited everywhere. That's the model worth copying in your specs.

What Happens When PMs Over-Specify Timing

Over-specified motion specs create a maintenance trap: every redesign, every new device class, and every accessibility fix requires re-litigating a number the PM picked without design-system context in the first place.

• Inconsistency creeps in. Feature A's PM specs 250ms, Feature B's PM specs 400ms for a visually identical transition.
• Design systems get bypassed. A hardcoded value in a ticket overrides the token the design system already defined.
• Rework balloons. Engineers implement the literal number, then designers ask for a change anyway once they see it live.
• Accessibility gets forgotten. A spec obsessed with exact easing rarely remembers to ask about prefers-reduced-motion.

The alternative is a briefing habit borrowed from how good specs already handle visual design: PMs don't specify hex codes either — they point to the design tokens that already encode color, spacing, and now, increasingly, motion.

A Taxonomy of UI Motion Purposes to Brief Against

Every UI animation exists to serve one of four functions — feedback, orientation, continuity, or delight — and naming which one you need tells the team everything they need to design the right motion, without you touching a timing curve.

Nielsen Norval Group's research on animation in UX repeatedly points back to this same idea: motion that lacks a clear communicative purpose reads as noise, and motion tied to a purpose reads as information. Brief the purpose, and the craft follows.

Feedback Motion: Confirming an Action Happened

Feedback motion tells the user their input was received — a button that depresses, a checkbox that checks, a toast that slides in. Brief the event and the valence (success, error, neutral), not the animation curve.

For example: "On successful save, briefly acknowledge the action so the user doesn't wonder if it worked." That's a complete brief. It tells the designer the trigger (save success) and the job (reassure), and leaves how — a checkmark morph, a subtle scale-bounce, a color flash — to them.

Orientation Motion: Showing Spatial Relationships

Orientation motion answers "where did I come from and where am I now?" — a modal that scales up from the button that opened it, a back-navigation slide that reverses the forward slide. Brief the spatial logic, not the physics.

A useful brief names the relationship: "Opening a stakeholder detail should feel like it came from the card the user tapped, and closing should reverse that path." This is exactly the kind of spatial reasoning that also matters in customer journey mapping — orientation motion is journey mapping compressed into 200 milliseconds.

Continuity Motion: Connecting Before and After States

Continuity motion — often called a shared element transition — visually threads one element through a state change so users don't lose track of what they were looking at. Brief which element is the anchor.

• Name the persisting element (a thumbnail, a title, an avatar).
• Name the before and after states it must bridge.
• Leave the interpolation method (morph, cross-fade, position tween) to the implementer.

Delight Motion: Adding Personality Sparingly

Delight motion is the only category where tone matters more than function — a confetti burst on a milestone, a playful empty-state illustration. Brief the emotional register and, critically, the frequency ceiling, since delight motion overused stops feeling delightful.

Delight animations should be specified with a budget: how often the user should see it before it becomes noise, not just what it looks like the first time.

How to Brief Performance and Accessibility Constraints Instead of Timing

The two constraints a PM should always specify are a performance budget (frame-rate and jank tolerance) and reduced-motion support — these are measurable, testable requirements that belong in a spec, unlike a designer's timing craft.

Performance and accessibility are where PMs have real, defensible authority. Unlike easing curves, these are things a PM can hold a team accountable to in QA.

Setting a Performance Budget for Animation

A performance budget states what "smooth" means in testable terms — typically 60fps on the target device tier, with a defined tolerance for dropped frames on lower-end hardware. Google's web.dev performance guidance treats jank above roughly 1-in-6 dropped frames as user-perceptible, which is a reasonable line to put in a spec.

Requiring prefers-reduced-motion Support

Every animation spec should require that the experience degrade gracefully when a user's OS signals prefers-reduced-motion: reduce — this is a W3C-documented accessibility media query, and treating it as optional excludes users with vestibular disorders for whom motion can trigger real physical discomfort.

The Web Content Accessibility Guidelines (WCAG) address animation triggered by interaction directly, and the reduced-motion media query has been a standard CSS feature for years — there's no excuse for a modern spec to skip it.

1. State the requirement once, at the design-system level, not per-feature: "All motion must respect prefers-reduced-motion."
2. Define the fallback pattern: cross-fade instead of slide, instant state-change instead of scale animation — a decision designers can standardize once.
3. Include it in your acceptance criteria and QA checklist, the same way you'd include a responsive-breakpoint requirement — see how breakpoint ownership gets specced for the same pattern applied to layout.

Writing the Motion Brief: A Template PMs Can Actually Use

A motion brief needs four fields — purpose, trigger, constraint, and fallback — and nothing else; anything more specific than that is design craft dressed up as a requirement.

Here's a template that works inside almost any spec format:

Motion requirement: [component/interaction name]
Purpose: [feedback | orientation | continuity | delight]
Trigger: [what user action or system event initiates it]
Constraint: [performance budget + reduced-motion fallback]
Non-goal: [explicitly note timing/easing is a design decision]

Applied to a real example — a card that expands into a detail view:

• Purpose: continuity (the card must visually persist into the detail header)
• Trigger: user taps the card
• Constraint: maintain 60fps on primary device tier; reduced-motion users get an instant state swap with a cross-fade
• Non-goal: exact transition duration and easing curve are a design decision, not specified here

This is deliberately shorter than most PMs expect a "complete" spec to be. That's the point — precision here means precision about the right thing, not exhaustive coverage of everything.

Where This Fits Inside a Larger Design System Spec

Motion specs shouldn't live in isolation — they belong next to the same system that governs your design tokens and component library, because a one-off motion spec per feature is how inconsistency creeps back in.

If your team already runs a design system, motion timing values should be tokens too — motion.duration.short, motion.easing.standard — set once, referenced everywhere, changed centrally. Your job as a PM is to make sure that token layer exists and gets used, not to invent the values yourself.

This is also a natural product trio decision point: the PM names the purpose and constraint, design owns the craft, engineering flags feasibility against the performance budget — three roles, one shared artifact, nobody guessing at someone else's expertise.

Bringing This Into Spec Studio

A spec's design and UX sections are exactly where a purpose-and-constraint motion brief belongs — not buried in a comment thread, not skipped entirely. Prodinja's Spec Studio is built as a living PRD, and its design/UX sections give a PM room to capture the purpose and constraints of an animation requirement without turning the document into a tutorial on easing curves.

That's the honest scope of what a spec should do here: hold the "why" — feedback, orientation, continuity, or delight — plus the performance and reduced-motion constraints, then hand off to the people who do the timing craft. Spec Studio's readiness gates and hand-off structure are designed to keep that division of labor visible in the document itself, rather than relying on tribal memory of who owns what.

Key Takeaways

• Brief motion by purpose — feedback, orientation, continuity, or delight — not by exact timing or easing curves.
• Use the four-part taxonomy (feedback, orientation, continuity, delight) to name what an animation needs to communicate before anyone opens a design tool.
• Performance budgets (target fps, device tier, complexity ceiling) are PM-owned, testable requirements — put them in the spec.
• prefers-reduced-motion support is non-negotiable and belongs in acceptance criteria, not as an afterthought.
• Motion values belong in your design token system, alongside color and spacing, so they're set once and inherited everywhere.
• A good motion brief is short: purpose, trigger, constraint, fallback, and an explicit non-goal for timing and easing.