Guida completa a Figma Make e all'Intelligenza Artificiale per la generazione UI/UX e Wireframing 2026

Che cos'è Figma Make, che cosa genera davvero, come si collega al design system di un'azienda, quanto costa fra postazioni e crediti, che cosa si porta via chi esce e dove è la scelta sbagliata

Figma Make è il punto in cui lo strumento di design più diffuso al mondo ha smesso di produrre immagini di interfacce e ha iniziato a produrre interfacce. Si descrive un'idea, si allega eventualmente un frame già disegnato, e si ottiene un'applicazione che funziona nel browser: codice React e TypeScript vero, non un prototipo di rettangoli collegati fra loro. È una differenza di categoria, non di comodità.

Questa guida percorre lo strumento per intero: caratteristiche principali, vantaggi competitivi nel lavoro quotidiano di chi progetta interfacce, costi, esportazione e portabilità, alternative e confronto, strategie di crescita, qualità del codice generato e tendenze future. Alla qualità del codice è dedicata una sezione a parte, con i dati indipendenti disponibili: è la parte che nessuno racconta e che decide se quello che esce da un generatore può finire in produzione o no.

Due fatti da fissare subito, perché sono quelli che cambiano una decisione d'acquisto. Il primo: Make consuma crediti AI, e i limiti per postazione sono in vigore dal 18 marzo 2026 — non è una funzione inclusa nell'abbonamento a consumo illimitato, e generare un'applicazione da zero costa, secondo le stime ufficiali di Figma, oltre cento crediti. Il secondo: il viaggio è a senso unico. Il codice si scarica e si può inviare su GitHub, ma la documentazione dice esplicitamente che ciò che si modifica fuori non torna indietro, e che una versione funzionante del file Make non si riporta dentro Figma Design.

Che cos'è Figma Make, e che cosa non è

La definizione, presa alla lettera

La documentazione ufficiale lo chiama «uno strumento da prompt ad app, guidato dall'intelligenza artificiale, che permette di dare vita a idee e a progetti Figma esistenti sotto forma di prototipi funzionanti, applicazioni web e interfacce interattive». Ogni parola è scelta, e vale la pena prenderle sul serio.

Da prompt ad app significa che l'unità di partenza è una descrizione, non una tela. Progetti Figma esistenti significa che il vero terreno di gioco non è la generazione da zero ma la trasformazione di ciò che c'è già. Prototipi funzionanti significa che il risultato si usa, non si guarda: ha uno stato, reagisce, può parlare con un database.

Da Config 2025 alla disponibilità generale

Make è stato annunciato alla conferenza Config del maggio 2025, in versione di prova, insieme a Sites, Buzz e Draw. È uscito dalla fase di prova il 10 luglio 2025, con una distribuzione graduale: oggi è disponibile su tutti i piani, ma con un confine netto che va conosciuto prima di comprare.

L'uso pieno richiede una postazione completa su un piano a pagamento. Le postazioni per sviluppatori, per la collaborazione e per la sola visualizzazione, così come il piano gratuito, permettono di lavorare soltanto sulle bozze, con condivisione limitata. E soprattutto: la pubblicazione di un file Make richiede una postazione completa. Chi ha in mente di far usare Make al cliente con un accesso economico scoprirà che non può pubblicare nulla.

I modelli, dichiarati apertamente

È un punto di trasparenza che merita nota, perché nel settore è raro. Al lancio, il blog ufficiale scriveva che «Figma Make usa attualmente Claude 3.7 Sonnet» e che altri modelli sarebbero arrivati. Sono arrivati: oggi la documentazione elenca una selezione di modelli fra cui Claude Sonnet e Opus, i modelli di OpenAI e quelli di Google, più un modello predefinito che Figma si riserva di cambiare nel tempo.

La conseguenza pratica non è ideologica ma economica: modelli diversi consumano crediti diversi, e la documentazione stessa consiglia di usare il modello più leggero per le micro-modifiche e quello più potente per il lavoro complesso. Sceglierlo bene è una voce di risparmio, non una questione di preferenze.

Che cosa produce davvero

Qui conviene essere precisi, perché in rete circolano descrizioni approssimative. Il file principale documentato è App.tsx: il risultato è React con TypeScript, accompagnato da un foglio di stile CSS. La documentazione sui kit parla esplicitamente di generare «prototipi di alta qualità, componenti React e un file CSS». È prevista un'integrazione con un servizio di base dati per dare un backend all'applicazione.

Una precisazione di onestà: Tailwind è citato ovunque online ma non risulta dichiarato nella documentazione ufficiale. Confermati sono React, TypeScript e CSS; il resto va verificato sul proprio progetto prima di prometterlo a qualcuno.

La differenza fra Make, Figma Design e i prototipi classici

È la distinzione che chiarisce tutto il resto. Un prototipo classico di Figma Design collega frame statici con transizioni predefinite: simula un'interfaccia. Make produce codice che gira: ha logica, stato, dati.

Un file Make è inoltre un tipo di file a sé, che vive dentro Figma ma non dentro il file di Figma Design. E il rapporto fra i due è asimmetrico: la documentazione dice che non si può ottenere una versione funzionante del file Make dentro Figma Design, e che le modifiche fatte ai livelli in Figma Design non tornano nel file Make. Si può però copiare l'anteprima di Make come livelli di design, che è il ponte nell'unica direzione disponibile.

