UI Motion Design: Animation in Websites and Apps

UI motion design is not decoration. It answers questions users ask without saying them out loud: did my tap register? Where did this menu come from? What just changed on the page? Good interface motion is short, almost invisible, and makes the product clearer and easier to use. Bad motion slows people down, distracts them and can even make them feel dizzy. This guide covers what motion is for in websites and apps, common durations and easing, performance, reduced-motion preferences and the direction of motion in Arabic interfaces. It is part of the complete guide to animation and motion graphics.

Why animate interface elements at all?

Before adding any motion, name its job. If you cannot name one, the interface is probably better without it.

Feedback

Motion confirms that an action landed: a button that shifts slightly when pressed, a toggle that slides to its new position, a form field that shakes gently after invalid input, a checkmark that appears once payment goes through. During operations that take time, a loading indicator or a skeleton screen reassures users that something is happening.

Orientation

Motion builds a mental map of the product. A side menu slides in from the edge where it "lives", a dialog grows out of the button that opened it, and going back reverses the direction of the entrance. Users always know where they are and how to return.

Continuity

When a product thumbnail in a list expands into the large image on the product page, users understand that the two screens are connected and keep their context. These shared element transitions reduce the mental effort of switching screens.

Attention and personality

Motion can direct the eye to an important notification or an error that needs fixing, and it can add a touch of brand personality. Use both sparingly: if everything moves, nothing stands out, and personality that slows users down becomes a burden. For the wider foundations, see UI and UX design fundamentals.

Durations: guidelines, not rules

Interface motion is much shorter than video motion. Most of it falls roughly between 100 and 500 milliseconds, and most micro-interactions sit around 150 to 300 ms. Treat the table below as a starting point, and let testing on real devices have the final word:

Rules that help you tune duration:

• Distance and size: an element that travels further or covers more of the screen needs slightly more time.
• Exits are faster than entrances: a leaving element is no longer the focus, so it should not take the user's time.
• Frequency shortens duration: motion people see dozens of times a day should be the fastest. What feels charming the first time becomes irritating the twentieth.
• Staggering: when a list appears, an offset of a few tens of milliseconds between items is enough. Cap the total so a long list does not take seconds to arrive.

Easing in interfaces

The logic extends what timing, spacing and easing explains, applied to interfaces:

• Entering elements: ease out (decelerate), so they arrive quickly and settle gently.
• Exiting elements: ease in (accelerate), so they pick up speed and disappear.
• Elements moving within the screen: ease in-out.
• Linear motion: only for continuous movement such as circular loaders and progress bars.

In a design system, turn these values into tokens: short, medium and long durations, plus a standard curve, an enter curve and an exit curve. The whole product then moves with one personality instead of every developer picking their own values. For gestures such as drag and release, many platforms and libraries offer spring-based animation, which feels natural and copes well when a motion is interrupted halfway.

Performance: animate what the browser can move cheaply

Janky motion is worse than no motion. To hit 60 fps, the browser has about 16.7 ms to produce each frame, and anything slower shows up as visible stutter, especially on mid-range phones.

• Animate transform (translate, scale, rotate) and opacity: browsers can usually handle these at the compositing stage without recalculating the page layout.
• Avoid animating width, height, margins and position (top and left): these force the browser to recalculate layout and repaint on every frame.
• Use will-change sparingly: overusing it eats memory instead of speeding things up.
• Pick the right format for complex illustrations: Lottie, Rive or a short compressed video rather than large GIFs. Motion graphics and animation software explains the difference between these tools.
• Never hold content hostage: important content should appear immediately, and animations should stay interruptible so users never wait for a motion to finish before tapping again. The wider impact on browsing is covered in website speed.

Here is a short example that combines performance-friendly animation with a reduced-motion fallback and right-to-left support:

.card { transition: transform 200ms cubic-bezier(0.2, 0, 0, 1), opacity 200ms ease-out; }
.card:hover { transform: translateY(-4px); }

.drawer { transform: translateX(-100%); transition: transform 300ms ease-out; }
[dir="rtl"] .drawer { transform: translateX(100%); }
.drawer.open { transform: translateX(0); }

@media (prefers-reduced-motion: reduce) {
  .card, .drawer { transition: opacity 150ms linear; }
  .card:hover { transform: none; }
}

Respecting reduced-motion preferences

Some people experience dizziness, nausea or difficulty concentrating with large movements, so operating systems offer a setting to reduce motion, such as "Reduce Motion" on Apple devices and similar settings on Android and Windows. Websites can read this preference through the prefers-reduced-motion media query in CSS or through JavaScript, and native apps have equivalent APIs.

What should change when the preference is on?

• Replace large slides, zooms, spins and parallax effects with a simple fade or an instant change.
• Stop background videos and rotating carousels from playing automatically.
• Keep essential feedback. Button state changes and success indicators stay, just with calmer motion.

Two general principles from the Web Content Accessibility Guidelines (WCAG) also apply: avoid anything that flashes more than three times in one second, and give users a way to pause any motion that starts automatically and lasts more than five seconds. See web accessibility for more.

Direction of motion in Arabic (RTL) interfaces

Motion follows reading direction. In an Arabic interface "next" sits to the left, so:

• Forward navigation: the new screen enters from the left and the current one exits to the right; going back reverses this.
• Side menus: slide in from the start edge, which is the right.
• Carousels, steppers and progress bars: advance from right to left, and swipe gestures flip accordingly.
• Directional icons: back and forward arrows are mirrored.
• Usually not mirrored: circular loaders that imitate a clock's rotation, media playback controls and logos. When in doubt, follow the bidirectional guidelines of the platform you are building for.

In CSS, logical properties such as margin-inline-start flip layout automatically, but translate values inside transform do not, which is why the drawer in the example above needs its own right-to-left rule. Lottie animations with an obvious direction need a mirrored version, or a horizontal flip if they contain no text. Building for both languages is covered in building a bilingual Arabic and English website.

Common mistakes

• Animating everything for decoration until motion means nothing.
• Long entrance animations on every section as the user scrolls, making the page feel slow and tiring.
• Durations and curves that vary randomly from screen to screen.
• Animating layout properties instead of transform and opacity.
• Ignoring the reduced-motion preference.
• Copying English interface motion into Arabic without reversing its direction.
• A spinner that loops forever with no sign of progress or of an error.

Pre-launch checklist

1. Every animation has a clear job: feedback, orientation or continuity.
2. Durations sit within the guideline range, and the most frequent interactions are the fastest.
3. Entrances decelerate, exits accelerate, and linear motion is reserved for continuous movement.
4. Animation is limited to transform and opacity wherever possible, and tested on a mid-range phone.
5. The reduced-motion preference is respected, with no flashing and no long auto-playing motion without a pause option.
6. Direction of motion is tested in both the Arabic and English versions.
7. Durations and curves are documented as tokens in the design system.