Figma Make acerca la edición visual al código real

La distancia entre diseño Y el desarrollo siempre ha sido una de las etapas más costosas en el trabajo de desarrollo de software. Un diseñador crea una pantalla. Un desarrollador la traduce a código. La implementación resulta ligeramente diferente. El diseñador hace comentarios. El desarrollador realiza ajustes. Surge otro caso extremo. El ciclo continúa.

La última actualización de Make por parte de Figma supone un intento de acortar ese ciclo. La empresa afirma que los usuarios ya pueden conectar Make a un código fuente local, seleccionar elementos de forma visual, ajustar propiedades como diseños, colores, fuentes o tamaños, y dejar que el agente busque el código correspondiente y aplique el cambio. La función también permite implementar cambios desde Make, lo que la lleva más allá de la generación de prototipos y la adentra en el terreno más delicado de la edición de software real.

Eso no significa que los diseñadores vayan a sustituir de repente a los ingenieros. Tampoco significa que todos los cambios visuales deban eludir la revisión de los desarrolladores. La forma más útil de interpretar esta actualización es la siguiente: Figma está intentando que el código sea más accesible precisamente en el momento en que se toman las decisiones de diseño.

Para los equipos de producto, eso podría ser muy importante.

El antiguo sistema de traspaso está bajo presión

El traspaso del diseño al desarrollo ha mejorado con el paso de los años, pero nunca ha desaparecido por completo. Los sistemas de diseño, las bibliotecas de componentes, los tokens, las herramientas de inspección y una mejor colaboración han ayudado, pero muchos equipos siguen perdiendo tiempo a la hora de plasmar la idea en la implementación.

El problema rara vez es que los diseñadores y los desarrolladores no se comuniquen. Es que trabajan en ámbitos diferentes. Los diseñadores manipulan la interfaz de forma visual. Los desarrolladores manipulan el código subyacente. Cada parte ve solo una parte de la realidad.

Esto genera los típicos problemas. Un cambio de espaciado que parece insignificante en un archivo de diseño puede estar vinculado a un componente compartido. Es posible que un ajuste de color deba respetar los tokens de diseño. El estado de un botón puede depender de las normas de accesibilidad, la adaptabilidad, la gestión de errores o la lógica del producto. Una página que se ve bien en una ventana gráfica puede fallar en otra.

La integración de código local de Figma Make resulta interesante porque intenta acercar ambos mundos. En lugar de pedir al diseñador que describa un cambio y espere a que otra persona encuentre el archivo adecuado, la herramienta permite al usuario señalar un elemento de la interfaz y solicitar la modificación directamente. A continuación, el agente lee el contexto del código y aplica la modificación.

Se trata de un proceso diferente al de limitarse a generar un prototipo a partir de una indicación.

La edición visual cobra mayor importancia cuando afecta al código de producción

Figma Make ya forma parte de la tendencia generalizada de creación de aplicaciones mediante IA, en la que los usuarios pueden generar prototipos o aplicaciones funcionales a partir de indicaciones en lenguaje natural y referencias de diseño. Este nuevo paso es aún más trascendental, ya que se conecta con los códigos fuente existentes. The Verge describió la actualización como una herramienta que permite a los equipos utilizar Figma Make como un entorno visual para crear y editar software real, en lugar de limitarse únicamente a explorar prototipos.

Eso modifica el perfil de riesgo.

Un prototipo creado puede ser imperfecto y, aun así, resultar útil. Ayuda al equipo a explorar un concepto. Sin embargo, cualquier modificación en un código real debe cumplir unos estándares más exigentes. Debe respetar la arquitectura, la reutilización de componentes, la accesibilidad, la gestión del estado, la capacidad de respuesta, las pruebas, las convenciones de nomenclatura y las normas del sistema de diseño.

Aquí es donde la edición visual de código puede resultar muy útil, pero solo si el agente comprende el sistema en su conjunto. Una simple modificación del color o del espaciado es una cosa. Un cambio de diseño que afecte a componentes reutilizables en varias páginas es otra muy distinta. Una interfaz visual puede dar la sensación de que la modificación es local, mientras que el cambio en el código puede tener consecuencias más amplias.

Por eso el flujo de trabajo de los desarrolladores sigue siendo importante. Las modificaciones visuales requieren revisión, control de versiones y la posibilidad de ver exactamente qué ha cambiado. Una implementación sólida debería crear una solicitud de incorporación de cambios, mostrar las diferencias, respetar los flujos de trabajo de las ramas y permitir a los ingenieros aceptar, rechazar o modificar el cambio.

Si la herramienta es compatible con esa disciplina, podría reducir las idas y venidas innecesarias. Si no lo es, podría generar nuevos tipos de trabajo de corrección.

