Google standardizza il design per le macchine.

Google Labs ha rilasciato in open source DESIGN.md, un formato pensato per descrivere l'identità visiva di un prodotto in modo che un agente di codice possa rispettarla senza tirare a indovinare. L'annuncio è apparso sul blog ufficiale di Google il 21 aprile 2026, in concomitanza con la pubblicazione della versione 0.1.0 del repository google-labs-code/design.md su GitHub. Vale la pena leggerlo per ciò che implica, non per ciò che promette.

Cosa è davvero DESIGN.md

La struttura è semplice. Un file di testo con due strati: in alto, un blocco YAML che dichiara i token del sistema — colori in esadecimale, dimensioni in px o rem, tipografia, raggi di bordo, definizioni di componenti — con un sistema di riferimenti tra token; sotto, prosa in Markdown che spiega le scelte e il loro perché. Nasce per essere letto da un agente prima ancora che da un essere umano. Il pacchetto include una CLI con quattro comandi essenziali: lint per validare il file e controllare il contrasto secondo le linee guida WCAG, diff per confrontare versioni, export per emettere Tailwind, CSS e tokens W3C DTCG, spec per restituire la specifica del formato.

Il senso operativo è spostare un'informazione che oggi vive nelle teste dei designer, nelle slide del brand book e in cartelle Figma protette dietro permessi, dentro un singolo file di testo che vive accanto al codice. Un agente che genera un'interfaccia non deve più dedurre la palette da uno screenshot o ricordare il font giusto: lo legge, e se sbaglia il linter glielo dice.

Un esempio minimo di come appare in pratica un DESIGN.md, semplificato per leggibilità:

---
brand: Acme
version: 1.2.0
tokens:
  color:
    primary: "#0066FF"
    primary-hover: "{color.primary | darken(0.1)}"
    page-bg: "#FFFFFF"
    page-text: "#0A0A0A"
  spacing:
    md: 16px
    lg: 24px
  typography:
    h1:
      size: clamp(2rem, 5vw, 4rem)
      weight: 800
      family: "Inter"
  components:
    btn-primary:
      bg: "{color.primary}"
      color: "#FFFFFF"
      padding: "14px {spacing.lg}"
      hover-bg: "{color.primary-hover}"
---

## Perché primary è blu

Il blu è il colore delle reti di trasporto pubblico europee dal 1968. Acme
opera nel comparto logistico-trasporti: il nostro target legge il blu come
"affidabilità funzionale", non come "tecnologia". La scelta è coerente
con la coda di brand recognition.

## Quando NON usare btn-primary

Mai più di uno per fold. Mai in colonne di tabella (riduce la leggibilità).
Mai sopra un'immagine senza overlay scuro (contrasto sotto WCAG AA).

Sono cinquanta righe che fanno il lavoro di un brand book PDF da sessanta pagine, con un vantaggio aggiuntivo: un agente AI può consumarlo direttamente e generare codice corretto senza alcuna interpretazione visiva. La parte prosaica ("Perché primary è blu"), spesso scartata come accessoria, in realtà è quella che permette al modello di prendere decisioni intelligenti sui casi non coperti dai token: se serve un colore di alert mai dichiarato, il modello legge la narrativa e capisce che deve restare nel registro "affidabilità funzionale", non saltare a un rosso emozionale che spaventa.

Cosa cambia rispetto a Design Tokens W3C

Per chi segue il dossier degli standard di design, la domanda ovvia è: cosa aggiunge DESIGN.md a quello che già esisteva con i Design Tokens W3C (DTCG)? La risposta è in tre punti. Primo: i Design Tokens W3C sono solo i token — un JSON strutturato di colori, spaziature, tipografia. DESIGN.md ingloba i token nello stesso file ma aggiunge il contesto narrativo che nessun JSON struttura naturalmente: perché primary è blu, quando non usare btn-primary, quali sono le eccezioni accettabili. Un agente di codice competente sa che i token gli dicono "cosa", la prosa gli dice "quando" e "perché".

Secondo: DESIGN.md include la CLI per validare il file, esportare verso target diversi e fare diff fra versioni. I Design Tokens W3C lasciano la validazione a chi adotta lo standard. DESIGN.md è opinionato: vuole che tu validi il contrasto, conti i token orfani, controlli i riferimenti circolari. Opinionato significa più rigido ma anche più consumabile out-of-the-box.

Terzo, e forse più importante: DESIGN.md è scritto da Google. I Design Tokens W3C sono un consorzio. Tradotto: l'adoption curve sarà molto diversa. Un formato spinto da una singola Big Tech con CLI propria e agenti che lo riconoscono nativamente entra in pratica in sei mesi. Uno standard di consorzio entra in cinque anni o non entra. Non è un giudizio sulla qualità — è un'osservazione sulla velocità di adozione di mercato.

Tre angolature che contano