Le caratteristiche principali

Da che cosa si parte

Quattro punti di partenza, e non sono equivalenti. Un prompt testuale, per generare da zero. Un design allegato, che deve essere un componente o stare dentro un frame — e la documentazione raccomanda un design per volta, non un gruppo. Un'immagine. Oppure un modello di partenza.

Il secondo è quello che distingue Make da tutti i concorrenti: non si parte da una descrizione di come dovrebbe essere l'interfaccia, si parte dall'interfaccia già disegnata, con le sue spaziature e i suoi componenti. Chi ha già fatto il lavoro di design non lo butta.

L'iterazione, e la modifica che non costa crediti

L'iterazione normale avviene in chat: si chiede una modifica, il modello la esegue, si consumano crediti. Ma esiste una seconda strada, ed è il consiglio più utile di tutta questa guida sul piano economico.

La funzione di modifica puntuale permette di selezionare un elemento del prototipo e cambiarlo direttamente, e la documentazione ufficiale conferma che non consuma crediti: «non tutte le modifiche richiedono un prompt; per piccoli aggiustamenti visivi, saltare del tutto il modello è più veloce e più efficiente in termini di crediti». Lo stesso vale per la modifica manuale del codice e per la duplicazione del file.

Chi lavora così — struttura generata dal modello, rifinitura a mano — spende una frazione di chi chiede al modello di spostare un margine.

Il plan mode

È una novità del 2026 e risponde al problema tipico dei generatori: il modello parte a costruire prima di aver capito. Con il plan mode, Make produce prima un piano in un file plan.md che si legge e si corregge, e solo dopo si dà il via alla costruzione.

Tre precisazioni documentate: è riservato ai piani a pagamento, funziona con il modello predefinito o con il modello più potente di Anthropic ma non con quelli di Google, e consuma più crediti della costruzione diretta. Il conto conviene comunque su un lavoro complesso, dove il costo vero non è il piano ma la ricostruzione di ciò che è stato generato male.

I Make kit, cioè il design system dentro il generatore

È la funzione su cui Make non ha rivali, ed è anche la ragione per cui un'azienda che ha già un sistema di design dovrebbe guardarlo prima degli altri. Un Make kit mette insieme tre cose: i pacchetti npm del design system aziendale, cioè i componenti React veri; le variabili e gli stili importati dalle librerie Figma pubblicate; e delle linee guida testuali che spiegano al modello come usarli.

Il risultato è che ciò che viene generato nasce con i componenti dell'azienda, non con componenti inventati che assomigliano a quelli dell'azienda. È disponibile per le postazioni complete sui piani a pagamento; gli amministratori possono approvare i kit e renderli predefiniti. Il piano gratuito non accede alle librerie del gruppo.

Un limite dichiarato, da conoscere: «i Make kit al momento non supportano l'estrazione completa dei design token» — la sintassi delle variabili non viene preservata esattamente e il CSS estratto è una versione semplificata. Figma stessa consiglia di compensare con le linee guida testuali. E un chiarimento terminologico utile: Code Connect non è il ponte del design system per Make; è legato alla modalità sviluppatore e al server MCP. Per Make, il canale sono i kit.

La pubblicazione

Un file Make si pubblica e ottiene un indirizzo pubblico nella forma tre-parole-casuali.figma.site. Si può collegare un dominio personalizzato — con un tetto condiviso con Figma Sites, dieci domini sul piano Professional e nessun limite sui piani superiori — proteggere la pagina con una password ed escluderla dai motori di ricerca.

È il punto in cui Make smette di essere uno strumento di progettazione e diventa un modo di mettere online qualcosa. Con l'avvertenza che segue nella sezione sull'export: quello che si mette online resta ospitato da Figma.

Il resto della famiglia

Per collocare Make nel quadro, in una riga ciascuno: Figma Sites è ancora in prova aperta e serve a pubblicare siti; Figma Buzz è in prova aperta ed è orientato ai contenuti di marketing su larga scala; Figma Draw è lo strumento di illustrazione dentro Figma Design, ormai rilasciato; Figma Slides è stabile; il server MCP ufficiale è disponibile per tutti ed è il canale con cui gli assistenti esterni leggono il contesto di un progetto.

I vantaggi competitivi

Il design system come contesto: qui Make è solo

È il vantaggio strutturale, e va detto con chiarezza perché è l'unico argomento davvero difficile da replicare. Tutti i generatori producono interfacce plausibili; quasi nessuno produce interfacce conformi al sistema di design di quell'azienda.

La ragione è che il contesto necessario — i componenti reali, le variabili, le regole d'uso — vive dentro lo strumento di design, e Make è l'unico generatore che ci sta dentro. Per un'azienda con una libreria pubblicata, questa differenza si misura nel tempo che passa fra il prototipo e la cosa vera: con componenti inventati quel tempo è una riscrittura, con i componenti giusti è una revisione.

Dal prototipo statico al prototipo che funziona