El papel del diseñador empieza a cambiar

Para los diseñadores, el atractivo es evidente. Muchas decisiones de diseño son visuales y precisas. Los diseñadores saben cuándo una maquetación no encaja, cuándo el espaciado es incorrecto, cuándo un componente no se ajusta a la jerarquía prevista o cuándo la interfaz implementada se ha desviado del sistema de diseño.

Hasta ahora, a menudo tenían que comunicar esos problemas de forma indirecta: un comentario, una captura de pantalla, un ticket, un mensaje de Slack, una nota de control de calidad. Cada uno de ellos supone un obstáculo. La edición visual ofrece al diseñador una forma más directa de expresar la solución.

Esto no implica que todos los diseñadores tengan que convertirse en ingenieros de software. Pero sí requiere un mayor conocimiento del código. Los diseñadores que utilicen herramientas como Figma Make deberán comprender que una interfaz no es solo lo que aparece en pantalla, sino que también es un sistema de componentes, restricciones, tokens y comportamientos. Los mejores diseñadores pueden llegar a sentirse más cómodos pensando en términos de implementación, sin necesidad de escribir código a mano.

Esto podría hacer que el papel del diseñador cobrara mayor importancia, no porque pase por alto a los ingenieros, sino porque puede participar de forma más directa en la capa de implementación.

También podría cambiar el tipo de trabajo al que dedican su tiempo los diseñadores. Es posible que se dediquen menos horas a documentar pequeñas correcciones visuales. En cambio, se podría dedicar más tiempo a la calidad de la interacción, la lógica del producto, la accesibilidad, la jerarquía de contenidos y el pensamiento sistémico.

Los desarrolladores pueden acogerlo con agrado o oponerse a él

La reacción de los desarrolladores dependerá de cómo se comporte la herramienta en la práctica.

Si Figma Make genera cambios limpios y revisables que respetan el código existente, es posible que los desarrolladores lo acojan con agrado. Las pequeñas correcciones visuales, la armonización con el sistema de diseño y los ajustes repetitivos de la interfaz de usuario pueden resultar tediosos. Si un agente se encarga de ellos adecuadamente, los ingenieros pueden centrarse en la arquitectura, el rendimiento, la lógica, los flujos de datos, las pruebas y otras tareas técnicas de mayor valor.

Pero si el agente genera diferencias desordenadas, ignora los patrones existentes o realiza cambios que, aunque parezcan correctos a simple vista, debilitan el código, los desarrolladores se resistirán a utilizarlo. Y con razón.

La historia de las herramientas de conversión de diseño a código está plagada de promesas exageradas. Muchas herramientas generan resultados que parecen aceptables en una demostración, pero que resultan difíciles de mantener en un producto real. Investigaciones recientes sobre los flujos de trabajo automatizados de conversión de Figma a código han revelado que, incluso los modelos más sólidos pueden tener dificultades con la adaptabilidad del diseño y la facilidad de mantenimiento del código, a pesar de que mejoran la fidelidad visual.

Ese es el estándar que tendrá que cumplir Figma Make. La precisión visual no es suficiente. El código tiene que formar parte del producto.

La oportunidad real es menor de lo que se dice, pero sigue siendo valiosa

La versión más optimista de esta historia es que Figma Make “revolucionará” el desarrollo de software de la noche a la mañana. Probablemente no lo hará.

La versión más completa resulta más práctica. Figma Make podría reducir las dificultades que plantean ciertos tipos de cambios en el front-end: ajustar el espaciado, la tipografía, los colores, los detalles de maquetación, las variantes de los componentes, el comportamiento adaptativo o pequeños ajustes en la interfaz. Estos son precisamente los cambios que pueden llevar mucho tiempo, ya que se sitúan a medio camino entre la decisión de diseño y los detalles de implementación.

Si esas modificaciones se realizan con mayor rapidez, los equipos podrán lanzar productos más pulidos con menos esfuerzo de coordinación. Los diseñadores podrán probar ideas en un entorno más realista. Los desarrolladores podrán revisar cambios concretos en el código en lugar de tener que interpretar comentarios vagos. Los gestores de producto podrán ver antes versiones de las funcionalidades más cercanas a la realidad.

Esta herramienta también puede resultar útil para el mantenimiento de los sistemas de diseño. Si un equipo necesita aplicar un patrón visual en múltiples lugares, un agente de IA que conozca el contexto del código fuente podría ayudar a identificar los componentes pertinentes y actualizarlos de forma más coherente que si se hiciera manualmente, ticket por ticket.

Pero esto solo funciona cuando el código está lo suficientemente estructurado como para que el agente pueda entenderlo. Un sistema de componentes maduro, una nomenclatura clara, tokens de diseño y una arquitectura coherente probablemente darán mejores resultados que un código fragmentado y lleno de implementaciones puntuales.

