De Figma a CSS: guía práctica de conversión

Respuesta rápida: convertir Figma a CSS plano significa traducir Auto Layout a Flexbox, resolver cada valor de relleno/espaciado/tipografía a su número real en lugar de una aproximación con clases de utilidad, y mantener el resultado libre de dependencias. Es el objetivo correcto cuando quieres control total sobre cada regla y ningún framework que aprender, instalar ni sobrescribir más adelante.

Por qué elegir CSS plano en lugar de un framework

Todos los formatos de salida que soporta MarkupGen —CSS puro, Tailwind, Bootstrap, Bulma— parten de la misma fuente: la estructura y los valores reales del frame de Figma. El CSS plano es simplemente el formato sin nada entre tu archivo y el navegador:

• No hay ninguna convención de nombres de clases que aprender. La escala de utilidades de Tailwind y las clases de componentes de Bootstrap son potentes, pero siguen siendo un sistema que hay que interiorizar. El CSS plano solo necesita conocer CSS.
• Sin peso de framework. Incluso con purga de clases sin usar, un framework añade un paso de build y una dependencia que mantener actualizada. Una exportación de CSS puro no tiene ninguna de las dos cosas.
• Cada regla es editable directamente. Cambiar un valor de espaciado significa editar una sola declaración, no buscar qué clase de utilidad corresponde al valor en píxeles que quieres.

La contrapartida es la misma que Tailwind existe para resolver: sin un framework que imponga una escala, los valores de espaciado y color pueden volverse inconsistentes en un codebase que crece, si nadie es disciplinado reutilizando los mismos números. Para una landing page o un sitio pequeño, rara vez es un problema. Para un producto grande con muchos colaboradores, vale la pena leer Vanilla CSS vs Bootstrap vs Tailwind antes de decidir.

Qué hay que convertir realmente

Un frame de Figma tiene más estructura de la que parece a simple vista, y cada pieza se corresponde con una parte específica del CSS:

Nada de esto es exótico: es la misma correspondencia que hace un desarrollador a mano al reconstruir un diseño píxel a píxel. La diferencia es hacerlo a partir de la estructura y los valores reales del frame en lugar de calcular a ojo desde una captura de pantalla.

Cómo genera MarkupGen el CSS

El flujo de trabajo son los mismos cuatro pasos sin importar el formato de salida: exportas el frame desde Figma con el plugin de MarkupGen, que captura la estructura, los estilos y las imágenes juntos; la IA construye el markup a partir de esa estructura real en lugar de aproximar una imagen; refinas contenido, fuentes o layout en el editor integrado si algo necesita un ajuste; exportas el paquete final.

Para el CSS plano en concreto, eso significa que la hoja de estilos generada usa los valores reales de color y espaciado del frame en lugar de ajustarlos a la escala predefinida de un framework — un relleno fijado en #3B82F6 sale exactamente así, no el azul de Tailwind más cercano. Auto Layout se mapea automáticamente a una estructura Flexbox (consulta Auto Layout to CSS para el desglose completo propiedad por propiedad), y el comportamiento responsive se genera a partir de las restricciones de redimensionado del frame en lugar de añadirse como un paso manual aparte. El HTML de salida prioriza elementos semánticos frente a <div> anidados por defecto, algo que importa tanto para el mantenimiento como para la accesibilidad y el SEO.

Convertir las variables de Figma en custom properties de CSS

Las variables de Figma (colores, tipografía, espaciado, radio, efectos) son lo más parecido a un sistema de diseño que tiene un archivo de diseño, y se corresponden conceptualmente con las custom properties de CSS — un bloque :root de pares --nombre: valor que cualquier regla de la hoja de estilos puede referenciar. Como se ha señalado antes, hoy en día la salida CSS de MarkupGen resuelve cada propiedad a su valor literal por elemento en lugar de emitir automáticamente esa capa de variables :root, así que construir la correspondencia es un paso manual. Aun así, es un paso mecánico en cuanto conoces el patrón:

Una convención de nombres que vale la pena mantener: reflejar la propia estructura de grupo/nombre de la variable de Figma (color/primary → --color-primary) en lugar de inventar una paralela, para que ambas sigan siendo fáciles de cotejar a medida que el diseño evoluciona. Una vez que las variables existen como custom properties, sustituye los valores literales generados por referencias var(--color-primary) en el CSS exportado.

Dos limitaciones que conviene conocer antes de apoyarte en esto: no toda variable de Figma se corresponde limpiamente con una única propiedad CSS — una variable usada tanto para un color de borde como para un color de texto en distintos lugares del diseño no implica que deban quedar vinculadas en el código si sus propósitos realmente son distintos. Y las variables responsive (un valor de espaciado que cambia entre breakpoints) necesitan volver a declararse dentro de cada media query relevante, ya que una sola custom property :root no puede contener más de un valor a la vez — los frames por breakpoint de Figma no se resuelven automáticamente en las sobrescrituras responsive de CSS basadas en cascada.

Revisar el CSS generado antes de publicar

• Busca desviaciones de valor. Sin una escala de utilidades que imponga consistencia, revisa si hay valores casi duplicados (padding: 15px junto a padding: 16px en otro lugar) que probablemente deberían ser el mismo número.
• Confirma el comportamiento responsive en breakpoints reales, no solo en el tamaño por defecto del frame — redimensiona el navegador en lugar de confiar en una sola captura de pantalla.
• Revisa los nombres de clases/selectores si el proyecto tiene su propia convención que seguir (BEM, CSS Modules, etc.) y ajústalos antes de hacer merge.
• Usa el editor integrado para ajustes de contenido o layout en lugar de editar la exportación a mano, y vuelve a exportar para que nada quede desincronizado.

Cada exportación recibe además una puntuación de calidad automática de IA, comparando la vista previa en vivo con el diseño original, así tienes una señal rápida de si está lista para publicarse antes de una revisión manual.

Preguntas frecuentes

¿La salida CSS usa custom properties (variables) de CSS? El resultado se centra en reglas estándar, directamente editables por elemento, en lugar de una capa de tema basada en variables — si tu proyecto usa un sistema de custom properties, planifica incorporar los valores generados a él como un paso manual.

¿El layout es responsive por defecto? Sí — los breakpoints se generan a partir de las restricciones de redimensionado del Auto Layout del frame, no se añaden después. Consulta Diseño responsive en Figma: Mobile y Desktop explicados para ver cómo funciona esto con layouts separados de mobile/desktop.

¿En qué se diferencia de la salida en Tailwind? Misma fuente de datos, destino distinto: la salida en Tailwind resuelve los valores a la clase de utilidad más parecida (con un valor arbitrario como respaldo para lo que quede fuera de escala); la salida en CSS plano mantiene los valores exactos del diseño como declaraciones estándar. Elige según si tu proyecto ya está estandarizado en un framework de utilidades.

Pruébalo con tu propio diseño

Si estás decidiendo entre una exportación de CSS puro y una basada en framework, la forma más rápida de saber cuál encaja es ver ambas sobre el mismo diseño. Prueba MarkupGen gratis, o consigue el recorrido completo en la guía de conversión de Figma a HTML. ¿Prefieres primero una visión rápida? Consulta la página del conversor de Figma a CSS.