Animación funcional UI en 2026: el checklist antes de publicar

La animación funcional de la interfaz es movimiento que cumple una función: confirma una acción, muestra un cambio de estado, guía la atención de una zona de la pantalla a la siguiente. No es decoración, ni es un guiño de personalidad. Cuando el movimiento tiene una función, el usuario apenas lo nota. Cuando no la tiene, siente la fricción aunque no sepa nombrarla.

Este artículo es el checklist que aplicamos en cada producto que publicamos en 2026. Es opinado. Asume que ya sabes escribir una transición CSS y que tienes un design system donde meter el motion.

Por qué importa más en 2026 que en 2022

Tres cosas han cambiado.

Primero, el European Accessibility Act entró en vigor el 28 de junio de 2025, y el motion es uno de los hallazgos más frecuentes en las auditorías. Los trastornos vestibulares afectan a una franja relevante de la población adulta: alrededor del 35% de los adultos de 40 años o más ha sufrido alguna forma de disfunción vestibular. Las animaciones que escalan, hacen pan o parallax pueden provocar náuseas, mareos y dolores de cabeza a estos usuarios.

Segundo, la calm UI ya no es una postura de nicho. Apple, Atlassian e IBM han publicado guías de motion en los últimos 18 meses que reducen las duraciones por defecto y desplazan el movimiento expresivo a momentos puntuales. "Menos, pero mejor" se aplica.

Tercero, el presupuesto por frame no se ha vuelto más generoso. 60fps siguen siendo 16,66ms por frame. Las propiedades que el navegador anima barato (opacity, transform) son las mismas que hace cinco años. Las que cuestan layout o paint (width, height, top, left, margin, padding) siguen siendo caras. Nada nuevo. Se sigue ignorando.

Qué hacer

1. Duraciones cortas y contextuales

Material Design 3 fija 200ms como referencia para las transiciones a nivel de componente y 300ms para las transiciones entre pantallas. Las Human Interface Guidelines de Apple caen en el mismo rango. La regla que seguimos:

• Microinteracción (hover, focus, toggle): 100 a 200ms.
• Cambio de estado de componente (modal abriéndose, drawer, dropdown): 200 a 300ms.
• Transición de página completa: 300 a 500ms, solo si lleva significado.
• Por encima de 500ms debe justificarse.

Un movimiento que el usuario dispara treinta veces por sesión va por debajo de 150ms. Un movimiento que ve una sola vez necesita más aire para leerse.

2. El easing es un verbo, no una atmósfera

Cada curva de easing tiene una función:

• ease-out para los elementos que entran en pantalla. Empieza rápido, se asienta. Se siente reactivo.
• ease-in para los que salen. Empieza lento, acelera. El usuario ya ha decidido.
• ease-in-out para el movimiento entre dos estados del mismo elemento.
• linear solo para progresos indeterminados y movimiento continuo (spinners, loaders).

Deben vivir como tokens en el design system (--ds-easing-enter, --ds-easing-exit, --ds-easing-standard), nunca inline en el componente.

3. Animar solo opacity y transform

Las propiedades que compone la GPU se mantienen a 60fps porque se saltan layout y paint. La lista es corta: opacity, transform (translate, scale, rotate) y filter con cuidado. Usa transform: translateY() en vez de animar top o margin-top. Usa transform: scale() en vez de animar width y height. La diferencia aparece en un Android de gama media, no en el Mac con el que has construido la página.

4. Respetar prefers-reduced-motion en la raíz

El WCAG 2.1, criterio 2.3.3 exige que el motion disparado por interacción pueda desactivarse, salvo cuando es esencial. La respuesta mecánica es una regla en la hoja de estilos global:

@media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } }

Cubre la mayor parte del daño. Para parallax no esenciales, vídeos de fondo en autoplay y reveals con mucho escalado, añade además un guard en JavaScript con matchMedia('(prefers-reduced-motion: reduce)') antes de montar la animación. Llevar la duración a cero igualmente ejecuta el listener: no anula el trabajo JS.

5. Cada animación tiene que ser interrumpible

