# Why You Should Never Use Ease-In for UI Animations

> Avoid ease-in for UI animations. Discover why this timing function creates sluggish interfaces and harms user experience. Learn to create responsive and fluid designs.

- Repository: [Emil Kowalski/skills](https://github.com/emilkowalski/skills)
- Tags: best-practices
- Published: 2026-08-08

---

**Never use `ease-in` for UI animations because it delays the initial movement, making interfaces feel sluggish and unresponsive at the exact moment users expect immediate visual feedback.**

The `emilkowalski/skills` repository establishes strict animation standards that explicitly forbid using `ease-in` for interface transitions. Understanding why you should never use `ease-in` for UI animations is critical for building responsive, modern web applications that feel instantaneous rather than sluggish.

## The UX Problem with Ease-In

### Delayed Initial Movement Destroys Responsiveness

`ease-in` curves start motion slowly and only accelerate after a delay. In UI interactions, the moment the user is watching is **right at the beginning** of the animation. Delaying that initial movement makes the interface feel broken and laggy, even if the total duration is short.

According to [`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md), the rule is explicit: **Never `ease-in` on UI** – it starts slow, delaying the exact moment the user is watching.

### Perceived Speed vs. Actual Speed

Perceived responsiveness matters more than actual duration. A 200 ms `ease-out` animation *feels* faster than a 200 ms `ease-in` because the user sees movement immediately. The [`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md) file flags `ease-in` as a critical finding that makes dropdowns and tooltips feel sluggish, requiring immediate replacement with `ease-out` or custom cubic-bezier curves.

## Recommended Alternatives to Ease-In

### Ease-Out for Immediate Feedback

Replace `ease-in` with `ease-out`, which begins instantly and decelerates naturally. This provides immediate visual confirmation while maintaining a polished finish. The repository provides the `--ease-out` token for consistent implementation across all components.

### Strong Custom Cubic-Bezier Curves

For greater control over entrances, use strong custom cubic-bezier curves like `cubic-bezier(0.23, 1, 0.32, 1)` that preserve the instant start while providing sophisticated deceleration. The [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) guidelines recommend these curves specifically to avoid the "sluggish" feel of delayed motion in dropdowns, modals, and toasts.

## Code Implementation Examples

The [`skills/animate/RECIPES.md`](https://github.com/emilkowalski/skills/blob/main/skills/animate/RECIPES.md) file provides concrete CSS implementations using the repository's animation vocabulary.

### Basic Button Transition with --ease-out

```css
.button {
  transition: background-color 150ms var(--ease-out), 
              transform 150ms var(--ease-out);
}

.button:hover {
  background-color: #0069d9;
  transform: translateY(-2px);
}

```

This ensures the hover state responds immediately to user input, with the motion easing out rather than ramping up.

### Modal Entrance with Custom Curve

```css
:root {
  --custom-enter: cubic-bezier(0.23, 1, 0.32, 1);
}

.modal {
  opacity: 0;
  transform: scale(0.95);
  transition: opacity 200ms var(--custom-enter),
              transform 200ms var(--custom-enter);
}

.modal[data-open] {
  opacity: 1;
  transform: scale(1);
}

```

The curve mimics `ease-out` behavior with a fast start and gentle finish, avoiding the perception of lag when the modal appears.

### On-Screen Movement with --ease-in-out

```css
.card {
  transition: transform 300ms var(--ease-in-out);
}

.card.move {
  transform: translateX(200px);
}

```

The `--ease-in-out` token (`cubic-bezier(0.77, 0, 0.175, 1)`) is suitable for elements already visible that move across the screen, but should never be used for initial entrances where `ease-out` is required.

## Repository Standards and Source Files

The `emilkowalski/skills` repository enforces these animation rules across multiple documentation files:

- **[`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md)**: Defines the "Never `ease-in` on UI" rule and provides the default animation tokens.
- **[`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md)**: Contains the detailed design rationale stating "Never use `ease-in` for UI animations" and mandates `ease-out` for all entrance transitions.
- **[`skills/animate/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/animate/SKILL.md)**: Lists common misuse patterns including `ease-in` on UI elements and provides recommended replacements.
- **[`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md)**: Provides audit guidance for hunting down `ease-in` usages and swapping them for responsive alternatives.

## Summary

- **Never apply `ease-in`** to UI animations where users expect immediate feedback, as the delayed start creates perceived lag and breaks responsiveness.
- **Use `ease-out`** or the repository's `--ease-out` token to ensure animations begin instantly and decelerate naturally.
- **Implement strong cubic-bezier curves** like `cubic-bezier(0.23, 1, 0.32, 1)` for polished entrances that maintain the critical instant-start behavior.
- **Reference [`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md)** and related files to ensure compliance with the repository's animation vocabulary and UX standards.

## Frequently Asked Questions

### What makes ease-in feel sluggish compared to ease-out?

`ease-in` accelerates from zero velocity, meaning the animation starts with imperceptible movement that users interpret as interface lag. In contrast, `ease-out` begins at full velocity and decelerates, providing immediate visual feedback that makes the interface feel snappy and responsive according to the source code standards.

### When is it acceptable to use ease-in in web development?

While the `emilkowalski/skills` repository strictly forbids `ease-in` for UI animations, it may be appropriate for elements exiting the screen or non-interactive ambient animations where the user is not waiting for the motion to initiate. However, for buttons, dropdowns, tooltips, and modals, always avoid `ease-in` to prevent breaking the interaction flow.

### How do I audit existing code for ease-in violations?

According to [`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md), search your codebase for CSS `transition-timing-function: ease-in` or `animation-timing-function: ease-in` declarations. Replace these with `var(--ease-out)` or `cubic-bezier(0.23, 1, 0.32, 1)` for entrance animations, and verify the changes against the repository's animation review standards.

### What is the difference between the repository's --ease-out and --ease-in-out tokens?

The `--ease-out` token provides immediate starting velocity with a gentle deceleration, perfect for UI entrances where users need instant feedback. The `--ease-in-out` token (set to `cubic-bezier(0.77, 0, 0.175, 1)`) accelerates and decelerates symmetrically, suitable only for on-screen movement where the element is already visible and transitioning between states, not for initial appearances.