Figma lleva código y Specs al lienzo: ¿sobrevivirá la intención del diseño?
La versión de octubre de Figma conecta prototipos ejecutables, requisitos escritos y agentes. Dónde ayudan las code layers y Specs, y dónde el equipo aún necesita revisar con criterio.
Composición oficial de los recursos de marca de Figma, utilizada sin cambios con márgenes neutros según sus directrices de uso informativo. Identifica la empresa; no muestra la interfaz de code layers ni de Specs.
Una pantalla de registro puede parecer terminada mientras las decisiones importantes siguen invisibles. ¿Qué ocurre si la invitación ha caducado? ¿Se puede reintentar tras un error de red? ¿Qué texto está aprobado? Un prototipo funcional puede responder algunas preguntas, pero también esconderlas detrás de un recorrido ideal convincente.
La versión del 15 de octubre de Figma incorpora code layers y Specs en beta abierta. Las code layers sitúan prototipos ejecutables directamente en el lienzo de diseño. Specs da a la intención escrita un lugar compartido junto a los diseños, diagramas y código que describe. Figma, la plataforma de diseño colaborativo conocida por muchos equipos de producto, amplía el espacio donde se comenta una pantalla para explorar juntos comportamiento y requisitos. Notas de versión de Figma.
Nuestra valoración: lo interesante es la relación entre esos materiales. Generar otra pantalla se aprecia fácilmente en una demostración; mantener su comportamiento alineado con las decisiones del equipo es una prueba más útil. Este artículo examina tres procesos prácticos, la disponibilidad desigual de las novedades y el trabajo de revisión que un lienzo compartido puede mejorar sin completarlo automáticamente.
Un prototipo ya puede ejecutarse junto al diseño que lo explica
Una code layer es un prototipo interactivo respaldado por código que se ejecuta dentro de un archivo de Figma Design. Permite explorar un comportamiento en el mismo espacio donde se comparan alternativas visuales. La conversación pasa de «imagina esta interacción» a «prueba estas dos versiones», manteniendo visible el trabajo de diseño que las rodea.
La guía de ayuda de code layers, consultada el 23 de octubre, describe cómo empezar desde un marco de diseño, un prompt, una web capturada, un repositorio conectado o archivos locales. El equipo puede duplicar una code layer para comparar alternativas en paralelo. Acceder a una vía concreta sigue dependiendo de su despliegue y de la compatibilidad del repositorio.
Imagina un equipo de producto revisando el registro. Una versión comprueba la invitación antes de crear la cuenta; otra deja introducir primero los datos. En un marco estático, ambas parecen plausibles. Un prototipo ejecutable muestra la secuencia, la interrupción y cuánto trabajo pierde una persona cuando falla la invitación.
El beneficio es una conversación más concreta. El equipo puede decidir qué comportamiento encaja antes de pedir a ingeniería que lo generalice en la aplicación. El prototipo expresa una idea comprobable, sin sustituir la implementación final de autenticación. Su valor está en revelar un desacuerdo cuando cambiar de dirección aún resulta barato.
Specs da a la explicación un lugar donde permanecer
El anuncio de Specs del 15 de octubre describe la llegada de Markdown al lienzo y la inserción de referencias a marcos, diagramas y otros contenidos de Figma. El documento puede conservar las razones de una decisión junto al trabajo visual. Esa relación lo diferencia de pegar una captura en un documento desconectado del resto.
En el ejemplo del registro, una especificación podría indicar que una invitación caducada debe conservar los datos introducidos, explicar quién se responsabiliza del texto e identificar el estado de error aprobado. Es fácil omitir esos detalles en un prompt como «construye esta pantalla». Cuando cambia el diseño, el equipo tiene un lugar próximo para preguntar si también cambió la regla.
Hay una diferencia útil entre contexto compartido y contexto correcto. Un documento que todos los compañeros y agentes pueden leer puede difundir una decisión obsoleta con mucha eficiencia. Alguien todavía debe decidir qué afirmaciones siguen vigentes, resolver comentarios contradictorios y marcar preguntas abiertas. Acercar los materiales reduce su distancia; no resuelve por sí solo las contradicciones.
El riesgo es otra apariencia de completitud. Una especificación pulida con imágenes integradas puede parecer autorizada aunque un requisito crítico no esté aprobado. Distingue de forma pequeña y explícita entre decisiones, supuestos y preguntas abiertas. Así un colaborador sabrá qué frases pueden guiar la implementación y cuáles requieren conversación.
Infografía conceptual original. Diseños, Specs y code layers contienen información distinta; lograr que coincidan todavía requiere revisión.
El anuncio de octubre contiene varios estados de lanzamiento
Figma agrupa capacidades que resulta fácil reducir a una sola promesa. El resumen del lanzamiento del 15 de octubre distingue betas abiertas, una beta cerrada y una vista previa. Un equipo puede evaluar las piezas disponibles mientras separa la visión más ambiciosa del sistema de las herramientas que puede usar hoy.
El calendario comercial también importa. Las notas indican que crear y editar dentro de una code layer es gratis en planes de pago hasta el 4 de noviembre de 2026. Es una oferta limitada, no una afirmación de precio permanente. Las code layers se describen como disponibles en todos los planes, mientras Specs se despliega en planes de pago. Comprueba el tipo de puesto, los créditos y las condiciones vigentes antes de presupuestar una beta para el equipo.
| Capacidad | Estado anunciado el 15 de octubre | Consecuencia práctica |
|---|---|---|
| Code layers | Beta abierta en despliegue | Probar prototipos en el lienzo; confirmar acceso en el archivo |
| Specs | Beta abierta en planes de pago | Establecer quién se responsabiliza de los requisitos y los edita |
| Code sources | Beta cerrada | No suponer que cualquier equipo puede importar así componentes reutilizables de producción |
| Guidelines | Beta abierta | Dar al agente reglas y ejemplos explícitos del sistema de diseño |
| Sistemas de diseño centralizados | Vista previa | Tratar la experiencia amplia de gestión como dirección futura |
| Figma MCP ampliado | Disponible | Comprobar cliente, permisos y herramientas necesarios para la acción |
La tabla también ofrece una secuencia de adopción. El equipo puede probar si el trabajo compartido entre prototipo y especificación mejora una revisión real antes de depender de una experiencia de gestión aún no publicada. La versión resulta más fácil de evaluar cuando cada pieza tiene su cometido y su estado.
Prueba el registro incluyendo los estados de error
El primer uso práctico es revisar un comportamiento antes de implementarlo. Utiliza un recorrido con una decisión real, no una pantalla decorativa cuya única pregunta sea si resulta atractiva. El registro sirve porque validación, carga, fallo y recuperación afectan a la experiencia.
El siguiente procedimiento es una propuesta de evaluación basada en los puntos de entrada documentados por Figma, no un informe de pruebas propias:
- Elige un marco existente y escribe junto a él el objetivo del usuario. Enumera estados de éxito, vacío, carga y error antes de pedir una versión ejecutable.
- Selecciona el marco y elige Code en la barra, o pulsa B, y después Build selection. Son los pasos documentados para empezar desde un diseño estático.
- Pide un comportamiento concreto: conservar los valores introducidos cuando falle la validación de la invitación y ofrecer un reintento claro, por ejemplo. Vincula el prompt al recorrido elegido.
- Duplica la code layer para explorar una interacción realmente diferente. Compara ambas versiones con el mismo escenario en lugar de juzgar dos recorridos ideales sin relación.
- Registra el comportamiento elegido y su justificación en una especificación. Incluye la alternativa descartada cuando explique una restricción que alguien podría eliminar en el futuro.
- Envía el diseño y los requisitos revisados al proceso normal de implementación. Verifica la autenticación y el tratamiento de datos reales en el entorno de la aplicación.
El resultado importante es una decisión respaldada por algo que el equipo pudo probar. Si el prototipo revela una incertidumbre, dejarla abierta en la especificación es mejor que inventar una regla solo para completar el documento. Una herramienta útil hace más visible la pregunta pendiente.
Un sistema de diseño necesita instrucciones además de componentes
El segundo escenario es mantener un sistema compartido de componentes mientras se explora una pantalla nueva. El equipo quizá ya tenga botones aprobados, reglas de espaciado, patrones de contenido y expectativas de accesibilidad. Un agente puede producir una alternativa visualmente plausible que esquive discretamente esa inversión y cree mantenimiento detrás de una vista atractiva.
La versión de octubre añade guidelines a bibliotecas publicadas e introduce code sources en beta cerrada. El resumen del lanzamiento los presenta como formas de dar a los agentes patrones y componentes existentes que seguir. La vista previa de sistemas centralizados extiende la idea a reunir bibliotecas, código y directrices, pero no debe tratarse como acceso universal actual.
Una prueba ilustrativa podría pedir al agente un formulario de ajustes con un componente de campo establecido. La especificación debe señalar el componente obligatorio, qué deben comunicar los mensajes de validación y qué reglas de interacción son esenciales. Después, el revisor comprueba si la implementación lo reutiliza de verdad o solo imita su aspecto.
Esa última distinción tiene consecuencias. Dos pantallas pueden parecer iguales mientras una hereda el comportamiento del componente mantenido y otra contiene una implementación nueva y ajena. La coherencia visual aporta valor, pero la coherencia de implementación determina qué correcciones futuras se propagan. El lienzo ayuda a comparar; el código sigue necesitando un revisor que conozca el sistema.
Las directrices también cuestan mantenimiento. Una regla copiada de una biblioteca antigua puede contradecir un componente nuevo, y un documento largo puede ocultar la única excepción importante. Prefiere ejemplos aprobados concretos y un responsable claro a una gran colección de preferencias sin fecha. Pide al agente que explique qué componentes utilizó para dar al revisor un punto de partida.
MCP lleva contexto al editor y puede devolver cambios
La documentación MCP de Figma, consultada el 23 de octubre, describe agentes que leen contexto de diseño y escriben contenido nativo en el lienzo. Identifica el servidor remoto como la vía con mayor compatibilidad de funciones. Escribir Specs requiere ese servidor y permiso de edición del archivo; otras acciones tienen sus propios requisitos de puesto y cliente.
Esto da al proceso un camino de vuelta. Un agente de programación puede recibir requisitos, descubrir una restricción al implementar y ayudar a actualizar la especificación compartida. El beneficio es continuidad entre decisión y código. Sirve menos si cada descubrimiento permanece en un chat del editor que el resto del equipo nunca ve.
La conexión también cambia la cuestión de permisos. Una herramienta que puede leer un marco y otra que puede editar una especificación son capacidades diferentes. Antes de habilitar el proceso, identifica el archivo, la acción prevista y quién puede aprobar cambios. Una conexión cómoda no debe convertir todos los documentos del proyecto en editables por defecto.
Para probarlo, utiliza un archivo y una petición limitada. Pide al agente que lea la especificación revisada, proponga el cambio de implementación y capture cualquier pregunta pendiente en un lugar visible. Inspecciona lo que escribió de vuelta. El objetivo es evaluar si el recorrido de ida y vuelta conserva el significado, no solo si una llamada API funciona.
Payload acerca datos reales y responsabilidades reales
El tercer escenario es una aplicación pequeña respaldada por contenido: directorio de eventos, catálogo interno o página de campaña que el personal debe actualizar. Un prototipo estático comunica la distribución mientras deja abiertas todas las cuestiones operativas. Cuando el contenido cambia a diario, el proceso de edición forma parte del producto.
Las notas del 15 de octubre dicen que Make puede generar la estructura de un backend Payload, incluidos CMS, base de datos, medios, API, autenticación y panel de administración, con Figma alojando el conjunto. Payload es un framework de contenido de código abierto. Su inclusión amplía la versión más allá de otra manera de dibujar o pedir una interfaz. Contexto del anuncio de Payload en Figma.
En el directorio de eventos, el beneficio visible es que un editor podría actualizar una entrada desde administración sin pedir que se cambie una tarjeta escrita directamente en código. La conversación de diseño puede incluir longitudes reales de campos, imágenes ausentes y borradores. Son condiciones habituales que los datos ficticios pulidos suelen ocultar.
La comodidad aumenta las responsabilidades de producción. Decide quién puede publicar, qué campos son públicos, cómo recuperar un borrado accidental y qué sucede cuando cambian los accesos. Un backend generado da un lugar donde implementar esas decisiones; no las toma por la organización. Revisa las condiciones reales de alojamiento y datos antes de aceptar envíos de usuarios.
Infografía original. Pasar del prototipo a producción añade decisiones de implementación y operación; las fases son criterios de evaluación, no una garantía medida del producto.
Explorar más rápido puede crear una cola de decisiones sin tomar
La principal ventaja es que más personas pueden discutir comportamiento mediante un elemento concreto. Un diseñador compara alternativas funcionales, un responsable de producto adjunta la intención y un ingeniero señala restricciones antes de que sorprendan en el lanzamiento. La misma velocidad también puede crear muchas variantes cuyo estado nadie recuerda.
Trata cada variante como un experimento con una pregunta. «¿Conservar los datos introducidos reduce la confusión tras este error?» ofrece algo que examinar. «Genera cinco versiones más» puede servir para explorar, pero después necesita una decisión sobre lo aprendido. De lo contrario, el lienzo se convierte en sala de espera de elecciones que nunca se hicieron.
Una medida útil para el equipo es cuántas decisiones pendientes llegan a implementación. Sigue algunos cambios habituales y pregunta si el desarrollador recibió un comportamiento más claro, menos referencias contradictorias y una vía fiable hacia el responsable de la decisión. Observa también el tiempo de mantener la especificación. El contexto compartido se gana su sitio cuando reduce ambigüedad en todo el proceso.
La expectativa que merece conservarse es modesta y potente: debería ser más fácil mantener de acuerdo diseños, razonamiento escrito y comportamiento ejecutable. La calidad beta, los límites de repositorios y las condiciones del plan influirán según el equipo. La dirección promete porque aborda la conversación que falta entre generación y producción, donde empieza tanto trabajo repetido evitable.
El lienzo puede ser un lugar donde las decisiones sigan visibles
Las code layers facilitan probar una idea. Specs facilita conservar el significado que se pretende. Juntas ofrecen una forma de mantener las razones del diseño junto a lo que se construye, para que el siguiente colaborador tenga algo más que una captura persuasiva.
La meta útil es un acuerdo que sobreviva a la implementación. Empieza con un recorrido, haz visible el comportamiento incierto y conserva la decisión junto al trabajo. Si el equipo llega a producción con menos preguntas sin respuesta, el nuevo lienzo hace algo más valioso que generar otro prototipo.
Fuentes
- Notas de versión de Figma, anuncios de Config India del 15 de octubre de 2026; consultadas el 23 de octubre.
- Build by design: nuevos procesos para nuevas formas de construir, 15 de octubre de 2026.
- Code layers en Figma Design, consultado el 23 de octubre de 2026.
- Presentación de Specs: Markdown como medio, 15 de octubre de 2026.
- Documentación del servidor MCP de Figma, consultada el 23 de octubre de 2026.
- Recursos de marca y marcas registradas de Figma, consultados el 23 de octubre de 2026.
Conserva el razonamiento de una decisión técnica
Si quieres un espacio separado para enlaces de fuentes y notas técnicas revisadas, Telli.sh es una opción. Abre tu espacio de notas.