Il secondo vantaggio riguarda che cosa si può chiedere a chi guarda. Un prototipo classico si prova come si prova una vetrina: si clicca dove il progettista ha previsto. Un prototipo funzionante si prova davvero — si scrive nei campi, si sbaglia, si torna indietro, si vede che cosa succede con dati veri.

Per una sessione con utenti reali è un salto di qualità del dato raccolto. E per una riunione di approvazione elimina la frase più pericolosa dei progetti digitali: «sì, ma non avevo capito che funzionasse così».

Un solo abbonamento, un solo posto

Il terzo vantaggio è organizzativo e vale soprattutto per gli studi piccoli: il design, il prototipo funzionante, i commenti, le librerie e il passaggio agli sviluppatori stanno nello stesso posto, con gli stessi permessi. Non c'è un secondo strumento da pagare, da imparare e in cui cercare il file giusto sei mesi dopo.

Va pesato onestamente: non è gratis, perché i crediti si consumano e possono costare più di un abbonamento a un generatore dedicato. Ma è un unico rapporto contrattuale, e per chi fattura a un cliente è una voce sola in fattura.

La velocità sul ciclo di approvazione

C'è un vantaggio commerciale poco citato e molto concreto. Presentare un prototipo funzionante in un primo incontro sposta la conversazione dal «mi piace / non mi piace» al «proviamo». È la stessa dinamica che vale per la grafica, moltiplicata: un'interfaccia che risponde convince a un livello diverso da un'immagine di un'interfaccia.

Con una conseguenza da governare, che è anche il rischio principale del mestiere oggi: più il prototipo sembra finito, più il cliente crede che sia quasi finito. La distanza fra un prototipo generato e un prodotto in produzione va dichiarata prima di mostrarlo, non dopo.

Dove il vantaggio si rovescia

• Nessun ritorno verso Figma Design. Ciò che si costruisce in Make non torna nel file di design come progetto modificabile: il ponte esiste solo nella direzione opposta, copiando l'anteprima come livelli.

• Nessun ritorno dal codice. La documentazione lo dice: «le modifiche che fai al codice non possono essere riportate automaticamente dentro Figma Make». Si copia e incolla, oppure si descrive la modifica in chat.

• L'invio a GitHub sovrascrive. È un invio a senso unico: ciò che si modifica nel repository non torna in Make e viene sovrascritto al prossimo invio. È il tipo di comportamento che distrugge una mattina di lavoro se non lo si conosce.

• I crediti finiscono. E finiscono più in fretta di quanto sembri: la sezione sui costi mette i numeri ufficiali.

• La qualità del codice non è documentata. Figma non pubblica né benchmark di prestazioni né dichiarazioni di conformità sull'accessibilità di ciò che viene generato. C'è una sezione dedicata, con i dati indipendenti che esistono sul tema.

Costi

I due livelli: postazione e crediti

Come in molti strumenti del 2026, il prezzo ha due componenti che si sommano, e chi ne guarda una sola sbaglia il preventivo.

Il primo è la postazione. Figma distingue postazioni complete, per sviluppatori, per la collaborazione e per la sola visualizzazione — queste ultime gratuite — e Make richiede una postazione completa su un piano a pagamento per l'uso pieno e per la pubblicazione. Sul listino: la pagina ufficiale espone in chiaro 12 dollari al mese per editor con fatturazione annuale sul piano Professional, 15 pagando mensilmente, e 45 al mese sul piano Organization con fatturazione annuale. La tabella per tipo di postazione e le cifre del piano Enterprise sono caricate dinamicamente e non sono leggibili nel testo della pagina: vanno verificate a schermo, e qui non le riportiamo.

Il secondo è il credito AI, ed è la parte nuova.

Quanti crediti si hanno, e quanti ne servono

I crediti si azzerano ogni mese e non si riportano; il piano gratuito e le postazioni di sola visualizzazione hanno anche un tetto giornaliero di 150. Dall'altra parte, le stime ufficiali di consumo — dichiarate da Figma come approssimative e riferite a inizio 2026 — sono queste:

Messe insieme, le due tabelle danno l'ordine di grandezza reale: con i tremila crediti di una postazione completa sul piano Professional, il blog ufficiale stimava da cinquanta a settanta prompt al mese. Non è poco e non è tantissimo: è abbastanza per due o tre progetti seguiti con metodo, ed è pochissimo per chi usa la chat come una gomma da cancellare.

Le date che contano, e i pacchetti aggiuntivi

Il conteggio dei crediti è stato annunciato il 9 dicembre 2025, i relativi listini sono comparsi l'11 marzo 2026 e i limiti sono in vigore dal 18 marzo 2026. È la data da tenere a mente leggendo qualsiasi confronto: tutto ciò che è stato scritto prima descrive un mondo in cui Make non aveva un costo marginale.

Sui pacchetti aggiuntivi va fatta una precisazione di trasparenza. Le cifre pubblicate a marzo 2026 — cinquemila crediti a 150 dollari una tantum o 120 al mese in abbonamento, con scaglioni superiori — sono state superate da un aggiornamento del 25 agosto 2026, che ha aumentato i crediti inclusi a parità di prezzo: il doppio sul piano Professional, 1,6 volte su Organization ed Enterprise. Da quel momento la documentazione rimanda al pannello di amministrazione e non pubblica più un listino. Chi cita i prezzi di marzo li sta citando come storici, anche senza saperlo.

