Cómo convertir variables de Figma a Tailwind CSS paso a paso

¿Cómo convertir variables de Figma a Tailwind CSS? Crea una asignación explícita: resuelve el valor y el modo de Figma, dale un nombre CSS semántico, expón la utilidad Tailwind prevista y pruébala en navegador. Figma no sincroniza automáticamente todas las variables con la configuración del proyecto.

Asigna variables de Figma a roles de Tailwind

Empieza clasificando los valores por lo que significan en el producto. Una primitiva como blue/600 describe un tono de paleta. Una variable semántica como action/primary describe un rol. El código debería pedir el rol —«acción principal»— en lugar de un número de azul. Esta capa facilita revisar un cambio de marca o contraste más adelante.

Figma admite variables de color, número, texto y booleanas. Las colecciones agrupan variables y modos, y las variables pueden usar otras del mismo tipo como alias. Esto convierte Figma en una fuente útil para el mapa, pero el equipo todavía decide cómo traducir los nombres a CSS y Tailwind. La guía de Figma sobre variables, colecciones y modos explica el modelo. El formato del Design Tokens Community Group describe tokens como valores con nombre y metadatos o relaciones opcionales.

Para el color de un botón, una asignación sencilla podría ser:

Figma: color/blue/600       = #4f46e5
Figma: action/primary       = alias de color/blue/600
CSS:   --color-action       = #4f46e5
Tailwind v4: bg-action       = background-color: var(--color-action)

La última clase es útil porque expresa intención. Si el código solo usa bg-blue-600, queda ligado al nombre de la paleta. Puede servir para mostrar colores, pero suele ser una mala opción predeterminada para componentes de producción basados en roles semánticos. «Acción principal» debería seguir siendo reconocible aunque cambie el azul subyacente.

Antes de tocar el código, prepara una tabla con cuatro columnas: ruta de variable en Figma, valor resuelto, tipo o unidad y nombre CSS/Tailwind de destino. Añade colección y modo cuando corresponda. Por ejemplo, action/primary podría ser #4f46e5 en modo claro y otro valor aprobado en modo oscuro, conservando un nombre CSS.

Usa con intención el alcance y los nombres de variable. Un alias de color debe resolver a un color. Un número de espaciado necesita una convención de unidad conocida. Un valor de tamaño tipográfico aislado no equivale a un estilo de texto completo. Si el sistema separa primitivas, semántica y decisiones específicas de componente, no lo aplanes en una lista única. Conserva las capas que faciliten cambiar decisiones reales.

Prepara una fuente fiable desde Figma

Antes de definir valores Tailwind, establece cómo salen los datos de Figma. Una tabla mantenida cuidadosamente basta para una colección pequeña. En una biblioteca grande, usa una exportación o flujo API aprobado y revisa el resultado. La guía para gestionar variables de Figma cubre colecciones, alcance, alias y modos. La documentación de variables en Dev Mode describe el contexto que pueden inspeccionar los desarrolladores.

Una captura, un hexadecimal copiado o el nombre de la variable no constituyen una exportación completa. Necesitas valor resuelto, tipo, relación de alias y modo seleccionado. Si escribes un script, define cómo trata alias, tipos incompatibles, nombres duplicados, valores ausentes y diferencias entre modos. Debe fallar de forma visible cuando una entrada no se pueda representar; no debería producir en silencio un valor aparentemente válido pero incorrecto.

Conserva la trazabilidad. Incluye el archivo o colección de Figma, la fecha o revisión de exportación y una clave estable en el artefacto o la documentación cercana. Quien revise debería poder responder qué variable originó una propiedad CSS, qué modo aportó el valor y qué hacer cuando cambie la fuente. Así varias personas de diseño y desarrollo pueden mantener la biblioteca y resolver discrepancias.

Las rutas de variable suelen separar grupos con barras, por ejemplo color / text / primary. Las propiedades personalizadas CSS suelen usar guiones. Decide si el conversor reemplaza barras por guiones, elimina grupos internos de implementación o conserva los alias mediante referencias. Aplica una regla uniforme. Las excepciones por componente hacen más difícil recorrer la capa de tokens y luego migrarla.

La traducción también identifica valores que Tailwind no puede utilizar directamente. Un número de Figma podría ser una proporción de interlineado, una duración en milisegundos o un valor de espaciado. El número no indica la propiedad ni unidad CSS. Registra ambas y prueba el valor en contexto. Una variable de color puede convertirse en un color. El radio de un componente puede ser una propiedad CSS o utilizar el espacio de radios de Tailwind. Es una decisión documentada, no una inferencia del número.

