How to Write Animation Prompts for AI Code Tools

The difference between an AI-generated app that feels polished and one that feels flat comes down to one thing: the animation prompt. Not whether you asked for animations — but how you asked for them.

Most developers write prompts like "add smooth animations to my components." The AI responds with scattered transition: all 0.3s ease declarations and maybe an opacity fade. Everything gets the same treatment. Nothing feels intentional.

This guide teaches you how to write animation prompts that make AI coding tools generate production-quality motion — specific timing, coordinated easing, spring physics, stagger patterns, and accessibility support. Whether you use Cursor, Claude, Lovable, or any other AI tool, these principles apply.

Why generic prompts produce generic animations

AI coding tools are pattern matchers. When you say "add animations," the tool reaches for the most common pattern it's seen in training data: a basic CSS transition or a simple opacity fade. It has no context about your design language, your timing preferences, or which elements should be animated differently.

Think of it this way: asking an AI to "add animations" is like asking a designer to "make it look good" without a design system. You'll get something — but it won't be cohesive, and it probably won't match your standards.

The fix is specificity. The more precisely you describe the motion you want, the better the output. Let's look at what that means in practice.

Bad prompt vs good prompt: side by side

Example 1: Card entrance

Bad prompt:

Add an entrance animation to the card grid.

What AI generates: Each card gets opacity: 0 to opacity: 1 with transition: 0.3s ease. All cards appear simultaneously. No stagger, no spring physics, no vertical movement.

Good prompt:

Add entrance animations to the card grid using Framer Motion.
Each card should fade in and slide up from y: 20px.
Use spring physics: damping 25, stiffness 250.
Stagger each card by 60ms using variants and staggerChildren.
Cards should animate once on mount, not on every re-render.

What AI generates: A variants object with staggerChildren, individual card variants with opacity + y transform, spring transition with the exact values specified, and initial="hidden" animate="visible" on the container.

The difference is night and day. Same AI tool, same component — completely different output.

Example 2: Hover interaction

Bad prompt:

Add a hover effect to the buttons.

What AI generates: className="hover:bg-blue-600 transition-colors" — a color change with a generic transition.

Good prompt:

Add hover and tap interactions to buttons using Framer Motion.
Hover: scale 1.04, y offset -1px, transition spring damping 18 stiffness 350.
Tap/press: scale 0.97, spring damping 12 stiffness 500.
Include focus-visible ring with spring animation.

What AI generates: whileHover, whileTap, and whileFocus props with the exact spring configurations. Physical, tactile button feedback that feels like pressing a real button.

Example 3: Modal

Bad prompt:

Add an animation to the modal.

What AI generates: Maybe an opacity transition on the modal wrapper. No exit animation. The backdrop appears instantly. When the modal closes, it vanishes.

Good prompt:

Wrap the modal in AnimatePresence with mode="wait".
Entrance: opacity 0 to 1, scale 0.95 to 1, spring damping 25 stiffness 300.
Exit: opacity 1 to 0, scale 1 to 0.98, duration 200ms ease-out.
Backdrop: opacity 0 to 1, duration 200ms.
Backdrop exit: opacity 1 to 0, duration 150ms.
Exit should be faster than entrance.

What AI generates: Full AnimatePresence implementation with coordinated modal and backdrop animations, proper exit animations, and different timing for enter vs exit.

The five principles of effective animation prompts

Principle 1: Specify the library

Always tell the AI which animation library to use. Without this, you'll get a mix of CSS transitions, Framer Motion, and sometimes even inline JavaScript animations in the same project.

Use Framer Motion for all animations. Do not use CSS transitions
for any motion that involves scale, position, or opacity changes.

For more on why Framer Motion is the right default for AI tools, see Framer Motion vs CSS Animations in AI-Generated Code.

Principle 2: Define spring values explicitly

Don't say "smooth spring animation." Specify the parameters:

Spring physics:
- General interactions: damping 25, stiffness 250
- Snappy feedback (buttons, toggles): damping 15, stiffness 400
- Gentle entrance (page-level): damping 30, stiffness 200

Different interactions need different spring configurations. A button press should feel snappy (high stiffness, low damping). A page entrance should feel smooth (lower stiffness, higher damping). By defining these upfront, every component gets the right feel.

Principle 3: Describe component states completely

Every animated element has multiple states. Describe all of them:

