La capa de layout que el lienzo solía ocultar
Una respuesta de la comunidad en la preview de 0.8.0 nombró la verdadera pregunta detrás del diseño agent-native: si el lienzo deja de ser la unidad de trabajo, ¿cómo siguen entendiendo el layout los usuarios?
Una respuesta útil de la comunidad no pide un botón más grande. Nombra la capa que falta.
Eso fue lo que pasó en la discusión de Open Design 0.8.0-preview. El hilo de lanzamiento defendía dos cambios: dejar de tratar el lienzo como la unidad de trabajo principal y convertir al agente en el trabajador de diseño de primera clase. Una respuesta estuvo de acuerdo con la dirección y luego señaló la parte difícil: cuando el lienzo desaparece, los usuarios siguen necesitando una forma de entender lo que hizo el agente antes de poder editarlo con confianza.
La frase en la respuesta fue «Layout Understanding Layer» (capa de comprensión del layout). Es un buen nombre porque rechaza la respuesta perezosa. El diseño agent-native no puede significar «confía en la captura de pantalla». Necesita un modelo legible del artefacto: secciones, intención, partes editables, referencias estables y movimientos de edición sugeridos. Esta publicación es un intento de tomarse esa respuesta en serio: esbozar qué podría cargar una capa así, dónde debería vivir en Open Design y por qué es una vía de contribución y no una promesa de roadmap.
El lienzo le daba a los diseñadores confianza espacial
El lienzo de Figma no es solo una superficie de dibujo. También es una superficie de explicación. Puedes alejar el zoom, ver la jerarquía de la página, hacer clic en un frame, inspeccionar restricciones, renombrar capas y entender dónde termina una pieza del trabajo y empieza otra.
Lo que realmente pierdes cuando el lienzo desaparece
Esa comprensión es fácil de subestimar hasta que ya no está. Una página de aterrizaje generada puede verse correcta en una vista previa aislada y aun así ser difícil de dirigir. El problema no son los píxeles, es la ausencia de un vocabulario compartido entre la persona y el agente.
«Haz el hero más seguro de sí mismo» solo es útil si el agente y la persona coinciden en qué es el hero. «Aprieta la sección de precios» solo funciona si el artefacto conserva una identidad de sección estable a través de las revisiones. Sin eso, cada instrucción degenera en señalar con el dedo: el diseñador describe una región por su posición («el segundo bloque desde arriba»), el agente adivina a partir de la salida renderizada, y la siguiente regeneración renumera todo en silencio. El lienzo solía absorber este coste de forma silenciosa. Nombraba las partes por ti, mantenía esos nombres estables mientras trabajabas y te permitía seleccionar una sin describirla.
La claridad vale la pena conservarla aunque la unidad sea equivocada
Esta es la parte del argumento #DeFigma que requiere cuidado. El lienzo puede ser la unidad de trabajo equivocada para un sistema agent-native —asume a una persona arrastrando rectángulos, no a un agente escribiendo archivos—, pero la claridad que la gente obtenía del lienzo sigue siendo valiosa. El error sería tratar «descartar el lienzo» y «descartar la comprensión que el lienzo proporcionaba» como la misma decisión. No lo son. Open Design tiene que trasladar esa claridad al modelo del artefacto, no tirarla. La capa de layout es el nombre de ese traslado.
Open Design ya tiene las primitivas correctas
La razón por la que esta propuesta encaja en Open Design es que el proyecto ya está construido en torno a contratos explícitos. Una skill es un archivo SKILL.md. Un sistema de diseño es un archivo DESIGN.md. Un plugin añade un sidecar open-design.json. Nada en el sistema es un blob binario que tengas que aplicar ingeniería inversa; los contratos son texto, y el texto es algo que tanto un agente como una persona pueden leer. La mecánica está cubierta en 31 skills, 72 sistemas: cómo funciona la biblioteca de Open Design, y el argumento de producto está en Por qué construimos Open Design como una capa de skills, no como un producto.
La capa de layout debería seguir el mismo patrón. Debería ser texto que el agente pueda leer, estado que la UI pueda renderizar y metadatos que otro agente pueda reutilizar. Si no puede satisfacer las tres cosas a la vez, tiene la forma equivocada.
En términos del repositorio, eso apunta a tres superficies:
| Superficie | Qué debería cargar |
|---|---|
| Manifiesto del artefacto | IDs estables para secciones, componentes, recursos y archivos generados |
| Snapshot del plugin | Qué skill, sistema de diseño, entradas y etapas del pipeline produjeron el artefacto |
| UI de revisión / salida headless | Un mapa de layout, aspectos editables e intenciones de edición sugeridas |
La restricción importante: la capa no debe convertirse en un segundo lienzo propietario. El modo de fallo a evitar es reconstruir el grafo de escena de Figma bajo un nombre nuevo: una estructura rica y específica de la aplicación que solo la UI de Open Design puede renderizar y que muere en el momento en que sales de la aplicación. La capa de layout debería ser, en cambio, un mapa de artefacto plano que viaje con los archivos, de modo que un colaborador pueda leerlo en un editor de texto y un agente distinto pueda consumirlo sin un SDK.
Una forma práctica para la capa de layout
Esta es la versión más pequeña que haría que el diseño agent-native se sintiera menos opaco:
- Cada artefacto generado obtiene IDs semánticos estables:
hero,proof-strip,pricing,faq,final-cta. - Cada ID carga una frase de intención: «Explicar la promesa del producto en una sola pantalla», no «sección superior».
- Cada sección enumera aspectos editables: texto, densidad, layout, color, medios, movimiento, fuente de datos.
- Cada archivo generado enlaza de vuelta al ID de sección que lo produjo.
- Cada pasada de revisión emite intenciones de edición sugeridas: «acortar el titular del hero», «aumentar el contraste en las tarjetas de precios», «dividir el bloque de testimonios».
- La UI renderiza esto como un navegador, mientras que los usuarios headless reciben la misma estructura como JSON o Markdown.
Cómo podría verse en realidad un manifiesto
El sentido de ponerlo por escrito es que la estructura no tiene nada de extraordinario, que es exactamente por lo que puede ser un contrato público en lugar de un truco privado. Un manifiesto para una página de aterrizaje generada podría leerse así:
{
"artifact": "landing/index.html",
"producedBy": { "skill": "magazine-poster", "system": "linear", "stage": "compose" },
"sections": [
{
"id": "hero",
"intent": "Explain the product promise in one screen",
"editable": ["copy", "density", "media"],
"files": ["landing/index.html#hero", "landing/hero.css"]
},
{
"id": "pricing",
"intent": "Let a visitor self-select a plan without scrolling back",
"editable": ["copy", "layout", "data-source"],
"files": ["landing/index.html#pricing", "landing/pricing.json"]
}
],
"suggestedEdits": [
{ "target": "hero", "intent": "shorten headline to one line" },
{ "target": "pricing", "intent": "drop from three plans to two" }
]
}Ninguna de esas claves es exótica. sections es una lista, editable es un enum, files es una referencia hacia atrás. El valor no está en la astucia del esquema, sino en el hecho de que los IDs sobreviven a una regeneración, de modo que el mismo bloque pricing sigue siendo pricing después de que el agente lo reescriba dos veces.
Eso basta para permitir que un diseñador diga «Cambia pricing de tres planes a dos», y basta para permitir que un agente de código parchee el archivo correcto sin adivinar a partir de los píxeles. La instrucción se resuelve en un ID de sección, el ID de sección se resuelve en un conjunto de archivos, y la edición aterriza donde se pretendía.
Por qué esto es una vía de contribución, no una solicitud de función
También le da a la comunidad una vía de contribución limpia. Un colaborador no necesita rediseñar el producto para ayudar aquí. Puede escribir una skill que emita un manifiesto para un tipo de artefacto, un átomo de revisión que proponga intenciones de edición, una extensión de manifiesto que añada un campo que otras skills puedan leer, o un caso de prueba que verifique que los IDs de sección se mantienen estables a través de una regeneración. Cada uno de esos es un cambio pequeño y mergeable que hace que una salida sea menos opaca, y como la capa es texto plano, dos colaboradores trabajando en una presentación y en una pantalla móvil no tienen que coordinar un formato binario compartido. La capa de layout se convierte en un contrato público, no en una capacidad privada enterrada dentro de la aplicación.
Qué hacer a continuación
Si este es el tipo de problema en el que quieres trabajar, contribuye con una pequeña skill o plugin que haga que un artefacto sea más fácil de inspeccionar. Empieza con una salida concreta: una página de aterrizaje, una presentación o una pantalla móvil. Añade IDs de sección estables, describe los aspectos editables, emítelos como JSON o Markdown junto al artefacto, y abre el PR con un artefacto de antes/después para que quien revise pueda ver la diferencia que aporta una capa inspeccionable.
Esto sigue siendo una dirección, no una función entregada; el valor de nombrarla ahora es que las primitivas ya existen, así que el trabajo es aditivo en lugar de una reescritura.
Lecturas relacionadas
- 31 skills, 72 sistemas: cómo funciona la biblioteca de Open Design — las primitivas actuales basadas en archivos que sustentan la propuesta
- Por qué construimos Open Design como una capa de skills, no como un producto — la forma de producto que hace posibles los contratos públicos de artefactos
- La alternativa de código abierto a Figma — dónde aterriza «descartar el lienzo» frente al referente que hizo del lienzo el centro