En otras palabras, Figma Make podría beneficiar a los equipos que ya cuentan con una buena organización en el ámbito del front-end.

La gobernanza pasa a formar parte del flujo de trabajo

Una vez que las modificaciones visuales pueden afectar al código en producción, la gobernanza cobra una importancia fundamental. Los equipos necesitan normas claras sobre quién puede realizar cambios, qué tipo de cambios requieren la aprobación de los desarrolladores, cómo se crean las ramas, cómo se revisan las solicitudes de incorporación de cambios y cómo se aplican las normas del sistema de diseño.

No se trata solo de una cuestión técnica. Es una cuestión de cultura de equipo.

Es posible que los diseñadores quieran tener más control sobre la fidelidad. Es posible que los desarrolladores quieran garantizar la calidad del código. Es posible que los equipos de producto quieran una iteración más rápida. Es posible que la dirección quiera ciclos de entrega más cortos. Todos esos objetivos son legítimos, pero pueden entrar en conflicto si no se define el flujo de trabajo.

Probablemente, el mejor uso que se le puede dar a Figma Make será el colaborativo, más que el unidireccional. Los diseñadores pueden proponer o realizar cambios visuales. El agente puede plasmar esos cambios en código. Los desarrolladores pueden revisar las diferencias. El sistema de diseño puede seguir siendo la fuente de coherencia. El equipo de producto puede avanzar más rápido sin renunciar a la responsabilidad técnica.

Ese equilibrio es importante. Las herramientas de IA deberían reducir las dificultades en el traspaso de tareas, no eliminar la responsabilidad profesional.

Por qué esto es importante más allá de Figma

La iniciativa de Figma se inscribe en una tendencia más amplia en el ámbito de la creación de software. La frontera entre el diseño, la programación y la gestión de productos se está volviendo menos rígida. Los agentes de programación basados en IA pueden leer códigos fuente, generar cambios y responder a instrucciones en lenguaje natural. Las herramientas de diseño pueden crear prototipos funcionales. Los equipos de producto pueden probar ideas más rápidamente. Los desarrolladores trabajan cada vez más con agentes, en lugar de escribir cada línea desde cero.

Las investigaciones sobre los agentes de programación que convierten especificaciones visuales en aplicaciones web apuntan en la misma dirección: los agentes no solo se evalúan en función de su capacidad para escribir código, sino también de su capacidad para crear aplicaciones funcionales y visualmente coherentes a partir de diseños y capturas de pantalla.

Esto no significa que todo el mundo se convierta en desarrollador, sino que el trabajo con software se vuelve más fluido. La persona más cercana al problema puede expresar el cambio de forma más directa, mientras que la herramienta se encarga de parte de la traducción.

Esto es importante porque muchos retrasos en el desarrollo de productos no se deben a la falta de ideas, sino a los costes que supone la coordinación entre las distintas disciplinas.

La dirección del viaje

La nueva integración del código fuente de Figma Make se entiende mejor como parte de un cambio gradual, más que como una ruptura repentina. Los archivos de diseño están cada vez menos separados de la implementación. El código es cada vez más editable a través de interfaces visuales y de lenguaje natural. Los agentes de IA se están convirtiendo en parte de la capa de colaboración entre disciplinas.

La oportunidad radica en una iteración más rápida y una mayor fidelidad entre lo que diseñan los equipos y lo que experimentan los usuarios. El riesgo es una menor calidad del código si los cambios visuales se consideran inofensivos cuando en realidad no lo son.

Los equipos que más se beneficien serán aquellos que mantengan una gestión disciplinada del flujo de trabajo. Utilizarán la edición visual para aquellos tipos de cambios en los que resulte realmente eficaz, mantendrán a los desarrolladores al tanto del proceso de revisión, conservarán sistemas de componentes sólidos y considerarán las modificaciones generadas por la IA como propuestas que deben someterse a revisión.

Puede que Figma Make no elimine el traspaso entre el diseño y el desarrollo. Pero puede hacer que ese traspaso se parezca menos a un ejercicio de traducción y más a un proceso de edición compartido.

Se trata de un cambio significativo. Es poco probable que el futuro del desarrollo de productos consista en que los diseñadores estén por un lado y los desarrolladores por otro, intercambiándose archivos. Será un flujo de trabajo más integrado en el que la intención del diseño, el contexto del código y la asistencia de la IA se unan en una fase más temprana.

Los ganadores no serán los equipos que permitan que cualquiera edite cualquier cosa. Serán los equipos que utilicen estas herramientas para avanzar más rápido, al tiempo que mantienen el producto coherente, accesible y fácil de mantener.