Come si consuma meno

Quattro regole, tutte ricavate dalla documentazione ufficiale e tutte a costo zero.

1. Usare la modifica puntuale per gli aggiustamenti visivi: non consuma nulla.

2. Scegliere il modello in base al compito: quello leggero per le micro-modifiche, quello potente per il lavoro strutturale.

3. Ripulire la cronologia: la guida ufficiale avverte che conversazioni lunghe fanno crescere il consumo.

4. Scrivere prompt precisi: è la raccomandazione più banale e la più disattesa, e la documentazione la elenca fra le cause principali di spreco.

Il conto per un freelance

Un professionista che lavora da solo su un piano Professional con una postazione completa spende 144 dollari l'anno di abbonamento e ha tremila crediti al mese. Tradotto in lavoro: sono all'incirca due progetti al mese portati avanti con metodo, se la rifinitura si fa a mano e la chat si usa per la struttura.

Il confronto che conta non è con un generatore dedicato a venticinque o trenta dollari al mese, perché lì si compra un'altra cosa: lì si compra la generazione, qui si compra la generazione più lo strumento di design, le librerie e il passaggio agli sviluppatori. Il confronto sensato è con quanto costerebbe tenere due abbonamenti e spostare i file a mano fra i due.

Export, portabilità e round trip

Lo zip e GitHub

Sul fronte dell'uscita, Make è più generoso di molti strumenti di questa categoria — e la differenza rispetto a una piattaforma chiusa va riconosciuta.

C'è un pulsante per scaricare il codice in un archivio zip con tutti i file, disponibile per le postazioni complete e per quelle da sviluppatore. E c'è l'invio a GitHub, disponibile su tutti i piani, che crea un repository dedicato per quel file Make.

Il viaggio che non torna indietro

Le limitazioni, però, vanno lette con attenzione perché sono tutte nella stessa direzione.

La riga che conta di più è la quarta: se qualcuno mette mano al repository, le sue modifiche vengono sovrascritte al prossimo invio da Make. Non è un difetto nascosto, è documentato — ma è esattamente il genere di cosa che si scopre nel modo peggiore. Un file Make e un repository condiviso con un gruppo di sviluppo non convivono senza una regola esplicita su chi è la fonte di verità.

Make nel proprio codebase

È la funzione che risolverebbe il problema, ed è per questo che vale la pena conoscerne lo stato reale. Si chiama Make nel proprio codebase locale, permette di collegare un repository esistente, eseguire l'applicazione vera dentro Make e lavorare con rami e richieste di modifica.

Ma oggi è in prova chiusa con lista d'attesa, funziona solo su Mac e solo con la versione di prova dell'applicazione desktop, sui piani a pagamento, e richiede una configurazione tecnica iniziale — una cartella dedicata con alcuni script. In altre parole: è la direzione, non lo stato attuale, e chi progetta un flusso di lavoro oggi non può contarci.

Che cosa mettere nel contratto

Tre righe che evitano tre discussioni.

1. Che cosa si consegna: un prototipo funzionante ospitato da Figma, oppure un archivio di codice, oppure un repository — non sono la stessa cosa e non costano lo stesso.

2. Chi è la fonte di verità dopo la consegna: se il codice passa al gruppo di sviluppo del cliente, il file Make smette di essere aggiornato, e va detto.

3. Che cosa è stato generato, e che la verifica di sicurezza e accessibilità è un'attività separata. La sezione seguente spiega perché non è una clausola di stile.

Va aggiunto un avvertimento che Figma stessa mette per iscritto: Make può incorporare contenuti di terze parti presi dalla rete, e la responsabilità di avere i diritti su ciò che si pubblica resta dell'utente.

Alternative a Figma Make e confronto

Il confronto in una tabella

Make contro v0, Lovable e Bolt

È il confronto che conta, e la differenza non è la qualità del codice generato: è da dove parte il modello.

v0 — 30 dollari per utente al mese sul piano Plus — è la scelta naturale per chi vive nell'ecosistema Vercel: genera, versiona su GitHub e rilascia dentro la stessa filiera. Lovable, da 25 dollari al mese, punta più in alto: applicazioni complete con base dati e autenticazione, cioè un prodotto pubblicabile e non un artefatto di design. Bolt, sempre da 25, lavora nel browser senza configurazione ed è lo strumento più aperto sullo stack.

Tutti e tre partono da zero: costruiscono componenti nuovi, plausibili, che assomigliano al vostro sistema di design se glielo si descrive bene. Make parte dai vostri componenti reali importati come pacchetti, dalle vostre variabili e dalle vostre regole. Per un progetto nuovo senza un sistema esistente, questo vantaggio vale poco e i generatori dedicati costano meno. Per un'azienda con una libreria pubblicata e un marchio da rispettare, vale quasi tutto.

Make contro Google Stitch