Define variables de tema para tu versión de Tailwind

Tailwind CSS v4 documenta una API CSS-first con la directiva @theme. Las variables de tema definen propiedades y utilidades. La documentación de variables de tema explica los espacios de nombres, y la guía de personalización de colores cubre colores propios. Un inicio pequeño sería:

@import "tailwindcss";
@theme {
--color-action: #4f46e5;
--color-surface: #ffffff;
--color-text: #172033;
--spacing-control: 0.75rem;
--radius-control: 0.5rem;
}

Son nombres de ejemplo, no los genera Figma. En v4, una variable de color puede exponer utilidades como bg-action, text-text y utilidades de color de borde. Los espacios de espaciado y radio también ofrecen clases basadas en el tema. Comprueba con una compilación pequeña la clase que genera tu versión. El propósito de cada propiedad CSS debe leerse con facilidad; evita nombrar una superficie semántica por su hexadecimal provisional.

A algunos equipos les conviene mantener una capa separada de tokens de diseño y referenciarla desde el tema Tailwind:

:root {
--ds-action-primary: #4f46e5;
--ds-surface-default: #ffffff;
}
@theme inline {
--color-action: var(--ds-action-primary);
--color-surface: var(--ds-surface-default);
}

Usa el patrón solo si encaja con la versión instalada y el flujo de compilación; compruébalo en documentación oficial y en el CSS resultante. Separar los nombres del sistema de diseño de los nombres de utilidad puede ayudar si otros estilos también consumen los tokens. Un proyecto pequeño quizá sea más claro con un único conjunto. No añadas otra abstracción solo para imitar un diagrama de arquitectura.

Los proyectos Tailwind v3 suelen declarar valores en tailwind.config.js o en un archivo TypeScript. La estructura y forma de extensión difieren del modelo CSS-first de v4. No pegues un bloque @theme en v3 y esperes que genere clases. Comprueba primero package.json, el lockfile, la integración y la documentación de esa versión. En una migración, conserva la configuración actual y mueve una categoría cada vez; compara el CSS compilado y los componentes renderizados.

Si estás evaluando EmviUI, su introducción práctica a los tokens de diseño explica los nombres y la capa semántica. Aquí añadimos el puente de implementación: parte de ese modelo, decide cómo se asigna a Tailwind y prueba la API de utilidades de la aplicación. EmviUI no hace esta asignación para tu repositorio; el proyecto sigue siendo responsable de nombres y compilación.

Usa modos de Figma como contextos de tema

Un modo de Figma es un conjunto de valores para variables de una colección; el contexto de diseño usa uno de esos modos. La declaración de tema Tailwind ofrece valores y nombres de utilidad, pero no decide qué modo debe activar la aplicación según la preferencia de la persona. Mantén separadas ambas responsabilidades.

En una interfaz clara y oscura, conserva la propiedad personalizada semántica y cambia su valor en el selector o mecanismo de tema correspondiente. Por ejemplo:

:root {
--ds-surface-default: #ffffff;
--ds-text-primary: #172033;
}
[data-theme="dark"] {
--ds-surface-default: #172033;
--ds-text-primary: #f5f6fa;
}

Las utilidades Tailwind pueden referenciar nombres estables mientras la aplicación selecciona el contexto con un atributo o una clase. Si el proyecto emplea utilidades de modo oscuro, sigue la convención y confirma que el estado se aplica en el antecesor correcto. Lo importante es que el mismo rol semántico se resuelva de forma previsible en Figma y producción.

No conviertas mecánicamente cada modo de Figma en una media query. Los modos pueden representar marca, densidad, plataforma, idioma u otros contextos, y no todos son temas que la persona usuaria selecciona en tiempo de ejecución. Un modo de espaciado de escritorio no define automáticamente un breakpoint CSS. Un modo de campaña puede pertenecer a otra marca. Identifica la condición del producto y elige un selector, clase, propiedad de componente o salida de compilación apropiados.

Comprueba texto, bordes, iconos, gráficos, controles desactivados e indicadores de foco en cada tema. Una superficie puede verse bien mientras el texto secundario pierde legibilidad. Los nombres semánticos dicen para qué sirve el valor, pero una persona tiene que revisar contraste e interacción. Ejecuta verificaciones de accesibilidad sobre combinaciones renderizadas en lugar de confiar en la etiqueta.

Si un modo modifica composición o espaciado, prueba anchuras reales con contenido representativo. Los breakpoints CSS son decisiones de implementación. Los modos de Figma ayudan a modelar contextos, pero no definen automáticamente el comportamiento adaptable del navegador. Relaciona la traducción de tokens con la estrategia responsive del proyecto. Un token puede informar un valor sin decidir cuándo debe cambiar la distribución.

