Motion Design with Claude Code: Prompts That Produce Better Web Animations

“Make the page feel premium” is not a motion brief. Claude Code can turn that sentence into spinning cards, a parallax hero, and hover effects on every button—and still miss the one transition that would help a user understand what changed.

Better animation begins with a decision: what should move, why, when, and what should happen for someone who prefers less motion? A good Claude Code prompt makes those decisions inspectable. It asks the agent to study the existing interface, implement one purposeful effect, and verify the result in the real app.

This guide is a prompt cookbook for web UI motion, not video motion graphics. The prompts are reusable editorial examples, not evidence that we ran them against your site or that they guarantee a particular aesthetic. Anthropic's prompting guidance recommends clear constraints and context; its frontend advice emphasizes a few well-orchestrated moments over scattered micro-interactions. The source is written for Claude models generally, so test the output in your own Claude Code workflow.

Start with a motion brief, not an animation library

Before asking Claude Code to edit code, define six things:

This turns motion from decoration into feedback or hierarchy. For simple hover, focus, and entrance effects, CSS may be enough. For React state transitions, layout changes, gestures, or interruptible sequences, Motion for React is one documented option. Do not add a dependency merely because a prompt mentions animation; ask Claude to inspect the project's existing stack first.

The prompt should also say what not to animate. A useful constraint is “one primary motion moment per screen, plus only functional feedback elsewhere.” That is a design choice, not a universal rule, but it prevents the common output where every component competes for attention.

A reusable prompt template

Use this when the repository already exists. Replace the bracketed fields rather than pasting vague visual adjectives on top.

Inspect the existing [page/component] and its styling, design tokens, and
animation dependencies before editing. I want motion that communicates
[specific purpose] when [trigger].

Motion brief:
- Primary target: [element(s)].
- Initial and final states: [what changes].
- Character: [e.g., restrained and quick], with no [unwanted effect].
- Use the existing stack. Prefer CSS for a simple effect; propose a library
  only if the interaction needs state-aware or layout animation.
- Do not animate unrelated components or redesign the page.
- Preserve keyboard access, focus visibility, and pointer/touch behavior.
- Respect prefers-reduced-motion with a meaningful static or quieter path.

First give me a short implementation plan and the files you expect to touch.
Then implement it. Run the relevant checks. If a browser preview is available,
inspect desktop, mobile, and reduced-motion states. Report what you verified
and what you could not verify; do not claim visual QA you did not perform.

The important fields are purpose, trigger, states, and acceptance checks. Exact duration and easing can be specified when the brand has a motion system; otherwise ask Claude to choose a restrained value and explain it, then judge the result in a preview. A number in a prompt is a starting constraint, not proof the animation feels right.

Prompt 1: a page-load reveal with a clear visual hierarchy

A landing page may need a single entrance sequence that helps the eye find the headline, supporting text, and call to action. This is a better target than animating every card independently.

On the existing landing page, add one restrained entrance sequence for the
hero only. Inspect the current component structure and CSS first.

Order: headline, supporting paragraph, then primary action. Keep the total
sequence brief and make the action usable immediately; no long wait before
it can be clicked. Use subtle opacity and a small vertical offset, with no
parallax, blur, scale-up, or looping movement. Do not animate the navigation,
body copy below the hero, or content when it re-renders for unrelated reasons.

Use CSS if the existing structure supports this cleanly. Reuse existing
tokens. For prefers-reduced-motion, display the final state without spatial
movement. Check mobile widths and ensure text remains readable even if
animation fails or JavaScript is unavailable. Show me the final diff and
explain how to preview both motion settings.

Acceptance criteria: the reading order stays logical, the CTA is never trapped behind an animation, and the hero does not replay on every state update. If Claude introduces a complex dependency for this sequence, ask why CSS was insufficient.

Prompt 2: feedback for a button or form action

Motion is most valuable when it makes an interface state legible. A save button needs clear idle, pending, success, and error states. The visual change should reinforce the words, not replace them.

Improve the feedback for the existing Save action. Inspect the current
request state, button markup, error handling, and design tokens before editing.