Stitch merita un confronto a parte perché occupa una posizione diversa e perché è gratuito. Nato in Google Labs sulla base della tecnologia di Galileo AI, genera interfacce da un prompt o da un'immagine e produce due uscite: il codice front-end e un design che si incolla dentro Figma per essere rifinito.

È quindi uno strumento a monte di Figma, non un'alternativa dentro Figma: serve a generare rapidamente una direzione da portare poi nello strumento di lavoro. Va detto che costi e quote non sono pubblicati sulle pagine ufficiali — l'accesso è di fatto gratuito, ma i limiti dichiarati in rete non sono verificabili, ed è un esperimento di Labs, con tutto quello che comporta in termini di continuità.

Gli strumenti di design, e quando bastano

Non tutto ciò che serve a progettare un'interfaccia deve generare codice, ed è utile ricordarlo prima di pagare crediti per un wireframe.

Visily costa 11 dollari per editor al mese sull'annuale e genera schermate e wireframe da prompt: per la fase divergente è più che sufficiente e costa un decimo. Miro, a 20 dollari per membro sul piano Business, include i prototipi interattivi ed è la risposta giusta se il gruppo ci discute già i flussi. Penpot è gratuito e si installa sui propri server, ed è l'unica scelta per chi ha vincoli seri di sovranità del dato. Balsamiq, da 16 dollari per editor, resta il riferimento della bassa fedeltà deliberata.

Due segnalazioni per chi legge confronti datati: Uizard, acquisita da Miro, non pubblica novità dal giugno 2024 e non va proposta per nuovi progetti; Adobe non ha più nulla in questa categoria — XD è fuori vendita dal 2023 e non ha avuto un successore per la progettazione di interfacce.

Il dato indipendente

Su quanto questi strumenti siano realmente usati esiste una sola rilevazione indipendente e metodologicamente trasparente: l'indagine State of Prototyping di UX Tools, primavera 2026, su 1.478 rispondenti fra il 14 marzo e il 6 aprile 2026. L'uso settimanale dichiarato:

Due letture, entrambe utili. La prima: cinque dei dieci strumenti più usati ogni settimana sono ormai assistenti basati sull'intelligenza artificiale, e uno di questi è Make, che in nove mesi dalla disponibilità generale è entrato nell'uso settimanale di un terzo dei rispondenti. La seconda, meno raccontata: v0, Lovable, Bolt, Cursor e Replit non compaiono fra i primi dieci. Fra i designer, i generatori indipendenti restano di nicchia; quello che è entrato nell'uso di massa è il generatore che sta dentro lo strumento che già usavano.

Come si decide: cinque domande

1. Esiste già un design system pubblicato? Se sì, i Make kit sono l'argomento che gli altri non hanno. Se no, un generatore dedicato costa meno e fa lo stesso lavoro.

2. Il risultato deve entrare in un codebase esistente? Allora servono strumenti che lavorano nel repository, non un file ospitato.

3. Quante volte si itererà? Molte iterazioni significano molti crediti: il conto va fatto prima.

4. Chi userà il prototipo? Se il cliente deve pubblicarlo o modificarlo, serve una postazione completa, non un accesso economico.

5. Serve un'app o serve una decisione? Per decidere basta un wireframe a un decimo del costo; l'app funzionante serve quando la decisione è già presa e va validata.

Strategie di crescita usando Figma Make

Quando ha senso adottarlo

Tre situazioni in cui la scelta si difende da sola: quando esiste già una libreria di componenti e ogni prototipo deve nascere conforme; quando serve validare un flusso con utenti reali e un prototipo statico non basta a raccogliere un dato onesto; e quando si lavora già dentro Figma e l'alternativa sarebbe aggiungere un secondo strumento, un secondo abbonamento e un passaggio manuale di file.

Non si difende quando si deve semplicemente esplorare molte idee a basso costo — lì un wireframe a undici dollari al mese fa lo stesso lavoro — e quando il risultato deve entrare in un codebase reale mantenuto da un gruppo di sviluppo, perché l'invio a senso unico diventa un attrito permanente.

Il flusso che funziona per un freelance

1. Si struttura a bassa fedeltà, fuori da Make. È la fase in cui si decidono le schermate e il loro ordine, e non vale la pena spendere crediti per decidere che una schermata non serve.

2. Si disegna in Figma Design la schermata chiave, con i componenti giusti.

3. Si allega a Make — un design per volta — e si genera la versione funzionante.

4. Si rifinisce con la modifica puntuale, che non consuma crediti, tenendo la chat per le modifiche strutturali.

5. Si pubblica per la prova, con password se serve, e si raccolgono i commenti sull'uso reale e non sull'aspetto.

6. Si consegna con una nota chiara su che cosa è un prototipo e che cosa servirebbe per farne un prodotto.

Che cosa si vende al cliente

Non si vende «il prototipo», che è un artefatto, e nemmeno «l'app», che non lo è. Si vende una riduzione di rischio: la possibilità di scoprire, in due settimane e con qualche centinaio di euro, cose che altrimenti si scoprirebbero dopo sei mesi di sviluppo.

La proposta che funziona è una fase a prezzo fisso che finisce con tre cose: un prototipo che le persone hanno usato davvero, un elenco scritto di che cosa è emerso, e una stima di sviluppo basata su qualcosa di concreto. Chi vende così non compete sul prezzo orario e non deve giustificare quanto è stato veloce a produrlo.

