Prompt-Driven Motion Design: A Structure That Gets Usable Results
A repeatable prompt structure for UI motion: object, trigger, states, property, timing, platform and constraints. Includes an example and review checklist.
Core Takeaway
A useful motion prompt names the object, the trigger, the states, the property that changes, the timing or physics, the target platform and the constraints. That structure gives an AI tool enough to produce a component you can test. Adjectives such as smooth or delightful do not specify behaviour, so the model fills the gap with a default.
Why most motion prompts fail
A prompt such as make the button feel premium is a mood, not a specification. The model has to guess the property, the distance, the duration, the easing and the trigger. It will usually pick a common default, which is why AI-generated motion often feels generic. The fix is not a longer prompt. It is a more specific one.
The seven parts of a motion prompt
Use the same structure every time so results are comparable.
- Object: the component and its size or context
- Trigger: tap, hover, focus, drag, data change or page load
- States: idle, pressed, loading, success, error and any others
- Property: position, scale, opacity, rotation, colour or text
- Timing or physics: duration and easing, or stiffness and damping
- Platform: React, SwiftUI, Flutter or a web demo
- Constraints: reduced motion, transform-only, no layout shift, brand tokens
An example prompt
A prompt that follows the structure might read: Build a save button for React. On press, scale to 0.96 over 90ms; on release, spring back to 1 with stiffness 420 and damping 30. When saving is true, show a small progress ring inside the button and keep the label width fixed. On success, morph the ring into a check for 600ms, then return to idle. On error, shake once by 3px and show the message below. Respect prefers-reduced-motion by replacing scale and shake with an instant colour change. Do not change the layout or the button's font.
Name what must not change
Constraints are as important as instructions. Tell the model to keep the existing component API, the text, the layout and the design tokens. Tell it which properties it may animate. A model that is free to restructure the component will often do so, and the resulting diff is harder to review than the motion itself.
Review the result as behaviour
Do not judge the output from a still frame. Trigger it, interrupt it, reverse it and run it with reduced motion. Check that the loading state cannot coexist with success, that the label does not jump when the spinner appears, and that the component still works when the action fails. A prompt can describe the happy path; the review has to cover the rest.
Make the prompt reusable
Save the structure as a template and fill in the object and states. If the AI tool supports project context or a design system, connect it so the model uses your tokens instead of defaults. Point the prompt at a real component or file rather than asking for a new snippet. The same discipline applies to any AI-assisted motion tool, regardless of vendor.
Key Principles to Remember
- Name object, trigger, states, property, timing, platform and constraints
- Replace mood adjectives with measurable behaviour
- State what must not change, including the component API and layout
- Review interruption, failure and reduced motion, not just the happy path
- Save the prompt structure and connect the tool to your real design system
Frequently Asked Questions
Sources
- Motion — Apple Human Interface Guidelines
- Motion overview — Material Design 3
- Understanding SC 2.3.3: Animation from Interactions — W3C WAI