Figma Motion: Designers 🤝 Devs, finally.

Desde el 24 de junio de 2026 una animación en Figma vive en el mismo archivo que el diseño, sobre un timeline que cualquiera puede abrir, comentar y reutilizar. Ese es el cambio que importa: una animación ahora se puede revisar antes de salir, en vez de discutirse después. Cualquier frame se pasa a modo Motion, y desarrollo abre ese archivo y copia la animación como CSS, JSON o React.

Qué es lo nuevo

Motion es otra vista del mismo archivo, al lado de Design y Dev Mode. Pasás un frame y aparece el timeline, donde ponés keyframes: un keyframe es un punto marcado en el tiempo con un valor asociado, así que dos keyframes de opacidad dicen "acá invisible, acá visible, resolvé el medio". Figma anima posición, escala, rotación y opacidad, y los comentarios son por tiempo: quien revisa marca un momento y no escribe "el medio se siente lento".

Lo que lo vuelve un sistema y no una función pasa por encima del frame suelto. Los componentes animados ahora llevan su movimiento: armás la animación una vez y, en palabras de Figma, "viaja con ese componente por cada pantalla y cada archivo de tus colaboradores, igual que el relleno y la tipografía". Arriba están las variables de motion con modos. Una variable es un valor con nombre al que el archivo apunta en lugar de un número suelto, y un modo es un juego alternativo de esos valores, como el tema claro y oscuro. Definís un segundo modo para una variable de easing, lo cambiás a nivel de página y todas las animaciones que la referencian cambian de una.

El diagnóstico de la propia Figma es poco habitual en un anuncio: "el movimiento se rehace desde cero cada sprint, y lo que sale refleja quién tuvo tiempo, no lo que se diseñó". Leelo con la salvedad de que es Figma describiendo un producto de Figma, y de que las voces de clientes las eligió Figma. Igual da en el clavo: el movimiento es la única parte de una interfaz que nunca tuvo un archivo que valiera como respuesta.

Qué recibe quien programa

En Dev Mode, la vista que Figma le da a desarrollo para inspeccionar un diseño, hay una pestaña Motion que muestra el timeline completo y copia la animación como CSS, JSON, o React y motion.dev. Figma afirma que "cada valor de tiempo, curva de easing y keyframe es legible sin que el desarrollador tenga que interpretar nada". El easing es la curva que decide cómo un movimiento acelera y frena, y es uno de los detalles que, según Figma, se pierden en la traducción entre el archivo y el código. Lo mismo viaja por el servidor MCP de Figma, el conector que le pasa a un agente de código datos estructurados y no una captura, del que ya escribimos cuando Figma midió qué le hacen los componentes conectados al código.

Dos límites van pegados a esa promesa de handoff. Motion está en beta abierta, cosa que Figma aclara en su documentación de handoff: puede cambiar y andar lento. Y el handoff es la mitad paga: las cuentas Starter exportan limitado, y copiar el código pide un plan pago con asiento Full o Dev.

El modo que el anuncio nunca nombra

Hay un modo que importa más que cualquier easing de marca, y ni el anuncio ni la documentación lo nombran. prefers-reduced-motion es una media feature de CSS que, según MDN, detecta si una persona activó en su dispositivo una preferencia para minimizar el movimiento no esencial. Nadie la activa en tu sitio: la activa una vez, en macOS, Windows, iOS o Android, y todas las páginas deberían respetarla.

Media web ya la escucha. El Web Almanac 2025, que analiza el rastreo de 17 millones de sitios del HTTP Archive, encontró prefers-reduced-motion en el 49,99% de las páginas de escritorio y en el 50,55% de las móviles, la preferencia más usada de la web, con "poco cambio" respecto de 2024. Ese número mide una cosa: que la consulta existe en el CSS. No dice si alguien decidió qué va adentro, y nuestra lectura es que ahí está el agujero: la bifurcación ya está escrita, esperando un valor que nunca nadie pidió.

La razón para definir ese valor no es cumplir una norma. El criterio 2.3.3 de las WCAG 2.2 pide que la animación disparada por una interacción se pueda desactivar, salvo que sea esencial para la funcionalidad o para la información que transmite, y es de nivel AAA, el más alto de los tres niveles de conformidad. Nuestra lectura es que ahí está el punto: el movimiento reducido no llega por una auditoría, así que llega como decisión de diseño o no llega. Lo que llega igual es el efecto que el W3C describe en esa misma página. En personas con trastornos vestibulares, afecciones del oído interno que afectan el equilibrio, la animación puede provocar náuseas, migrañas y hasta la necesidad de guardar cama para recuperarse.

Qué pedir en la próxima revisión

Nuestra posición, y es posición, no hallazgo: el mecanismo que Figma sacó para la consistencia de marca es el que el movimiento reducido necesitó siempre. Una variable de motion con dos modos, completo y reducido, deja la decisión en el archivo donde la toma quien diseña, y no en un bloque @media que desarrollo escribe al final del sprint sin nada con qué comparar. Nada sugiere que Figma vaya a generarte esa bifurcación: es una convención que adopta un equipo, no una opción que se activa.

Una variable de dos modos también vuelve contestable la pregunta de revisión. Hasta junio, preguntar cómo se ve una pantalla para alguien que pidió menos movimiento daba una opinión. Ahora devuelve un modo en el archivo, o la admisión de que nadie decidió.

Lo que hay que mirar en seis meses no es la adopción del timeline, porque lo van a adoptar. Es si el código exportado se lleva la bifurcación. Hoy Figma exporta la animación que diseñaste. Si dentro de un año exporta esa animación más la media query que la apaga, el movimiento pasa a ser la primera propiedad de diseño que sale con su default de accesibilidad puesto. Si no, sigue siendo algo que cada equipo decide o se saltea sin darse cuenta.

Fuentes