Il mio design system agentico è live. Il prototipo esce prima di Figma, e Figma lo riceve quando abbiamo già detto sì.

Finalmente è live il mio design system agentico. Il prototipo esce prima di Figma, e Figma lo riceve quando abbiamo già detto sì.

Due settimane per costruirlo, partendo dal design system che avevamo già in Figma. Questo è cosa c'è dentro, come stanno insieme i pezzi e cos'è cambiato nel modo di lavorare.

Cos'è davvero un design system agentico

Un design system tradizionale è scritto per le persone. Un componente ha un nome, qualche variante su una pagina Figma e un'idea condivisa dentro il team di quando si usa. Quell'idea vive nelle conversazioni, nelle review, nella testa di chi c'è da più tempo.

Un agente non ha niente di tutto questo. Non può sedersi in una review, non può chiedere cosa intendevamo e non può dedurre un'intenzione da uno screenshot. Se la regola non è scritta, per lui non esiste.

Quindi un design system agentico è lo stesso design system con una differenza: ogni regola che una persona applica per istinto è stata scritta in una forma che una macchina può leggere. Non documentazione nel senso solito, ma una specifica abbastanza precisa da poterci comporre sopra.

Nessuno di questi strumenti è il design system. Il design system sono le regole, e stanno in un posto che leggono sia le persone sia l'agente.

Cosa ho estratto da Figma

Sono partito da quello che c'era già e ne ho tirato fuori tutto quello che a un agente serve per rispettarlo al pixel.

Prima i token: colore, tipografia, spaziature, griglia, raggi ed elevazioni. Li ho estratti due volte. Una come valori e una come significati, perché un agente che conosce solo un codice esadecimale lo userà ovunque, mentre un agente che sa che quel token è il colore di superficie di una card elevata lo userà dove va usato.

Poi, per ogni componente, un contratto:

• A cosa serve il componente
• Quali varianti e stati ha
• Con cosa si può comporre
• Cosa non si deve mai fare con lui
• Quali regole di accessibilità deve rispettare

L'ultima parte è quella che ha richiesto più tempo, ed è anche quella che fa la differenza. Era quasi tutta conoscenza che nessuno aveva mai avuto motivo di mettere per iscritto.

Dove vive ogni pezzo

In Figma si continua a decidere come deve apparire. Su questo non è cambiato niente.

Token, contratti, codice, test e ogni decisione presa vivono in un repository. Quel repository è la memoria del sistema: è l'unico posto che fa fede, ed è quello che legge l'agente.

In Storybook si vede come ogni componente si comporta davvero. Ha smesso di essere il posto dove il design system è documentato per gli umani ed è diventato documentazione eseguibile e superficie di validazione.

Il prototipo prende forma in codice, dentro un playground in Next.js su Vercel. È lì che il lavoro diventa qualcosa su cui si può cliccare.

Claude è collegato a Figma e a Storybook via MCP. Legge tutto questo e orchestra il lavoro.

I controlli automatici fanno da giudice. Tipi, test e accessibilità devono passare prima che qualcosa entri. L'agente non decide se il proprio risultato è abbastanza buono.

Come nasce davvero una schermata

Il mio lavoro è rimasto quello di sempre, e anzi è tornato quello.

Raccolgo i requisiti, mi allineo sulle aspettative, studio il brand e capisco cosa deve fare quella pagina per vendere. Se il prezzo è alto, per esempio, il prodotto va raccontato di più: i materiali, la lavorazione, il motivo per cui costa quello che costa.

Poi chiedo a Claude quello che voglio, con la stessa precisione con cui lo chiederei a un designer del team. Niente prompt generici. Un brief.

Claude compone con i componenti che esistono. Se gliene serve uno nuovo prima cerca tra quelli che ci sono, poi me lo propone, e lo decido io. Quest'ordine conta: un agente libero di inventare componenti a richiesta forka il design system nel giro di un mese.

Il prototipo arriva nel playground. Lo guardiamo lì, io e il team, e il sì lo diciamo lì. Solo dopo finisce in Figma e in Storybook, già pronto per lo sviluppo, senza che qualcuno lo ridisegni.

Cosa resta umano

Il brief resta mio. Così come la decisione sui componenti nuovi, e il sì nel playground.

Un redesign completo che prima richiedeva un mese ora esce in una settimana. Il tempo che ho recuperato va sulla parte che nessun agente fa al posto mio: capire cosa deve ottenere quell'esperienza, come deve sentirsi chi la usa, dove vogliamo portare il prodotto. Strategia, esperienza utente, visione, e poi l'esecuzione.

Da adesso progettare e sviluppare un'esperienza digitale, per me, funziona così.

In sintesi

Un design system agentico non è uno strumento da adottare, è una specifica da scrivere. Estrai i token come significati e non solo come valori, dai a ogni componente un contratto che dichiari scopo, limiti e regole di accessibilità, tieni tutto in un repository che leggono sia il team sia l'agente, e lascia che siano dei controlli automatici a decidere cosa entra. L'agente compone; il brief, i componenti nuovi e il sì finale restano alle persone.