Turn a vague motion brief into a spec

Words such as polished, weighty, and smooth describe feeling without describing what happens in an interface. The first step of a spec is to ask for observable events: who triggers the change, which object changes, what people can see before and after, and how long the result needs to be understood. “A card arrives with an action and gradually stops” can become a card entering near its trigger, arriving quickly, decelerating near the end, and retaining a clear boundary and title. The team then discusses states and rhythm instead of private interpretations of aesthetic words.

Naming before and after states also reveals missing information. A publish button commonly has at least Draft, Publishing, Published, and Publish failed; a request that says only “play a success animation after click” misses waiting, failure, and repeat activation. Once states sit in a table, each row has visible copy, allowed actions, accessibility announcement, and visual cue. The spec becomes a compact behavior contract: engineering can build a state machine from it and testing can write assertions from it.

A state graph answers which transitions are allowed; a beat plan answers what becomes visible when. Keeping them separate prevents a common failure: a lovely timeline that cannot handle a second click, a slow network, or a failed request. Draw legal transitions first, such as Draft to Publishing to Published, with Publishing also able to move to Failed. Then write key beats for each transition: at 0ms lock the button and acknowledge input, at 80ms show processing, and after the server returns switch the final state. Beats describe perceptible nodes rather than documenting every frame.

The number of beats should increase with information complexity, not decorative ambition. Save confirmation may need only Pressed, Saving, and Saved; an approval request needs the approver queue because people must understand whom the system is awaiting. For several elements, state who changes first, who follows, and who stays still. Stillness is often an important design choice: it gives an anchor against which a new row, result number, or status label can be compared. A good spec explicitly names what should remain still.

A spatial spec includes origin, destination, distance, and hierarchy. Origin tells people why change occurs here; destination tells them where the result belongs; distance determines whether motion steals attention; hierarchy decides whether content overlays, pushes, or sits beside other content. Replace “slide in from the left” with “enter the result region beneath the active filter, travel no more than 16px, and keep the result count in place.” Engineering can then choose transform, inserting a row, or replacing existing content, while design can judge whether the action still follows interface structure.

A time spec needs both duration and relationships. A lone value such as 240ms says how long one change lasts, while saying nothing about whether a button and status label synchronize, whether a list appears after the result settles, or whether failure interrupts processing. “Button feedback: 120ms; status copy appears after 80ms; success switches when the request completes; follow-up record delays 60ms” is clearer. Add the job of the curve: ease-out supports a definite arrival, while spring supports continuous input or interruptible objects. Curve names are implementation choices; people perceive arrival, pause, and continuity.

Motion specs often end at the success path, forcing edge cases to be improvised after launch. Every in-progress state should answer: What happens on another click? On leaving the page? On timeout? When returned data is stale? For cancelable work, the visual state should return to a clear starting point; for noncancelable work, button and copy should explain what is completing. A failure state must retain the original input or recoverable context so people do not see failure and lose their previous work at the same time.

Low-motion rules also belong in state definitions. “Reduce motion” is too vague; state which signals remain, which travel shortens, which loops stop, and how focus is managed. In a publishing flow, the low-motion version still retains button state, publishing result, and record insertion while removing travel along a path and decorative rotation. Put that rule on every key transition so it never becomes a last-minute patch. It also clarifies the default path because the team must state what every animation actually communicates.

A handoff-ready spec lets someone who missed the conversation reproduce the judgment. Start with scenario, audience, and success criteria; give state graph, beats, spatial relationships, and parameter ranges in the middle; close with failure, undo, low-motion behavior, and review methods. A static diagram or interactive prototype helps communication, yet an image cannot replace words: tests need to know when to assert, engineering needs to know when data updates, and content design needs to know how copy changes. Text, diagram, and code fragment together create a traceable decision.

Acceptance statements should be observable. Instead of “feel smooth,” write: “Within 120ms of Publish, show an in-progress state; when complete, button, status marker, and timeline record become Published in the same state update; low-motion mode uses no decorative travel over 1px; on failure, title, body copy, and retry remain.” Such standards preserve room for design judgment while giving automation and human review the same facts. The spec then feeds the content library: every verified scenario can become a future Product Moment.