# How to Choose the Right Easing Function for UI Animations: A Standards-Based Guide

> Master UI animation easing with custom cubic bezier curves. Leverage design system tokens and avoid ease-in for interactive elements. Optimize your animations today.

- Repository: [Emil Kowalski/skills](https://github.com/emilkowalski/skills)
- Tags: how-to-guide
- Published: 2026-07-28

---

**Choose custom cubic-bezier curves over built-in CSS keywords by referencing standardized tokens from your design system, while strictly avoiding `ease-in` for interactive UI elements.**

Selecting the appropriate easing curve determines whether your interface feels responsive or sluggish. According to the `emilkowalski/skills` repository, treating easing as a first-class design decision requires moving beyond default CSS keywords toward custom cubic-bezier standards. The repository's skill-based architecture provides concrete files that define tokens, audit rules, and vocabulary for making these choices systematically.

## Why Built-in CSS Easings Fall Short

The design rationale in [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) explains why builtin CSS easings are considered "too weak" for production interfaces. Default keywords like `ease`, `ease-in-out`, or `linear` lack the physicality and brand-specific character required for modern motion design. Instead of accepting these generic defaults, the skill mandates that **custom cubic-bezier curves should be the default** for all component animations, giving designers precise control over acceleration and deceleration phases.

## Standardized Tokens for Consistent Motion

The [`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md) file establishes a constrained vocabulary of motion values that every component must reference. This document lists the accepted easing tokens, duration scales, and spring configurations that prevent arbitrary timing decisions. By centralizing these definitions, the repository ensures that a "quick" animation in one component matches the "quick" animation in another, eliminating the fragmented timing that occurs when developers define values ad-hoc.

### Example Token Implementation

Rather than hardcoding cubic-bezier values, reference your standardized tokens:

```css
/* Instead of arbitrary values */
.element {
  transition: transform 200ms ease-in-out;
}

/* Use standardized tokens */
.element {
  transition: transform var(--duration-fast) var(--ease-out-expo);
}

```

```javascript
// Spring configuration from standards
const springConfig = {
  stiffness: 300,
  damping: 30,
  mass: 1
};

```

## Auditing Easing Decisions

The [`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md) file provides a decision order for selecting easing curves and flags specific anti-patterns. Most critically, the audit identifies **`ease-in` on UI elements as a guaranteed finding**—meaning it will always be flagged during code review. This curve accelerates from zero velocity, creating a perception of lag or unresponsiveness that contradicts the immediate feedback users expect from interactive elements.

## Mastering Animation Vocabulary

Precise communication requires shared terminology, defined in [`skills/animation-vocabulary/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/animation-vocabulary/SKILL.md). This skill establishes definitions for terms like **cubic-bezier** (mathematical curves defining acceleration) and **asymmetric easing** (different acceleration/deceleration rates). Using this vocabulary allows teams to discuss why a specific curve feels "heavy" or "snappy" without relying on subjective descriptions.

## Summary

- **Avoid CSS defaults**: The `emil-design-eng` skill explicitly rejects built-in keywords like `ease` as insufficient for production UI.
- **Reference tokens**: Use the standardized easing tokens and duration scales defined in [`review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/review-animations/STANDARDS.md) to maintain consistency.
- **Ban ease-in**: The `improve-animations` audit treats `ease-in` on interactive elements as a critical violation due to perceived latency.
- **Use precise terms**: Refer to [`animation-vocabulary/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/animation-vocabulary/SKILL.md) to discuss cubic-bezier curves and asymmetric easing accurately.

## Frequently Asked Questions

### Why are CSS default easings considered insufficient for modern UI?

Builtin CSS easings like `ease` or `linear` are too generic and lack the physicality required for responsive interfaces. According to [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md), these defaults are "too weak" and should be replaced with custom cubic-bezier curves that provide specific acceleration characteristics matching your design system's motion language.

### What makes `ease-in` problematic for UI animations?

`ease-in` starts slowly and accelerates, creating a perception of lag or unresponsiveness. The [`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md) file flags `ease-in` on UI elements as a guaranteed finding because it violates the principle of immediate feedback—users expect interactive elements to respond instantly to input, not to hesitate before moving.

### How do standardized tokens improve animation consistency?

The [`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md) file defines accepted easing tokens and duration scales that all components must reference. This prevents developers from choosing arbitrary values and ensures that motion feels cohesive across the entire application, with standardized springs and cubic-bezier curves that share the same physical properties.

### When should I use spring configurations instead of cubic-bezier curves?

Spring configurations are ideal for interruptible, physics-based animations that need to maintain momentum when destinations change mid-animation. According to the standards in [`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md), use springs for gesture-based interactions or draggable elements, while using predefined cubic-bezier tokens for simpler state transitions like hover effects or modal entrances.