Si un usuario puede pulsar un botón, la animación que arranca tras la pulsación no debe bloquear la siguiente. Transiciones bloqueadas, modales que ignoran el escape durante la apertura, dropdowns que se niegan a cerrarse hasta que termina la apertura: son los casos más comunes. La corrección es estructural: el estado guía la animación, no al revés. Si el estado vuelve a cerrado a mitad de apertura, la animación debe revertirse desde el frame actual, no esperar.

6. Llevar el motion al design system como tokens

Los tokens de duración (--ds-motion-duration-fast, --ds-motion-duration-base, --ds-motion-duration-slow) y los de easing (--ds-motion-ease-out, --ds-motion-ease-in, --ds-motion-ease-standard) viven en el mismo nivel que el color y el espaciado. Atlassian, IBM Carbon y Material 3 publican su capa de tokens. Copia la estructura si tu design system no la tiene.

7. Animar para comunicar estado, no para entretener

Las tres funciones que el motion cumple legítimamente en una interfaz de producto:

• Feedback: confirmar la pulsación de un botón, el flip de un toggle, un guardado correcto.
• Continuidad: enseñar de dónde viene un nuevo elemento, para que el usuario no tenga que releer la pantalla.
• Jerarquía: llamar la atención sobre el único elemento que ha cambiado, y luego asentarse.

Si una animación propuesta no hace ninguna de las tres, fuera.

Qué no hacer

1. Parallax que se dispara en cada scroll

Fondo y primer plano moviéndose a velocidades distintas durante el scroll son el disparador vestibular más citado en las auditorías. Rara vez añade significado. Si el sitio de marketing insiste, ponlo detrás de prefers-reduced-motion: no-preference.

2. Animar width, height, top, left o margin

Disparan layout. El layout cuesta entre 6 y 14ms en dispositivos de gama media y se propaga a cada descendiente. Perderás frames. Usa transform.

3. Seis cosas animándose a la vez

Cuando más de dos o tres elementos se mueven a la vez, el usuario no distingue qué responde a su acción y qué se mueve por ambiente. Elige el único elemento que importa. Muévelo. Deja quieto el resto.

4. Spinners decorativos en acciones por debajo de 300ms

Si la acción termina en 150ms, el spinner añade latencia, no tranquilidad. Renderiza directamente el estado de éxito. Reserva los spinners para operaciones que de verdad tardan, y para cualquier cosa por encima del segundo prefiere un skeleton o una progress bar inline.

5. Scale o pan con autoplay en el hero al hacer scroll

Los reveals cinematográficos en la primera visita parecen pieza de portfolio, no producto. Y fallan WCAG 2.3.3 si no los proteges. La relación coste-beneficio es mala: 100ms de wow percibido para la pequeña porción de usuarios no afectados, y molestia física para el resto.

6. Curvas de easing custom que no encajan con el sistema

Un cubic-bezier(0.4, 0.0, 0.2, 1) en un componente y otro en el componente vecino es la manera en que un producto empieza a sentirse "raro" sin que nadie sepa señalar la causa. Usa las mismas tres o cuatro curvas en todas partes.

7. Motion que no puedes apagar en desarrollo

Si el equipo no puede desactivar las animaciones mientras depura un componente, esa animación estorba en cada prueba de teclado, en cada diff de capturas y en cada auditoría de accesibilidad. Añade un flag a nivel raíz (variable de entorno, query param o toggle en DevTools) que apague el motion en todo el sitio. Lo usarás cada semana.

El resumen

• Duración de microinteracción: 100 a 200ms.
• Cambio de estado de componente: 200 a 300ms (rango Material 3 y HIG).
• Transición de página: 300 a 500ms, solo si lleva significado.
• Easing en entrada: ease-out. Se siente reactivo.
• Easing en salida: ease-in. El usuario ya ha decidido.
• Propiedades a animar: solo opacity y transform.
• prefers-reduced-motion: respetada en la raíz, con un guard JS para el motion pesado.
• Interrumpibilidad: siempre. El estado guía la animación, no al revés.

Lee esta lista con un ingeniero senior antes del primer sprint de cualquier producto. Los bugs de motion que aparecen luego son casi siempre los puntos saltados aquí.

En el blog: Calm UI en 2026: el giro que deja atrás las acrobacias de animación y Diseño accessibility-first tras el European Accessibility Act.