Animación y microinteracciones
Animar no es mover cosas, es comunicar cambio
La animación en interfaces no existe para impresionar. Existe para explicar transiciones de estado. Una buena animación responde a una pregunta concreta:
- ¿Qué acaba de pasar?
- ¿Por qué cambió esto?
- ¿Dónde debo mirar ahora?
Si una animación no aclara algo, añade ruido.
Microinteracciones: el nivel donde se gana o se pierde calidad
Una microinteracción es:
- Un hover que confirma interactividad
- Un focus que orienta
- Un cambio de estado que tranquiliza
- Una transición que evita saltos
No son “detalles”. Son feedback continuo. Interfaces sin microinteracciones:
- Parecen rotas aunque funcionen
- Generan incertidumbre
- Se sienten “baratas”
Animación como extensión del estado
Todo lo que se anima ya tenía un estado. Ejemplos:
closed → openinactive → activeidle → loadingenabled → disabled
La animación no crea el estado. Solo lo hace legible en el tiempo. Error común:
- Animar sin estado claro
- Usar animación como decoración independiente
Duración, easing y intención
Tres parámetros gobiernan cualquier animación útil:
- Duración: cuánto tarda
- Easing: cómo se mueve
- Retraso: cuándo empieza
Reglas prácticas:
- Rápido para feedback (< 150 ms)
- Medio para transición (150–300 ms)
- Lento solo para énfasis real (> 300 ms)
Cuanto más frecuente es la interacción, más corta debe ser la animación.
Menos propiedades, más claridad
No todo se anima bien. Propiedades seguras:
opacitytransformfilter(con cuidado)
Propiedades peligrosas:
width,heighttop,leftbox-shadowcomplejo
Estas últimas causan:
- Reflows
- Jank
- Inestabilidad visual
Una animación fluida es una animación barata para el navegador.
Tailwind y animación: utilidades, no coreografía
Tailwind no es un motor de animación. Es una herramienta para declarar transiciones simples.
Sirve para:
- Transiciones de hover
- Estados focus
- Cambios de opacidad
- Micro feedback inmediato
No sirve para:
- Secuencias complejas
- Coreografías largas
- Animaciones dependientes del tiempo
Tailwind cubre el 80% de microinteracciones. El 20% restante requiere herramientas específicas.
Animación y accesibilidad
Animar sin considerar accesibilidad es romper la interfaz para parte de los usuarios.
Puntos clave:
- Respetar
prefers-reduced-motion - No usar animación como único feedback
- Evitar flashes y movimientos bruscos
- No bloquear la interacción con animaciones largas
La mejor animación es la que puede apagarse sin romper nada.
Animaciones de entrada vs animaciones de interacción
Diferencia crítica:
- Entrada: aparece algo nuevo
- Interacción: respondes a una acción
Las animaciones de entrada:
- Deben ser discretas
- Ocurrir pocas veces
- No competir con el contenido
Las animaciones de interacción:
- Deben ser rápidas
- Repetibles
- Predecibles
Error habitual:
- Animar todo como si fuera una demo
Microinteracciones que sí aportan valor
Ejemplos útiles:
- Botón que “presiona” ligeramente al hacer click
- Campo que resalta suavemente al recibir foco
- Card que eleva sutilmente al hover
- Loader que confirma que algo está ocurriendo
Ejemplos problemáticos:
- Rebotes innecesarios
- Efectos elásticos exagerados
- Transiciones largas en acciones frecuentes
Estados animados y rendimiento
Cada animación:
- Consume recursos
- Compite con render y JS
- Puede degradar UX si se abusa
Buenas prácticas:
- Animar pocas cosas a la vez
- Cancelar animaciones cuando el estado cambia
- No encadenar animaciones sin razón
Señales de mala animación
- El usuario espera a que termine
- El contenido se vuelve secundario
- El layout “baila”
- El rendimiento cae en dispositivos modestos
- La UI se siente “juguete”
Errores frecuentes al empezar con animación
- Animar por moda
- Copiar efectos sin entender intención
- No medir duración
- Ignorar accesibilidad
- Usar animación para tapar problemas de UX