Do not begin with keyframes. Begin with the decision the motion has to support. A motion brief turns a vague request such as “make this feel better” into a small, testable interaction contract before implementation starts.
Inspect Before Asking
Read the surface and its surrounding code first. Recover facts the product can already answer instead of asking the user to repeat them:
- the trigger and every visible state before, during, and after it;
- how often the interaction is likely to repeat in one session;
- the existing motion tokens, component library, and implementation stack;
- whether the action can be interrupted, reversed, or fired again quickly;
- the current reduced-motion behavior and any autoplaying or looping media nearby.
Bring questions only for decisions the product cannot answer. Ask one decision at a time. Do not ask a user to invent milliseconds, spring constants, or cubic-bezier values; propose those after the desired character and constraints are understood.
Decide Whether Motion Earns Its Time
Run the idea through two gates before choosing a technique.
- Frequency: How often will a person encounter it? Repeated task actions should be instant or nearly instant. A rare transition can afford more explanation.
- Purpose: What becomes clearer because the interface moves? Valid purposes include preserving spatial context, confirming input, explaining a relationship, or making a genuine wait easier to follow.
If the motion only decorates a completed action, cut it. Record that as the brief’s verdict so implementation does not quietly reintroduce it later.
Specify the State Change
Describe the behavior as states, not as an effect name.
- Name the trigger: press, route change, insertion, removal, validation, progress, drag, or scroll threshold.
- Name the start and end state for every moving property.
- Identify the physical origin and direction. A menu should relate to its trigger; a panel should leave toward the edge it belongs to.
- Define entry and exit separately. Exits are usually shorter, and neither direction may postpone the state change the user requested.
- State what happens when the action repeats mid-flight: retarget from the current value, reverse, finish immediately, or ignore the duplicate input.
A good brief is precise enough that two implementers would build the same behavior without requiring a frame-by-frame storyboard.
Choose the Feel After the Behavior
Capture the product character in ordinary language: direct, calm, playful, weighty, mechanical, or another concrete quality. Then propose one duration and easing family that expresses it while respecting the interaction’s frequency.
Use the product’s existing tokens when they exist. Introduce a new value only when the current scale cannot express the behavior. Prefer an ease-out curve for interface feedback because it responds immediately. Avoid an ease-in start on interactive changes; the narrow exception is a complete off-screen exit that does not delay the next usable state.
When the character is uncertain, build two meaningfully different variants and compare them side by side. Do not produce several nearly identical timings and call that exploration.
Define the Reduced Variant
Reduced motion is part of the behavior, not a cleanup task. Specify both variants in the brief:
- Standard: the movement, scale, reveal, or choreography that communicates the change.
- Reduced: the same information and final state with movement removed or minimized, usually through an instant change or a short opacity or color transition.
Autoplaying video, animated images, smooth scrolling, parallax, and loops need an explicit pause, play, or static-frame decision. Reduced motion must never make content remain hidden or leave an interaction unfinished.
Deliver the Brief
Use this compact handoff before writing code:
### Motion brief
- Verdict: Animate | Keep static
- Trigger and frequency:
- Purpose:
- Start and end states:
- Origin and direction:
- Entry / exit timing:
- Easing or spring character:
- Interruption and repeated input:
- Reduced-motion variant:
- Existing tokens and implementation stack:
- Performance or accessibility risk to validate:
Every line should contain a decision. No blank fields, invented product context, or unresolved “TBD” values. If one decision remains open, name it as the next question and pause before implementation.
Validate the Contract
Review the implemented motion against the brief, not against whether it merely runs.
- Trigger it repeatedly and interrupt it midway.
- Test both the standard and reduced variants.
- Check the first frame, final frame, origin, and exit direction.
- Record a representative interaction in browser performance tools when the surface is busy or the motion tracks input.
- Revisit the original purpose. If the motion no longer makes that outcome clearer, remove it.