How to add subtle animation to a website with AI

Start with one change that a user needs to understand: an item moved, a panel opened, or a save completed. Add motion around that change after the underlying interaction works. Keep the final state understandable without animation and avoid making reading depend on a reveal effect.

Choose the smallest useful movement

A card that rises slightly on hover can signal interactivity. A list item moving into its new position can explain a reorder. An entire page drifting continuously usually explains less while asking for more attention. Write down what the movement communicates before choosing timing or distance.

For a fictional saved-items list, the useful event is the item moving into a saved section. A decorative bounce after every click may compete with that information. Animate the transition once, then let the interface settle.

Start with a CSS enhancement

.action-card {
  transition: transform 180ms ease-out;
}
@media (hover: hover) and (pointer: fine) {
  .action-card:hover { transform: translateY(-3px); }
}
.action-card:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 4px;
}
@media (prefers-reduced-motion: reduce) {
  .action-card { transition: none; }
  .action-card:hover { transform: none; }
}

The timing and distance are starting choices, not universal design standards. This snippet assumes the card contains a real link or button. Adding a hover effect does not make a non-interactive div keyboard accessible.

Audit the complete interaction

• Confirm the action works before and after the animation.
• Click twice quickly and inspect the resulting state.
• Navigate with the keyboard and check focus visibility.
• Turn reduced motion on and verify the immediate state remains clear.
• Try a touch device where hover is not the primary interaction.

Watch for animations that leave content translated, hide text until an observer runs, or delay input while an effect finishes. The effect should explain the interface rather than become a prerequisite for using it.

Give your AI a narrow brief

Add a small animation to this existing state change.
Explain what it communicates before proposing code.
Keep the no-animation path fully usable.
Respect reduced motion, keyboard focus, touch input, and rapid repeated actions.
Change only the smallest relevant component and include a cleanup path
for any animation or event listener.
Component and interaction: [code and description]

Test the resulting code in the actual browser and framework. A generated snippet can be a useful starting point, but its behavior depends on your layout, state updates, and existing styles.

Make a small motion plan before changing code

For each effect, record the trigger, purpose, final state, reduced-motion path, and interruption policy. A fictional list-filter plan could be:

This plan prevents the animation from becoming the source of truth for the interface. The selected filter belongs in application state; the movement is temporary presentation.

Choose what to leave still

Do not animate every heading, paragraph, and card on entry. Repeated entrances can make a long page feel busy and may hide content before JavaScript runs. Keep reading content visible by default. An observer may add movement to an already readable element, but it should not decide whether the reader can see the text.

Loading is another place to be restrained. A quiet status can communicate pending work without a looping shimmer. If you do animate loading, stop when the operation ends and show a real error path. A decorative progress bar should not imply measured progress you do not have.

Review the browser sequence

Start the effect, trigger a second action immediately, then navigate away while movement is active. Inspect the console and final state. Repeat with reduced motion active from the beginning and with the preference changed during the effect. This sequence catches lifecycle problems that a single settled screenshot misses.

Measure performance only when you need to make a performance claim or diagnose a problem. Do not report a faster interface because an effect looks smoother. The useful outcome is a working interaction that communicates change with less confusion, supported by the checks you actually performed.

Include the actual component in your request

If you are using a coding AI, share the component and its relevant styles, not just a screenshot of the final page. Say what the control does and where its state is stored. A screenshot can show appearance, but it cannot establish what happens when a request fails or when someone presses Escape.

For a fictional save button, a useful request is: “This button saves the form. Keep the text visible. While saving, show the existing pending message. On success, let the confirmation fade in briefly; on error, show the error immediately and preserve the input. Do not delay another click to finish an animation.”

The exact duration is a design choice to test in your page. The brief matters because it connects the effect to the states people need to understand.

Keep an interaction test sheet with the change

Have the coding AI explain how its implementation passes each relevant row, then run the checks yourself. Keep the test sheet with the component so the next design change can be reviewed against the same interaction.