Il rischio di consegnare la prima risposta plausibile

Va nominato perché è il rischio professionale specifico di questi strumenti, e non riguarda la tecnologia ma l'abitudine. Quando generare un'interfaccia credibile costa tre minuti, la tentazione è di consegnare la prima che funziona.

Il valore di un professionista sta esattamente nel non farlo: nel generare tre direzioni invece di una, nel togliere metà degli elementi che il modello ha messo perché stavano bene, nel chiedersi se la schermata serve. Un modello produce ciò che è statisticamente plausibile; un progettista produce ciò che è giusto per quel problema, e spesso sono cose diverse.

Il mercato italiano

Due osservazioni pratiche. La prima: in Italia il committente tipo non compra «prototipazione», compra la rassicurazione di non sbagliare l'investimento. La fase si vende meglio descrivendo il rischio che elimina — «prima di far scrivere il software, verifichiamo che le persone lo capiscano» — che nominando lo strumento.

La seconda riguarda un vincolo che in molti scoprono tardi e che la sezione sulle tendenze dettaglia: se il cliente rientra nell'ambito dell'European Accessibility Act, i requisiti di accessibilità si decidono nella struttura dell'interfaccia. Chi li mette a progetto fin dal wireframe fa un lavoro che vale di più — e che non si può rifare dopo ritoccando i colori.

La qualità del codice generato: che cosa dicono i dati

Perché questa sezione esiste

Figma non pubblica benchmark di prestazioni, dichiarazioni di conformità sull'accessibilità o certificazioni di idoneità alla produzione per ciò che Make genera. Non è una critica: nessun concorrente lo fa. Ma significa che chi deve decidere se quel codice può diventare un prodotto deve guardare altrove — e qualche dato indipendente esiste.

Sicurezza: il rapporto Veracode

Il riferimento più solido è il GenAI Code Security Report pubblicato da Veracode nel luglio 2025, che ha testato oltre cento modelli linguistici sulla generazione di codice. Il risultato principale: il 45% dei campioni prodotti ha fallito i test di sicurezza, introducendo vulnerabilità classificate nella lista OWASP delle più comuni.

La ripartizione per linguaggio dice qualcosa di utile a chi lavora sul web: Java 72% di fallimenti, C# 45%, JavaScript 43%, Python 38%. E sul cross-site scripting il dato è severo: fallimento nell'86% dei campioni rilevanti. La conclusione del rapporto è la frase che conviene ricordare: le prestazioni di sicurezza sono rimaste piatte — i modelli più recenti scrivono codice che funziona meglio, non codice più sicuro.

Le vulnerabilità osservate sul campo

Una ricerca della School of Cybersecurity and Privacy del Georgia Institute of Technology, divulgata nell'aprile 2026, ha scansionato oltre 43.000 avvisi di sicurezza trovando 74 casi confermati di vulnerabilità introdotte da codice generato, di cui 14 critiche e 25 ad alta severità — iniezione di comandi, aggiramento dell'autenticazione, richieste forzate lato server.

Il dato che colpisce è la curva: 18 casi in sette mesi a fine 2025, 56 nei primi tre mesi del 2026. Va attribuita per quello che è — una ricerca divulgata tramite comunicato, non un articolo sottoposto a revisione fra pari — ma l'ordine di grandezza è coerente con il rapporto precedente.

Accessibilità: il buco nei dati

Qui va detta una cosa scomoda: non esistono studi indipendenti verificabili sull'accessibilità del codice generato da questi strumenti. Nessuno ha misurato in modo pubblicabile quanti prototipi generati rispettino i criteri delle linee guida internazionali.

Per un pubblico europeo è la lacuna che costa di più, perché è esattamente l'area in cui dal 2025 esiste un obbligo. In assenza di dati, l'unica condotta difendibile è considerare l'accessibilità una verifica da fare, non una proprietà da presumere.

Che cosa significa in pratica

Non che questi strumenti non vadano usati: significa che il codice generato è una bozza avanzata, non un prodotto, e che fra la generazione e il rilascio va messa una fase di revisione — di sicurezza, di accessibilità, di manutenibilità — che qualcuno deve fare e qualcuno deve pagare.

Per chi vende progetti, è anche un'opportunità di posizionamento: mentre il costo della produzione crolla, il valore della verifica sale. Dichiararlo in preventivo come voce separata è più onesto e più redditizio che nasconderlo dentro un prezzo a corpo.

Tendenze future

Code Layers, e il canvas che esegue codice

La novità più significativa annunciata a Config 2026, il 23 e 24 giugno, si chiama Code Layers: porta codice funzionante come livello nativo sulla tela di Figma Design, in relazione bidirezionale con Make. È in prova chiusa con distribuzione avviata da luglio.

Se mantiene la promessa, risolve il limite più fastidioso descritto in questa guida — la strada a senso unico fra Make e il file di design — e cambia la natura della tela: non più un posto dove si disegnano rappresentazioni di interfacce, ma un posto dove convivono disegno e cosa funzionante. Nella stessa occasione sono arrivate Figma Motion, gli effetti shader personalizzati e i plugin generativi, tutti in prova aperta.