Keep the button label and accessible status clear in four states: idle,
pending, success, and error. Add a brief visual transition between states,
but do not delay the request, block keyboard interaction unnecessarily, or
use motion as the only signal. Preserve the current API and validation flow.

Prefer a small CSS transition unless the component already uses Motion for
React. Avoid perpetual loading animation after the request resolves. Under
prefers-reduced-motion, show each state immediately or with a quiet opacity
change. Test a successful save, an error, keyboard activation, and repeated
clicks. Report any state that could not be exercised locally.

The prompt names behavior that matters more than polish: a resolved request must leave the pending state, and users must still understand success or failure without seeing animation. For semantics, Claude may need to add or preserve status text and appropriate live-region behavior; review those changes as functional UI, not decoration.

Prompt 3: an interruptible layout transition

Tabs, accordions, filters, and sidebars have state. An animation should follow that state and survive rapid user input. This is where a state-aware library can earn its cost—but first check whether the project already has one.

The results panel changes when a user selects a filter. Make that transition
clear without moving the whole page. Inspect the current React state flow and
dependencies before choosing an animation technique.

Animate only the active-filter indicator and the results container. If Motion
for React is already installed, you may use its layout or presence features;
otherwise explain whether CSS is sufficient before adding a package.
Keep the transition short and interruptible: rapid filter changes must end
on the latest selected state without stale content flashing.

Preserve focus, URL state, loading/empty states, and keyboard navigation.
For reduced motion, update to the new state without spatial movement.
Test rapid switching and narrow screens. Summarize which cases were actually
verified and show the files changed.

Motion's React guide documents layout and exit animations, while its accessibility guide explains how to adapt or disable spatial motion for users who request less. Those APIs are options, not a blanket recommendation to use Motion for every transition.

Ask Claude Code to review the motion it made

The first implementation often looks plausible in code but feels wrong in motion. After the edit, use a separate review prompt. If Claude Code has browser access, ask it to inspect the running page; otherwise request a precise manual test script and keep visual claims modest.

Review only the animation changes in the current diff. Compare the result
against the original motion brief and inspect the running UI if a browser
preview is available.

Check: purpose and hierarchy; replay behavior; interruptibility; mobile
layout; keyboard focus; reduced-motion behavior; loading/error states; and
whether the animation causes layout shift or unnecessary paint work.

For each issue, cite the file and the observed behavior. Separate what you
directly verified from what you infer from code. Fix the smallest set of
issues needed, rerun relevant checks, and list any manual visual checks still
required. Do not add new effects during the review.

This final constraint matters. “Improve the animation” can become permission to add yet another animation. A focused review checks the original intent and stops.

Accessibility and performance are part of the brief

The browser's prefers-reduced-motion media feature signals that a user wants less non-essential movement. It does not necessarily mean that all state changes should become invisible. Preserve information and feedback while reducing or replacing spatial motion. Motion for React offers reduced-motion controls for the same purpose. Motion: accessibility

Animation can also feel slow because it triggers layout or painting work. Google's animation performance guide recommends favoring transform and opacity where practical and being careful with properties that change geometry. That is not a ban on animating height or layout: it means measure the result on the actual page and device, especially when many elements move at once.

Put these checks in the prompt:

• Does the animated state remain understandable without movement?
• Can a keyboard user reach and see the focused control throughout?
• Does the animation replay unexpectedly on re-render or route return?
• Can a user interrupt it, click during it, or switch states rapidly?
• Does it remain readable on a small screen and a slower device?
• Did the agent actually run or inspect the page, or only read the code?

If you have a design system, give Claude its existing motion tokens and examples. If you do not, start with one carefully reviewed effect rather than inventing an entire motion system in a single prompt.

The prompt pattern to keep

The reusable pattern is inspect → brief → implement → verify → review. Tell Claude Code what the motion communicates, which elements may move, what must remain unchanged, and how to prove the result works for more than one user preference. This is more durable than any list of “best animation words.”

For the broader workflow of keeping an agent grounded in a repository, see our context-engineering guide and agent-harness guide. Claude Code can write the animation; the product team still owns the taste and the acceptance decision.