La prima: stiamo assistendo alla nascita di una nuova classe di artefatti, i file pensati per essere letti da macchine prima che da persone. README, AGENTS.md, ora DESIGN.md. Ogni dominio dell'azienda — vendita, design, legale, processo interno — finirà compresso in un file dichiarativo con front matter strutturato. Chi guida un'azienda dovrebbe abituarsi all'idea che il proprio brand book, oggi un PDF di sessanta pagine, fra poco sarà un documento di duemila righe in formato testuale. Più scomodo da impaginare, incomparabilmente più utile.

La seconda: il fatto che Google rilasci la specifica come standard aperto, con licenza permissiva e CLI indipendente da Stitch, è una mossa precisa. Non sta vendendo un prodotto, sta provando a fissare un protocollo. Chi adotta DESIGN.md per primo si trova di fatto allineato con qualunque agente futuro sia addestrato a riconoscerlo — e Google ne addestrerà parecchi. È la stessa logica con cui i robots.txt del 1994 hanno determinato venticinque anni di indicizzazione: chi ha messo il file, è stato rispettato.

La terza: la specifica è in versione 0.1.0, dichiaratamente alpha, con avvertenza esplicita che il formato cambierà. Tradotto: chi aspetta la versione 1.0 stabile arriverà tardi. Chi adotta ora paga un costo di manutenzione, ma compra opzionalità. È un calcolo da fare a freddo, non un motivo per ignorare l'annuncio.

I limiti della v0.1.0 (e cosa serve oltre)

DESIGN.md nasce per il design visuale: colori, spacing, tipografia, componenti UI di base. Coperto bene. Ma un sistema brand completo include almeno altri quattro contratti che la specifica attuale non tocca:

• Componenti complessi · anatomia + varianti + stati. Un bottone "btn-primary" è facile da dichiarare in YAML. Una card di blog post con header + media + body + footer, con varianti per featured / regular / sponsored, con stati hover / focus / loading / error, richiede una struttura che YAML piatto non gestisce naturalmente. Servirà un secondo file (COMPONENTS.md?) o un'estensione della specifica.
• Content types. Cos'è un "blog post"? Un "case study"? Una "persona"? Un agente che genera contenuto ha bisogno di sapere lo schema dei tipi di contenuto, non solo come renderizzarli. DESIGN.md non se ne occupa.
• Page templates. Una homepage è hero + 5 sezioni + footer. Un blog index è grid + paginazione. Una FAQ è Q&A list. La sequenza dei componenti su una pagina è un contratto a sé.
• Voce e copy. Quali parole usare, quali evitare, qual è il tono. DESIGN.md descrive il colore di un bottone ma non cosa scriverci sopra.

Chi adotta DESIGN.md oggi sta facendo un investimento parziale. È un buon investimento — il pezzo che copre è quello che si tocca per primo — ma il sistema completo richiede una famiglia di file machine-readable, non un unico file. Aspettarsi che la 1.0 di DESIGN.md copra tutto sarebbe miopia. Aspettarsi che la 0.1.0 sia abbastanza per sostituire il brand book sarebbe sopravvalutazione.

La posizione di Jigen

Il nostro mestiere è portare in produzione un'automazione AI dentro un'azienda in ventuno giorni. Quando una squadra di pochi team entra in un cliente e deve far parlare un agente con un'interfaccia, un set di componenti, un tono di voce visivo, il problema reale è sempre lo stesso: la fonte di verità del brand è dispersa. Tre file Figma, due Notion, un manuale del 2022 in PDF, un designer che se lo ricorda. Ogni iterazione costa riconciliazione. DESIGN.md, anche nella sua forma immatura, dà finalmente un punto di ancoraggio: un singolo file che l'agente legge ogni volta, che il linter verifica, e che resta in versione assieme al codice.

Il punto non è che DESIGN.md sia perfetto. È che cristallizza un movimento già in corso: le aziende che vinceranno i prossimi cinque anni avranno il proprio sistema di design, il proprio sistema di vendita, il proprio processo di onboarding scritti in formati strutturati che un agente può consumare senza intermediari. Tutto ciò che resta in PowerPoint diventerà inerte.