Card component states:
- Initial (mount): opacity 0, y 20px, scale 0.98
- Visible (after entrance): opacity 1, y 0, scale 1
- Hover: scale 1.02, y -4px, shadow elevation
- Tap: scale 0.98
- Exit (unmount): opacity 0, y -10px
- Reduced motion: opacity transitions only, no transform

Most developers only describe the hover state and leave everything else to the AI's defaults. The result is incomplete animation — elements pop in without entrance animations and disappear without exits.

Principle 4: Choreograph stagger patterns

When multiple elements animate, they need a relationship to each other. Describe the choreography:

Stagger patterns:
- List items: 50-60ms between each child
- Grid cards: 60-80ms between cards, row by row
- Section groups: 100ms between major sections
- Feature lists within cards: 40ms between features,
  starting after the card's entrance completes

This creates a cascading effect that guides the user's eye. Without stagger instructions, AI tools either animate everything simultaneously (looks chaotic) or don't stagger at all (looks static).

Principle 5: Always include reduced-motion fallbacks

This is the principle most developers skip, and it's the one that matters most for accessibility:

Reduced motion (prefers-reduced-motion: reduce):
- Replace all spring and transform animations with simple
  opacity transitions, duration 150ms
- Remove all scale, y offset, and rotation changes
- Keep opacity fades as they don't cause motion sickness
- Use the useReducedMotion() hook from Framer Motion

Roughly 30% of users have reduced motion enabled (often via OS-level accessibility settings). Without this fallback, your animations can cause discomfort or nausea for these users. AI tools implement reduced-motion support well — but only when asked.

Putting it all together: a complete motion prompt

Here's what a complete animation prompt looks like when you combine all five principles:

## Animation Specification

Library: Framer Motion (no CSS transitions for motion)

### Spring configurations
- Default: { type: "spring", damping: 25, stiffness: 250 }
- Snappy: { type: "spring", damping: 15, stiffness: 400 }
- Gentle: { type: "spring", damping: 30, stiffness: 200 }

### Entrance animations
- Elements fade in (opacity 0 to 1) and slide up (y 20 to 0)
- Use default spring config
- Stagger children by 60ms using variants

### Hover interactions
- Cards: scale 1.02, y -4, elevated shadow, default spring
- Buttons: scale 1.04, snappy spring
- Links: no scale, underline animation only

### Tap/press
- Buttons: scale 0.97, snappy spring
- Cards: scale 0.98

### Exit animations
- Wrap all conditional elements in AnimatePresence
- Exit: opacity to 0, y to -10, duration 200ms ease-out
- Exits should be 30% faster than entrances

### Scroll-triggered
- Sections: whileInView with once: true, amount: 0.3
- Same entrance animation as mount, but with gentle spring

### Reduced motion
- Replace all motion with opacity transitions (150ms)
- Remove scale, y, rotation transforms
- Use useReducedMotion() hook

Paste this into your AI tool's context — as a Cursor Rule, Claude Project Knowledge, or directly in your Lovable prompt — and every component generated will follow these rules.

Or skip the writing — use pre-built motion prompts

Writing a comprehensive motion prompt from scratch takes time. You need to know the right spring values, understand stagger timing, and think through every interaction state. The prompt above is a simplified version — production prompts cover edge cases like route transitions, toast notifications, skeleton loaders, and more.

That's why UI Motion Prompts exists. We've done the hard work of crafting detailed, tested motion specifications that work across AI coding tools. Each prompt covers the full animation surface — entrances, exits, hovers, taps, scroll-triggered, layout animations, and accessibility — with values tuned for specific use cases like dashboards, marketing sites, and e-commerce.

Instead of spending an hour writing and testing your own motion prompt, you can copy one that's already been validated across Cursor, Claude, and Lovable, and start getting production-quality animations in minutes.

For more on the concept behind motion prompts, read What Are UI Motion Prompts?. For a quick reference of the Framer Motion patterns these prompts generate, see our Framer Motion Cheat Sheet for Vibe Coders.

Start with specificity

The single most impactful change you can make to your AI animation workflow is this: stop writing vague animation prompts. Every time you type "add smooth animations," replace it with specific values — the library, the spring parameters, the stagger timing, the exit behavior, and the reduced-motion fallback.

Your AI tool already knows how to implement all of this. It's waiting for you to tell it what you actually want.

UI Motion Prompts — pre-built animation specifications that tell AI exactly what to generate. Stop writing generic prompts and getting generic results. Browse the prompt library and ship polished motion in every component.