En una revisión útil se pregunta qué ocurre cuando el texto es más largo, el control está desactivado o la persona cambia de tema. Diseña pantallas representativas en Figma y compara los mismos estados en navegador. Si un modo cambia una superficie semántica en diseño pero afecta a tres clases CSS inconexas, el mapa quizá sea demasiado indirecto o el código no refleje la intención.

Valida la asignación antes de publicarla

Tras editar el tema, ejecuta la compilación habitual y crea un componente pequeño con las clases previstas. Aplica bg-action, text-text y una utilidad de espaciado a un botón o tarjeta. Inspecciona el CSS o elemento renderizado para confirmar que Tailwind encontró la clase, emitió la regla esperada y resolvió la propiedad personalizada. Que el nombre parezca plausible no demuestra que exista la utilidad.

Compara un valor en cada capa: modo seleccionado en Figma, variable resuelta, propiedad CSS, variable de tema Tailwind, estilo calculado y componente visible. Comprueba si el alias se aplanó o se conservó como referencia. Ambas opciones pueden ser válidas, pero el flujo de cambios es distinto. Si el alias debe seguir al valor de origen, regenera y prueba después de cambiar una primitiva. Si la salida es una instantánea, documéntalo y actualízala cuando cambie la fuente.

Prepara una tabla breve de aceptación para la primera migración: los colores coinciden en ambos temas; el espaciado y los radios usan las unidades previstas; se compilan las utilidades esperadas; no quedan clases retiradas; se muestran los estados de foco, desactivado, hover y error; y una pantalla representativa no se desborda. Conserva algunas pantallas para comparar. No evalúes el éxito solo porque el analizador CSS acepte el tema.

Haz visibles los fallos. Una variable ausente debería causar un error de compilación o validación, no caer silenciosamente en otro rol semántico. Señala propiedades CSS duplicadas. Enumera para revisión los tipos de Figma no compatibles. Cuando cambie un valor, quien revise debe distinguir una actualización segura de una primitiva de un cambio en el significado de un rol semántico. Ajusta la comprobación al tamaño: para un piloto basta una lista corta; un sistema grande puede necesitar diferencias automatizadas y revisión explícita de cambios delicados.

La automatización ayuda con la extracción, normalización, generación de archivos y comparación. Mantén revisables las decisiones del mapa. Un script puede transformar color/action/primary en --color-action siguiendo una regla declarada; no puede inferir con fiabilidad si dos valores parecidos significan lo mismo en tu producto. El formato del Design Tokens Community Group busca facilitar la interoperabilidad, pero cada integración necesita su propio flujo. Versiona el conversor y sus reglas junto al sistema de diseño.

Para ver el proceso de implementación, consulta el flujo de Figma a Tailwind para React adaptable. Para los fundamentos visuales, el plan para crear un kit mantenible muestra cómo un conjunto compacto de componentes puede consumir decisiones consistentes. La conversión funciona cuando diseño reconoce los roles de origen, desarrollo usa las utilidades previstas y el producto representa esos valores en sus contextos compatibles.

Dónde encaja EmviUI en este flujo

EmviUI sirve de referencia para estudiar patrones reutilizables y componentes coherentes mientras construyes un producto con Tailwind. No importa colecciones de Figma, no genera el tema Tailwind del proyecto ni sincroniza cambios de tokens. Trata sus ejemplos y su kit como referencias de implementación, no como prueba de que el mapa ya está preparado en tu repositorio.

Un piloto práctico consiste en elegir una interfaz que vayas a crear —un formulario de ajustes, una página de perfil o un panel de dashboard— y preparar un mapa corto de color, espaciado, radio y tipografía. Compara los roles de Figma con las clases que necesita cada componente. Si un ejemplo de EmviUI ayuda a entender el patrón, adáptalo a tus nombres y pruébalo con tu versión real de Tailwind. Mantén clara la diferencia entre una decisión semántica del producto y su valor visual actual.

El piloto permite medir el resultado. Diseño debería cambiar un valor semántico y ver actualizarse el contexto previsto. Desarrollo debería encontrar una clase basada en el rol sin memorizar números de paleta. Quien revisa el código debería rastrear el componente hasta Figma y detectar estados ausentes. Si el mapa complica estas tareas, simplifícalo antes de ampliarlo a cientos de variables. Un mapa breve y fiable supera a una exportación extensa que nadie puede mantener con seguridad.

Preguntas frecuentes