Lo abbiamo già visto sul nostro Design System interno. Il DS Jigen è composto da pagine HTML di documentazione narrativa (per umani che leggono) più una famiglia di file machine-readable (tokens.json, components.json, glossary.json, content-types.json, page-templates.json, più un llm-porter-playbook che dichiara l'ordine di lettura). La logica è la stessa di DESIGN.md, e dimostra qualcosa che vale la pena dire ad alta voce: una macchina che produce codice o copy non è meno esigente di un designer. Anzi, è più rigorosa, perché non completa con il "buon senso" — completa con quello che trova. Se la fonte è ambigua, l'output è ambiguo.

Come si scrive un DESIGN.md la prima volta

Per chi parte da zero, il percorso è prevedibile. Tre o quattro mezze giornate spalmate su una settimana, non un progetto da preventivare:

Sessione 1 · Token colore + WCAG. Tutta la palette del brand scaricata da Figma o ricostruita da uno screenshot, convertita in hex, dichiarata come token. Per ogni colore, calcolare il contrasto contro background di riferimento (chiaro, scuro, eventuale variante pastel). Le coppie sotto AA vanno corrette o annotate come "decorative only". È il momento in cui emergono incoerenze del brand book che nessuno aveva mai nominato — accade quasi sempre.

Sessione 2 · Spacing + tipografia. La scala di spaziatura (4/8/12/16/24/32/48px) dichiarata come token. La scala tipografica con font-family, size, weight, line-height, letter-spacing per ogni ruolo: H1, H2, H3, body, caption, eyebrow. Pubblicare anche i token che si usano nelle eccezioni rare — meglio averli scritti e non usati, che doverli inventare di volta in volta.

Sessione 3 · Cinque componenti core. Bottone (variants primary/secondary/ghost), card, input form, badge, nav. Per ognuno: anatomia, stati, regole di composizione, anti-pattern noti. È la sessione che richiede il designer in carne e ossa, perché alcuni dettagli (come gestire un bottone disabled, dove vive un focus ring) non si possono inferire da nessuno screenshot.

Sessione 4 · Prosa di accompagnamento. Per ogni scelta non ovvia, due-tre frasi che spiegano il perché. Questa è la sezione che la maggior parte delle aziende salta — "si capisce dal token, no?" — e che in realtà è quella che permette a un agente di prendere decisioni intelligenti quando gli capita un caso fuori catalogo.

A fine settimana c'è un file che vive accanto al codice, viene versionato, e può essere consumato da qualunque agente di codice. Costo: ~20 ore di lavoro distribuite. Beneficio: ogni iterazione futura di brand-allineamento costa minuti invece di giorni.

Test rapido · il tuo brand è già machine-readable?

Una griglia diagnostica per il vertice di un'azienda che vuole sapere a che punto è. Cinque domande:

1. Esiste un file di testo (qualsiasi formato) che dichiara la palette completa del brand? Sì → punto 2. No → c'è la prima sessione da fare.
2. Esiste un file che dichiara la scala tipografica completa, con font-family + size + weight per ogni ruolo? Sì → punto 3. No → c'è la seconda sessione.
3. Per ogni componente UI principale, esiste una descrizione strutturata di varianti, stati, regole di composizione? Sì → punto 4. No → c'è la terza sessione.
4. Esiste un documento di prosa che spiega le scelte di brand non ovvie (perché blu e non rosso, perché Inter e non Garamond)? Sì → punto 5. No → c'è la quarta sessione.
5. Un agente di codice (Claude, GPT, Gemini, un copilot interno) può consumare questi file senza dover prima essere "spiegato" da una persona? Sì → sei machine-readable, congratulazioni. No → l'ultima sessione consiste nel renderli consumabili, tipicamente convertendo da PDF o slide a YAML/JSON/Markdown.

Cinque sì su cinque: il brand è pronto per il 2026 e oltre. Tre o quattro sì: sei a una settimana di lavoro dall'esserlo. Due o meno: c'è un debito strutturale che ogni settimana paga in iterazioni dispersive — e che, fra sei mesi, sarà ancora più costoso da saldare perché nel frattempo gli agenti staranno facendo più cose, ognuna delle quali costerà riconciliazione manuale.

Implicazione concreta

Per un fondatore o un amministratore delegato la domanda da porsi questa settimana è una sola: se domani mattina un agente AI dovesse generare la prossima landing page, il prossimo template di email, il prossimo dashboard, da quale file leggerebbe colori, tipografia e regole di componente? Se la risposta è "nessuno, chiediamo al designer", l'azienda è fuori standard. Non c'è bisogno di adottare DESIGN.md oggi; c'è bisogno di accettare che il brand book di domani sarà un file di testo, e di iniziare a scriverlo. Il costo è un pomeriggio. Il costo del non farlo è ogni iterazione futura pagata in ore di rilavorazione.

Google ha pubblicato una specifica alpha e una CLI di poche centinaia di righe. L'evento sembra minore. Non lo è. È il primo standard pubblico di un protocollo che, fra sei mesi, sarà presupposto silenzioso di qualunque agente di design.

Spunto: Google Labs, "Stitch app's DESIGN.md format is now open-source for designers", blog.google, 21 aprile 2026 — leggi l'annuncio ↗ e il repository su GitHub ↗. Lettura Jigen: DESIGN.md non è uno strumento per designer — è uno strumento per agenti di codice che devono rispettare un'identità senza tirare a indovinare. È un passo lungo la stessa direzione del nostro Design System interno, che già oggi espone una famiglia di file machine-readable (tokens / components / content-types / page-templates / glossary / playbook). Adottarlo presto significa allinearsi al protocollo che fra sei mesi sarà presupposto silenzioso. Aspettare la 1.0 stabile significa arrivare dopo che altri si saranno già messi in catalogo.