Animation prompts that level up Claude / Lovable / Cursor-built sites (2026)

The Claude artifact looks like a Claude artifact. The Lovable page looks like a Lovable page. The Cursor-built site looks like a Cursor-built site. Same fonts, same color blocks, same default spacing, same static hero. The work is correct; the page is anonymous.

The gap between correct and feels like the team shipped this is mostly animation. Not the kind that draws attention to itself — the kind that makes the page respond to the reader instead of just sitting there.

This piece walks through four patterns that close most of the gap, with prompt templates that work whether the AI builder is Claude, Lovable, Cursor, v0, or Bolt.

Why animation is the differentiator now

Three years ago, the AI builder ceiling was does it render. The current ceiling is does it feel like a human shipped it. The render is solved; the feel is where the divergence between sites happens.

A few small animations move the needle quickly:

• Content that fades in as the reader scrolls past it reads as intentional instead of placeholder.
• A button that lifts slightly on hover reads as built for use instead of built for screenshots.
• A page transition that fades the previous view out reads as one product instead of separate static pages.

None of these are the page's value proposition. All of them shape whether the reader trusts the page enough to read the value proposition.

The four patterns and their prompts

1. Scroll-driven reveals

The pattern: as the reader scrolls down, sections fade in and translate up slightly when they enter the viewport. The technique is IntersectionObserver + a small CSS transition, no library needed.

Cross-tool prompt:

Add scroll-triggered animations to the page. Each main section should start with opacity: 0 and transform: translateY(20px), then transition to opacity: 1 and transform: translateY(0) over 600ms with a cubic-bezier ease-out. Use IntersectionObserver to add an in-view class when the section enters the viewport; the transition fires on that class. No animation library — pure CSS transitions and one IntersectionObserver in vanilla JS.

The output is around 30 lines of CSS and JavaScript, runs on any browser, costs nothing on the bundle size. Works in Claude artifacts, Lovable projects, Cursor-built sites, and pasted into v0 or Bolt outputs.

2. Staggered entrances for lists and grids

The pattern: when a feature grid, card list, or testimonial wall enters the viewport, the children animate in one at a time with a 50–80ms stagger. Reads more alive than the whole grid appearing at once.

Cross-tool prompt:

The feature grid should animate in with a stagger when it enters the viewport. Each child card starts at opacity: 0 and transform: translateY(16px), then transitions in. Use transition-delay based on the child index — child 1 at 0ms, child 2 at 80ms, child 3 at 160ms, and so on, capped at 480ms so a long grid doesn't have a long total animation. The transition itself is 500ms ease-out. Use the same IntersectionObserver pattern as the section reveals.

The cap on total delay is the part most AI builders skip on their own — without it, a twelve-card grid animates over a full second, which reads as slow rather than alive.

3. Hover micro-interactions

The pattern: buttons, cards, and links respond to the cursor with small physical responses — lift, scale, shadow change. Each interaction is under 200ms.

Cross-tool prompt:

Add hover responses to the primary buttons and feature cards. Buttons should lift 1px with a slight scale to 1.02 and the shadow soften and grow; transition is 180ms ease-out, and the reverse on mouseleave is 240ms ease-in (slightly slower than the lift, which reads as more physical). Cards should lift 2px and have the border color shift to a slightly brighter version on hover. Use CSS only — no JavaScript, no animation library.

The asymmetric timing (faster on enter, slower on leave) is the detail that separates "AI-default" hover from "this was designed". Most AI builders use the same timing in both directions; asking explicitly is the only way to get the asymmetry.

4. View-state transitions

The pattern: when a section reveals new content (a tab switch, an accordion expanding, a state change in a calculator), the transition is animated rather than instant.

Cross-tool prompt:

Animate the state transitions on the [feature: tab switcher / accordion / pricing toggle]. When the active state changes, the old content fades out at 150ms while the new content fades in at 200ms with a 100ms delay so they cross-fade slightly. The layout shift (if the new content has different height) should animate via height with overflow: hidden and a 250ms ease-out transition. Use Web Animations API or CSS transitions, no library.

For full page-to-page transitions on a multi-page site, prompt for the View Transitions API specifically:

Wrap the navigation in the View Transitions API. Each route change should fade-cross over 300ms. Fall back to instant navigation in browsers that don't support the API. The CSS hook is ::view-transition-old(root) and ::view-transition-new(root).

What "less is more" actually means here

The reflex with animation is to apply it to everything. The reflex with prompting AI is to add features. Together they produce pages where every element is moving, hovering, scaling, fading — and the page reads as more anonymous than the static version it replaced.

The rule that holds across most builds:

• Animate the entry of major sections. Hero, the next section, each major content block.
• Animate response to user action. Hovers, taps, state changes.
• Don't animate decoration. Background gradients shifting, floating particles, icons spinning when not interacted with — these decorations exist to prove animation is there, which is the opposite of what good animation does.

For AI builders, the next-prompt after the initial build is often remove the decorative animations and keep only the reveal-on-scroll, hover responses, and state transitions. The page settles into the right rhythm.

Performance — the part most AI builders skip on their own

Native CSS transitions and the Web Animations API run on the browser's compositor thread, which means they don't block the main thread and they stay smooth even when the page is doing other work. The pattern that breaks this:

• Animating width, height, top, left — triggers layout, jank-prone
• Animating transform and opacity — compositor-only, smooth

Most AI builders, prompted for "animate the card on hover", will default to animating transform: scale(...) and opacity — which is correct. Where they go wrong: prompting for an accordion expansion will often get them animating height, which is the slow path. Add to the prompt: use max-height with a transition, or use the height: auto to height: <px> trick with JavaScript-measured height, never animate height directly. The output runs cleaner.

What this is not

These patterns level up the surface. They don't fix a page that's missing the actual work — the copy, the information hierarchy, the typography, the spacing. Animation on a bad page makes a slightly more polished bad page.

The order most professional builds follow: typography and spacing first, then the copy and information density, then the color and contrast, then animation. Adding animation early is fun and produces immediate-looking results; it's also the layer most likely to need ripping out if the lower layers shift.

For the actual ship — getting the file from the AI tool to the client or stakeholder — the pipeline goes through making the artifact self-contained (so the animations survive outside the AI tool's frame) and then picking the delivery channel (private link, public host, attachment) that matches the audience.