MCP e il design system interrogabile

La seconda tendenza è meno vistosa e più strutturale. Il server MCP di Figma, ormai disponibile per tutti, permette a un assistente esterno di leggere il contesto di un progetto: componenti, variabili, struttura. Il design system smette di essere una libreria da consultare a mano e diventa un contesto interrogabile.

È la stessa direzione dei Make kit, vista dall'altro lato: lì si porta il sistema dentro il generatore, qui si porta il sistema dentro qualsiasi strumento sappia parlare quel protocollo. Chi progetta oggi un design system dovrebbe pensarlo anche come qualcosa che una macchina leggerà.

Che cosa resta del wireframing

La domanda è legittima: se un prototipo funzionante costa minuti, che senso ha disegnare rettangoli grigi?

La risposta che regge è che il wireframe non serviva a risparmiare tempo, serviva a guardare la struttura senza la distrazione della superficie. Più un artefatto sembra finito, più chi lo guarda commenta la finitura: mostrare un prototipo curato quando la domanda era «servono davvero cinque passaggi?» sposta la conversazione sul posto sbagliato. Il rischio documentato del 2026 non è che il wireframe scompaia: è che si salti la fase di struttura e si consegni la prima risposta plausibile del modello.

Accessibilità e AI Act si decidono nella struttura

È il punto più operativo, e riguarda chiunque consegni interfacce in Europa.

Lo European Accessibility Act si applica dal 28 giugno 2025 ai prodotti e servizi immessi sul mercato, fra cui commercio elettronico, servizi bancari, libri digitali e trasporto passeggeri. L'esenzione per le microimprese — meno di dieci dipendenti e non più di due milioni di euro di fatturato o bilancio — vale per i servizi, e c'è un dettaglio che i professionisti sbagliano spesso: l'esenzione riguarda chi fornisce il servizio, non chi lo realizza. Un freelance che è microimpresa, se lavora per un cliente sopra soglia, ha il vincolo pieno.

I criteri che si decidono nella struttura e non nella grafica sono noti: gerarchia dei titoli, ordine e visibilità del focus, dimensione minima degli elementi da toccare, etichette persistenti nei moduli, alternative al trascinamento, nessuna informazione affidata al solo colore, contrasto di testi e componenti. Nessuno di questi si ripara in modo affidabile su un prototipo già generato.

A questo si aggiunge l'articolo 50 dell'AI Act, applicabile dal 2 agosto 2026, con un periodo di tolleranza fino al 2 dicembre 2026 per la marcatura dei sistemi preesistenti. Per chi progetta interfacce la conseguenza è concreta: se l'interfaccia interagisce direttamente con le persone — un assistente, un agente, un avatar — va dichiarato che si sta parlando con un sistema di intelligenza artificiale, fin dalla prima interazione e in modo chiaro e distinguibile. È un requisito di interfaccia e di microcopy, quindi si mette a wireframe: aggiungerlo alla fine significa rifare la schermata.

Che cosa non cambierà

Due cose. La prima: il collo di bottiglia non è più produrre. Quando un'interfaccia funzionante costa minuti e qualche decina di crediti, la risorsa scarsa diventa sapere che cosa costruire e per chi — che è la parte che si scopre parlando con le persone, non con un modello.

La seconda: fra un prototipo e un prodotto ci sarà sempre una differenza, e riguarda le cose che non si vedono in una dimostrazione — sicurezza, accessibilità, prestazioni sotto carico, manutenibilità dopo due anni. I dati della sezione precedente dicono che quella distanza, per ora, non si sta accorciando. Sapere quanto è larga, e dirlo al cliente, è esattamente il mestiere.

Domande frequenti

Che cosa genera esattamente Figma Make?

Genera codice vero, non un prototipo vettoriale: il file principale documentato è App.tsx, quindi React con TypeScript, accompagnato da un foglio di stile CSS, con la possibilità di collegare un backend per i dati. Il risultato è un'applicazione che funziona nel browser, con logica e stato, diversa dai prototipi classici di Figma Design che collegano frame statici con transizioni predefinite. Tailwind è citato spesso online ma non risulta dichiarato nella documentazione ufficiale: confermati sono React, TypeScript e CSS.

Figma Make è incluso nell'abbonamento?

In parte. L'uso pieno e la pubblicazione richiedono una postazione completa su un piano a pagamento: le postazioni per sviluppatori, per la collaborazione e per la sola visualizzazione, così come il piano gratuito, permettono di lavorare soltanto sulle bozze. Sopra alla postazione ci sono i crediti AI, che si consumano a ogni generazione: 500 al mese sul piano gratuito, 3.000 per una postazione completa su Professional, 3.500 su Organization e 4.250 su Enterprise, senza riporto da un mese all'altro. I limiti per postazione sono in vigore dal 18 marzo 2026.

Quanti crediti consuma una generazione?

