Qué contiene realmente un frame
Un frame de Figma es un árbol de formas con posiciones, rellenos, trazos, secuencias de texto y restricciones de diseño. Esa es una descripción completa de cómo se ve algo en un tamaño determinado. No es una descripción de qué es cada elemento.
| En el archivo | Debe inferirse | |
|---|---|---|
| Estructura | Un grupo de rectángulos y texto en estas coordenadas | Que este grupo es una Card, y que es la misma Card utilizada en otras nueve pantallas |
| Color | El relleno es #6b7280 | Si se trata de texto atenuado, un borde, un estado deshabilitado o un placeholder |
| Espaciado | 32px entre estos dos elementos | Si 32 es un paso de la escala, un valor puntual o el resultado de un ajuste manual |
| Responsividad | Constraints y los frames de breakpoint que existan | Qué sucede en cada ancho intermedio entre ellos |
| Semántica | Texto con un tamaño mayor y un peso más grueso | Si es un h1, un h2 o texto con estilo que no es un encabezado |
Cada fila de la columna derecha es una decisión que el convertidor debe tomar sin información. Tomará cada una de forma plausible e independiente, razón por la cual el resultado es, simultáneamente, convincente a primera vista e imposible de mantener.
Un frame codifica la apariencia. El código necesita identidad e intención. El convertidor no está fallando. La información nunca estuvo en el archivo.
El coste del código generado
Si se acepta el resultado tal cual, surgen cuatro problemas específicos, todos los cuales aparecen después de que el código se ha fusionado y no durante la revisión.
- 1
Sin reutilización de componentes
La misma tarjeta convertida en cinco pantallas se convierte en cinco implementaciones independientes. No hay nada que las vincule, por lo que un cambio en la tarjeta implica cinco cambios, y alguien acabará encontrando solo cuatro.
- 2
Valores literales en todas partes
Los conversores emiten
#6b7280porque eso es lo que indica el relleno. Se ignora por completo la capa de tokens, lo que significa que el sistema de diseño que ha construido es ahora meramente decorativo en esas pantallas. - 3
Diseño absoluto o frágil
Los datos de posición se convierten en posicionamiento. Coincide con el frame exactamente en el ancho del frame y se degrada en cualquier otro, siendo la degradación peor en los dispositivos que menos se han probado.
- 4
Sin semántica
Un texto grande y pesado se convierte en un
divcon estilos. Los lectores de pantalla reciben una página sin estructura de encabezados, los usuarios de teclado no encuentran puntos de referencia y nadie lo nota hasta que se realiza una auditoría.
El segundo punto es el más trascendental y el menos visible en la revisión. Una vez que las pantallas generadas contienen valores de color literales, la base de código tiene dos sistemas de color: los tokens y lo que el archivo de diseño decía ese día. Un control de CI que falle al detectar un hex fuera del archivo de tokens lo detiene en la entrada.
El mapeo es superior a la generación
El enfoque productivo consiste en dejar de pedirle a la herramienta que escriba código y empezar a decirle qué código ya existe. Code Connect de Figma hace exactamente esto: vincula un componente de diseño con el componente de código real, de modo que el Dev Mode muestra el componente real y sus props en lugar de CSS generado.
Esto cambia el problema de la generación a la búsqueda, y la búsqueda es un problema que puede resolverse correctamente.
| Generar | Mapear | |
|---|---|---|
| Produce | Marcado nuevo que aproxima el frame | Una referencia al componente que ya mantiene |
| Reutilización | Ninguna. Cada conversión es nueva | Total, por construcción |
| Tokens | Ignorados; se emiten literales | Preservados; el componente ya los utiliza |
| Accesibilidad | Lo que el conversor haya inferido | Lo que su componente ya haga |
| Coste de configuración | Ninguno | Un mapeo por componente, mantenido a medida que los componentes cambian |
| Falla cuando | Siempre, lentamente | Un diseño utiliza algo que aún no existe en el código |
Esa última fila es el coste real, y es significativo: el mapeo solo funciona para componentes que existen. Un diseño genuinamente nuevo sigue requiriendo construcción. Pero esa es la división correcta del trabajo: un humano o un agente construye el nuevo componente una vez, y cada uso posterior es una referencia en lugar de una regeneración.
Vale la pena ser concretos sobre el objetivo del mapeo. Un handoff termina cuando la parte del código se ve así, con roles nombrados y valores reales, en lugar de una lista de hex recuperados de un frame:
La estrategia de paridad de nombres
Bajo el mapeo de componentes hay un cambio más sencillo que cierra una cantidad sorprendente de la brecha, y no requiere ninguna herramienta: utilizar los mismos nombres en ambos lugares.
SLDS 2 de Salesforce es el ejemplo publicado más claro. Su librería de Figma utiliza los mismos nombres de hooks de estilo semánticos que el CSS (los propios ejemplos del equipo son radius-border-4 y font-scale-4), por lo que los diseños se mapean uno a uno con el código real. Su objetivo declarado es un vocabulario compartido que sirva de puente entre el diseño y el desarrollo.
El efecto es que desaparece toda una categoría de errores de handoff. Cuando un diseñador dice font-scale-4 y un desarrollador escribe font-scale-4, no hay un paso de traducción, por lo que no hay lugar para que el significado se pierda. Compare esto con un estilo de Figma llamado "Heading / Large" que se mapea a una variable CSS llamada --text-2xl: cada handoff es una búsqueda y cada búsqueda puede fallar.
| Discrepantes | Coincidentes | |
|---|---|---|
| Handoff | Un paso de traducción por propiedad | Copiar el nombre |
| Revisar | "¿Es este el gris correcto?" requiere abrir ambas herramientas | El nombre es correcto o no lo es |
| Un agente que lee ambos | Dos vocabularios, sin relación declarada, suposiciones silenciosas | Un solo vocabulario |
Si solo hace una cosa de este artículo, renombre sus variables de Figma para que coincidan exactamente con sus propiedades personalizadas de CSS. Cuesta una tarde, no requiere ningún plugin y elimina un impuesto permanente en cada handoff. Los nombres planos, en minúsculas y con guiones sobreviven en ambas herramientas: más sobre nomenclatura para portabilidad.
Cuando el sistema de diseño reside en Figma
Muchos equipos tienen una librería de Figma exhaustiva y una base de código que solo la refleja parcialmente. El instinto es buscar una herramienta que cierre esa brecha automáticamente. Hay una alternativa más económica que funciona mejor.
Una librería de Figma contiene las decisiones: la escala, los roles, el conjunto de componentes, el ritmo del espaciado. Esas decisiones se transfieren perfectamente como texto, y el texto es el formato sobre el cual tanto un desarrollador como un agente de código pueden actuar. Extraerlas en un archivo de tokens más un brief escrito es un día de trabajo y hace que cualquier conversión posterior sea innecesaria, porque el lado del código ahora tiene la misma información que el lado del diseño.
Analizamos 299 archivos DESIGN.md escritos precisamente para trasladar esa información a agentes de IA, y la mayoría no lo hace: el 86% especifica los colores como hex raw sin rol semántico, el 76% no indica prohibiciones, el 69% no define el modo oscuro y el 44% no indica ningún valor de tamaño concreto en ninguna parte. Un brief extraído de una librería de Figma real, hecho correctamente, supera a casi todos ellos. Usted ya tiene los números.
- 1
Exporte las variables como tokens, con roles
No la paleta raw. Los roles: qué color es texto atenuado, cuál es un borde, cuál es un estado desactivado. Si sus variables de Figma están nombradas por tono, este es el momento de renombrarlas por rol en ambos lugares a la vez.
- 2
Escriba las escalas como números
Tamaños de fuente, pasos de espaciado, radios. La librería ya contiene esto; el lado del código suele tener un subconjunto más improvisaciones.
- 3
Escriba lo que la librería prohíbe hacer
Las prohibiciones están en la librería implícitamente (sin sombras en ninguna parte, sin pesos superiores a 600), y son lo más valioso de hacer explícito, ya que son invisibles para cualquier extracción automatizada.
- 4
Mapee los componentes que ya existen en el código
Solo ahora vale la pena introducir herramientas, y solo para componentes que estén en ambos lados. Todo lo que no esté mapeado es una construcción desde cero, y saber cuál es cuál es, en sí mismo, útil.
Los kits de Identity Forge son ese artefacto en formato preconstruido: 28 roles de color semánticos para modo claro y oscuro, escalas de tipografía y espaciado, motivos y directrices explícitas de lo que se debe y no se debe hacer, exportables como variables CSS, @theme de Tailwind, un elemento de registro de shadcn o JSON de DTCG/W3C. Explore los kits o lea cómo escribir el brief.
Qué esperar de las herramientas actuales
Expectativas calibradas, por tarea:
| Resultado realista | |
|---|---|
| Un prototipo desechable a partir de un mockup | Bien. La deuda estructural no importa en un código que se va a borrar |
| Extracción de medidas y valores | Bien, y subestimado. La inspección en Dev Mode es la victoria aburrida y fiable |
| Una pantalla nueva utilizando componentes existentes | Bien si el mapeo está configurado. Mal si no lo está |
| Markup de producción a partir de un frame complejo | Mal. Visualmente cercano, estructuralmente incorrecto, y la limpieza suele requerir más trabajo que escribirlo desde cero |
| Convertir un sistema de diseño completo | No es un problema de conversión. Extraiga las decisiones como texto en su lugar |
La segunda fila merece más reconocimiento del que recibe. Una inspección fiable (valores exactos, nombres de tokens reales, props de componentes reales) elimina una fricción diaria genuina y nunca pretende hacer más de lo que hace.
¿Puede la IA convertir diseños de Figma en código de producción?
Puede producir código que se parezca al frame. Si eso es código de producción depende de la estructura, y la estructura es lo que un frame no contiene: identidad del componente, roles semánticos y comportamiento responsivo entre breakpoints. Espere un resultado visualmente cercano pero estructuralmente erróneo, y presupueste el tiempo para la limpieza.
¿Qué es Figma Code Connect?
Una función que vincula los componentes de diseño con sus componentes de código reales, de modo que Dev Mode muestre el componente real y sus props en lugar de CSS generado. Cambia el problema de generar nuevo marcado a referenciar código que ya mantiene, lo que preserva el trabajo de reutilización, tokens y accesibilidad.
¿Por qué el resultado de design-to-code utiliza colores hardcoded?
Porque el relleno en el frame es un valor, y el convertidor no tiene forma de saber qué rol semántico desempeña ese valor. Vincular los nombres de sus variables de Figma con los nombres de sus tokens de CSS es lo que da a la herramienta algo a lo que referenciar en lugar de un código hex.
¿Cómo paso mi sistema de diseño de Figma a código?
No convirtiendo pantallas. Exporte las variables como tokens semánticos con roles asignados, escriba las escalas como números, anote lo que la librería se niega a hacer y, solo entonces, mapee los componentes que existen en ambos lados. Eso es un día de trabajo y hace que la conversión continua sea innecesaria.
¿Deben usar los mismos nombres de tokens diseñadores y desarrolladores?
Sí, y es el cambio con mayor retorno de inversión según el esfuerzo realizado. Cuando un diseñador dice font-scale-4 y un desarrollador escribe font-scale-4, no hay paso de traducción y, por tanto, no hay lugar para que el significado se pierda. Salesforce construyó la librería de Figma de SLDS 2 basándose precisamente en esta paridad.