¿Qué es el paso de diseño a código?
El paso de diseño a código describe el proceso de convertir las decisiones tomadas en una herramienta como Figma en código front-end funcional. La versión duradera transfiere tokens de diseño en lugar de generar marcado a partir de un lienzo, porque los tokens siguen siendo válidos cuando la interfaz cambia y el marcado generado no.
Dos enfoques que se confunden
Generar código a partir de un lienzo. Apuntas una herramienta a un frame de Figma y recibes JSX o HTML. Queda estupendo en una demo y decepciona en producción: la salida no tiene relación con tu librería de componentes, el anidamiento refleja cómo agrupó las capas quien diseñó, y en cuanto el diseño cambia regeneras y pierdes cualquier edición.
Transferir las decisiones. Mueves los tokens (color, espaciado, tipografía, radio) y dejas que los desarrolladores construyan componentes que los referencien. Menos impresionante en una demo. Es el que sobrevive, porque los tokens siguen siendo válidos cuando cambia el layout, y porque el código sigue siendo código que una persona escribió y puede mantener.
Casi todos los equipos que prueban el primer enfoque acaban en el segundo.
Por qué el handoff sigue fallando
El fallo no está en el momento de la entrega. Está en todo lo que viene después.
Una diseñadora actualiza un color en Figma. Ese cambio tiene que llegar a una hoja de estilos. No hay ninguna vía automática, así que llega por un mensaje en un canal, que alguien lee, o no. Multiplícalo por cada cambio a lo largo de un año.
Los dos lados están trabajando correctamente. La conexión entre ellos es una persona acordándose.
La restricción de la API de Figma
Conviene saberlo antes de evaluar cualquier herramienta de este ámbito: el endpoint de la API REST de Figma para leer variables solo está disponible en planes Enterprise.
Eso significa que una herramienta que sincroniza variables de Figma por la API REST funciona en una demo sobre una cuenta Enterprise y no hace nada en el plan Professional que tiene la mayoría de equipos. Los plugins no están sujetos a esto, porque leen las variables desde dentro del archivo a través de la API de plugins. Si estás comparando herramientas de sincronización, pregunta cuál usa cada una.
Qué aspecto tiene un ciclo que funciona
- Las decisiones de diseño viven como tokens, en un único sitio que ambos lados referencian.
- Un cambio del lado del diseño llega como un diff, no como una sobrescritura.
- Una persona con permisos de edición lo revisa y lo aplica.
- Se abre un pull request contra el repositorio, que pasa por la revisión de código habitual.
- Los agentes de IA leen esos mismos tokens en vivo, así que el código generado aterriza dentro del sistema y no al lado.
El paso de revisión intermedio no es fricción que haya que optimizar. Una herramienta que reescribe en silencio los tokens de un equipo cuesta más confianza de la que devuelve la automatización.
Dónde encaja Flash DSM
Flash DSM usa un plugin de Figma como transporte, así que funciona en cualquier plan de Figma. Una publicación se convierte en un diff de tokens revisable, y un diff aprobado puede abrirse como pull request.