Secondo le stime dichiarate da Figma come approssimative, cambiare un carattere tipografico costa circa 30 crediti o più, aggiungere interattività circa 75 o più, generare un'applicazione da zero oltre 100. Con i 3.000 crediti di una postazione completa sul piano Professional, il blog ufficiale stimava da cinquanta a settanta prompt al mese. Non consumano invece nulla la modifica puntuale degli elementi, la modifica manuale del codice e la duplicazione del file: è la via più efficace per spendere meno, insieme alla scelta di un modello leggero per le micro-modifiche.

Si può scaricare il codice prodotto da Figma Make?

Sì, in due modi. C'è un pulsante per scaricare il codice in un archivio zip, disponibile per le postazioni complete e per quelle da sviluppatore, e c'è l'invio a GitHub, disponibile su tutti i piani, che crea un repository dedicato. L'invio però è a senso unico: la documentazione avverte che le modifiche fatte su GitHub non tornano in Make e vengono sovrascritte al prossimo invio, sempre sul ramo principale. Esiste una funzione per lavorare direttamente sul proprio codebase, ma è in prova chiusa con lista d'attesa, solo su Mac e solo con la versione di prova dell'applicazione desktop.

Figma Make usa i componenti del nostro design system?

Sì, ed è la funzione che lo distingue da tutti i concorrenti. Si chiamano Make kit e mettono insieme tre cose: i pacchetti npm del design system, cioè i componenti React veri, le variabili e gli stili importati dalle librerie Figma pubblicate, e linee guida testuali che spiegano al modello come usarli. Sono disponibili per le postazioni complete sui piani a pagamento. Un limite dichiarato: i Make kit non supportano l'estrazione completa dei design token, quindi il CSS estratto è una versione semplificata e Figma consiglia di compensare con le linee guida.

Il codice generato si può mettere in produzione?

Va trattato come una bozza avanzata e non come un prodotto. Figma non pubblica benchmark di prestazioni né dichiarazioni di conformità sull'accessibilità di ciò che Make genera. Sui dati indipendenti disponibili: il GenAI Code Security Report di Veracode, del luglio 2025, ha testato oltre cento modelli e ha trovato che il 45% dei campioni falliva i test di sicurezza, con il 43% di fallimenti su JavaScript e l'86% sui campioni rilevanti per il cross-site scripting, concludendo che i modelli più recenti scrivono codice più funzionante ma non più sicuro. Sull'accessibilità del codice generato non esistono studi indipendenti verificabili. Fra generazione e rilascio va quindi messa una fase di revisione, che va prevista in preventivo.

Meglio Figma Make o v0, Lovable e Bolt?

Dipende da una cosa sola: se esiste già un design system. v0 costa 30 dollari per utente al mese, Lovable e Bolt partono da 25, e tutti e tre generano codice partendo da zero, costruendo componenti nuovi che assomigliano al vostro sistema se glielo si descrive bene. Figma Make parte invece dai componenti reali dell'azienda importati come pacchetti, dalle sue variabili e dalle sue regole. Per un progetto nuovo senza un sistema esistente, i generatori dedicati costano meno e fanno lo stesso lavoro; per un'azienda con una libreria pubblicata e un marchio da rispettare, la differenza è sostanziale.

Quanto è usato davvero Figma Make?

L'unica rilevazione indipendente e metodologicamente trasparente è l'indagine State of Prototyping di UX Tools, primavera 2026, condotta su 1.478 rispondenti fra il 14 marzo e il 6 aprile 2026. L'uso settimanale dichiarato vede Figma all'82,6%, Claude al 50,8%, ChatGPT al 48,2%, Claude Code al 38,4% e Figma Make al 34,8%, seguito da FigJam al 34,0%. Cinque dei dieci strumenti più usati ogni settimana sono ormai assistenti basati sull'intelligenza artificiale. Da notare anche ciò che manca: v0, Lovable, Bolt, Cursor e Replit non compaiono fra i primi dieci.

In sintesi

Figma Make è la risposta di Figma a una domanda che il mercato aveva già posto: se generare un'interfaccia funzionante costa minuti, perché continuare a disegnarne l'immagine? La risposta che dà è la più intelligente fra quelle disponibili, perché non compete sulla generazione — su quella i concorrenti dedicati costano meno — ma su ciò che il generatore sa: i componenti veri dell'azienda, le sue variabili, le sue regole.

Le tre cose da tenere a mente prima di adottarlo. Il prezzo ha due livelli: la postazione completa, indispensabile per usarlo e pubblicare, e i crediti AI, in vigore con limiti dal 18 marzo 2026, che su una generazione da zero superano i cento. Il viaggio è a senso unico: il codice esce in zip e su GitHub, ma non torna indietro, e l'invio sovrascrive ciò che altri hanno modificato — con Code Layers, annunciato a Config 2026, questa è la cosa che potrebbe cambiare per prima. E il codice generato è una bozza: i dati indipendenti sulla sicurezza del codice prodotto da modelli linguistici sono severi, sull'accessibilità non esistono affatto, e la verifica è una fase di lavoro, non una casella da spuntare.

Per un professionista, la conclusione operativa è breve e vale al di là dello strumento: quando produrre costa poco, il valore si sposta sul decidere che cosa produrre e sul verificare che ciò che è uscito regga. Chi sa fare queste due cose continuerà a valere più del generatore che usa — e potrà scegliere quello che preferisce.