Il livello di layout che il canvas nascondeva

Una risposta utile della community non chiede un pulsante più grande. Dà un nome al livello mancante.

È quello che è successo sotto la discussione su Open Design 0.8.0-preview. Il thread di lancio sosteneva due cambiamenti: smettere di trattare il canvas come l'unità di lavoro primaria, e rendere l'agente un lavoratore di design di prima classe. Una risposta concordava con la direzione, poi indicava la parte difficile: quando il canvas scompare, gli utenti hanno ancora bisogno di un modo per capire cosa l'agente ha creato prima di poterlo modificare con fiducia.

L'espressione nella risposta era "Layout Understanding Layer". È un buon nome perché rifiuta la risposta pigra. Il design agent-native non può significare "fidati dello screenshot". Ha bisogno di un modello leggibile dell'artefatto: sezioni, intento, parti modificabili, riferimenti stabili e mosse di modifica suggerite. Questo articolo è un tentativo di prendere sul serio quella risposta: abbozzare cosa potrebbe trasportare un tale livello, dove dovrebbe vivere in Open Design e perché è un percorso di contribuzione piuttosto che una promessa di roadmap.

Il canvas dava ai designer fiducia spaziale

Il canvas di Figma non è solo una superficie di disegno. È anche una superficie di spiegazione. Puoi rimpicciolire, vedere la gerarchia della pagina, cliccare un frame, ispezionare i vincoli, rinominare i livelli e capire dove un pezzo di lavoro finisce e un altro inizia.

Cosa perdi davvero quando il canvas scompare

Quella comprensione è facile da sottovalutare finché non è andata. Una landing page generata può sembrare corretta in un'anteprima in sandbox ed essere comunque difficile da dirigere. Il problema non sono i pixel: è l'assenza di un vocabolario condiviso tra l'umano e l'agente.

"Rendi l'hero più sicuro" è utile solo se l'agente e l'umano concordano su cosa sia l'hero. "Stringi la sezione dei prezzi" funziona solo se l'artefatto porta un'identità di sezione stabile attraverso le revisioni. Senza quello, ogni istruzione degenera in un indicare: il designer descrive una regione per la sua posizione ("il secondo blocco dall'alto"), l'agente indovina dall'output renderizzato, e la rigenerazione successiva rinumera silenziosamente tutto. Il canvas assorbiva questo costo silenziosamente. Nominava le parti per te, manteneva quei nomi stabili mentre lavoravi, e ti lasciava selezionarne una senza descriverla.

La chiarezza vale la pena di essere conservata anche se l'unità è sbagliata

Questa è la parte dell'argomentazione #DeFigma che richiede attenzione. Il canvas può essere l'unità di lavoro sbagliata per un sistema agent-native — presuppone un umano che trascina rettangoli, non un agente che scrive file — ma la chiarezza che le persone ottenevano dal canvas è ancora preziosa. L'errore sarebbe trattare "abbandona il canvas" e "abbandona la comprensione che il canvas forniva" come la stessa decisione. Non lo sono. Open Design deve spostare quella chiarezza nel modello dell'artefatto, non buttarla via. Il livello di layout è il nome per quel trasloco.

Open Design ha già le primitive giuste

Il motivo per cui questa proposta si adatta a Open Design è che il progetto è già costruito attorno a contratti espliciti. Una skill è un file SKILL.md. Un design system è un file DESIGN.md. Un plugin aggiunge un file laterale open-design.json. Nulla nel sistema è un blob binario che devi decodificare; i contratti sono testo, e il testo è qualcosa che sia un agente sia un umano possono leggere. I meccanismi sono trattati in 31 skill, 72 sistemi: come funziona la libreria di Open Design, e l'argomentazione di prodotto è in perché abbiamo costruito Open Design come un livello di skill, non come un prodotto.

Il livello di layout dovrebbe seguire lo stesso schema. Dovrebbe essere testo che l'agente può leggere, stato che la UI può renderizzare e metadati che un altro agente può riutilizzare. Se non può soddisfare tutti e tre contemporaneamente, ha la forma sbagliata.

In termini di repository, questo punta a tre superfici:

Superficie	Cosa dovrebbe trasportare
Manifest dell'artefatto	ID stabili per sezioni, componenti, asset e file generati
Snapshot del plugin	Quale skill, design system, input e fasi della pipeline hanno prodotto l'artefatto
UI di revisione / output headless	Una mappa del layout, gli aspetti modificabili e gli intenti di modifica suggeriti

Il vincolo importante: il livello non dovrebbe diventare un secondo canvas proprietario. La modalità di fallimento da evitare è ricostruire lo scene graph di Figma sotto un nuovo nome — una struttura ricca e specifica dell'app che solo la UI di Open Design può renderizzare e che muore nel momento in cui lasci l'app. Il livello di layout dovrebbe invece essere una semplice mappa dell'artefatto che viaggia con i file, così un contributore può leggerla in un editor di testo e un agente diverso può consumarla senza un SDK.

Una forma pratica per il livello di layout

Ecco la versione più piccola che renderebbe il design agent-native meno opaco:

1. Ogni artefatto generato ottiene ID semantici stabili: hero, proof-strip, pricing, faq, final-cta.
2. Ogni ID porta una frase di intento: "Spiega la promessa del prodotto in una schermata", non "sezione superiore".
3. Ogni sezione elenca gli aspetti modificabili: testi, densità, layout, colore, media, motion, fonte dati.
4. Ogni file generato si ricollega all'ID della sezione che lo ha prodotto.
5. Ogni passaggio di revisione emette intenti di modifica suggeriti: "accorcia il titolo dell'hero", "aumenta il contrasto nelle card dei prezzi", "dividi il blocco delle testimonianze".
6. La UI lo renderizza come un navigatore, mentre gli utenti headless ricevono la stessa struttura come JSON o Markdown.

Come potrebbe apparire davvero un manifest

Il punto di scriverlo è che la struttura è poco notevole — il che è esattamente il motivo per cui può essere un contratto pubblico invece di un trucco privato. Un manifest per una landing page generata potrebbe leggersi così:

{
  "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" }
  ]
}

Nessuna di quelle chiavi è esotica. sections è una lista, editable è un enum, files è un riferimento all'indietro. Il valore non sta nell'ingegnosità dello schema: sta nel fatto che gli ID sopravvivono a una rigenerazione, così lo stesso blocco pricing è ancora pricing dopo che l'agente lo ha riscritto due volte.

Questo basta per permettere a un designer di dire "Cambia pricing da tre piani a due", e basta per permettere a un agente di codice di applicare la patch al file giusto senza indovinare dai pixel. L'istruzione si risolve in un ID di sezione, l'ID di sezione si risolve in un insieme di file, e la modifica arriva dove era destinata.

Perché questo è un percorso di contribuzione, non una richiesta di funzionalità

Dà anche alla community un percorso di contribuzione pulito. Un contributore non ha bisogno di riprogettare il prodotto per aiutare qui. Può scrivere una skill che emette un manifest per un tipo di artefatto, un atomo di revisione che propone intenti di modifica, un'estensione di manifest che aggiunge un campo che altre skill possono leggere, o un caso di test che afferma che gli ID di sezione restano stabili attraverso una rigenerazione. Ognuna di queste è una modifica piccola e mergeabile che rende un output meno opaco — e poiché il livello è testo semplice, due contributori che lavorano su un deck e una schermata mobile non devono coordinare un formato binario condiviso. Il livello di layout diventa un contratto pubblico, non una capacità privata sepolta dentro l'app.

Cosa fare dopo

Se questo è il tipo di problema su cui vuoi lavorare, contribuisci con una piccola skill o un plugin che renda un artefatto più facile da ispezionare. Inizia con un output concreto: una landing page, un deck o una schermata mobile. Aggiungi ID di sezione stabili, descrivi gli aspetti modificabili, emettili come JSON o Markdown insieme all'artefatto, e apri la PR con un artefatto prima/dopo così un revisore può vedere la differenza che fa un livello ispezionabile.

Questa è ancora una direzione, non una funzionalità rilasciata — il valore di nominarla ora è che le primitive esistono già, quindi il lavoro è additivo anziché una riscrittura.

Contribuisci con una skill.

Letture correlate

• 31 skill, 72 sistemi: come funziona la libreria di Open Design: le attuali primitive basate su file sotto la proposta
• Perché abbiamo costruito Open Design come un livello di skill, non come un prodotto: la forma di prodotto che rende possibili i contratti pubblici sugli artefatti
• L'alternativa open-source a Figma: dove finisce "abbandona il canvas" rispetto al leader di mercato che ha reso il canvas centrale