Il designer sta diventando anche sviluppatore?

Tra AI, prototipi sempre più vicini al prodotto reale e strumenti design-to-code, il confine tra progettazione e sviluppo si sta assottigliando. Ma questo significa davvero che un designer debba imparare a programmare?

Giovedì 10 settembre 2026

Negli ultimi anni il rapporto tra design e sviluppo è cambiato molto più rapidamente di quanto sembrasse possibile. Per molto tempo il processo è stato abbastanza lineare: il designer progettava, preparava il prototipo e poi consegnava tutto allo sviluppatore. Da quel momento iniziava una seconda fase, fatta di interpretazione, adattamento e implementazione.

Oggi questa separazione è sempre meno netta. Gli strumenti di progettazione si stanno avvicinando al codice, mentre gli strumenti di sviluppo stanno diventando più accessibili a chi arriva dal design. L’intelligenza artificiale accelera ulteriormente questo processo, perché permette di trasformare un’interfaccia in qualcosa di funzionante senza dover necessariamente partire da una pagina vuota e scrivere ogni riga di codice manualmente.

I numeri mostrano quanto il cambiamento sia concreto. Nel suo AI Report 2026, Figma rileva che in un solo anno la percentuale di designer coinvolti anche nelle attività di sviluppo è passata dal 21% al 41%. Nello stesso periodo, gli sviluppatori che partecipano alle attività di design sono aumentati dal 44% al 60%. Non significa che le due professioni siano diventate la stessa cosa, ma indica chiaramente che i confini tradizionali stanno diventando molto più permeabili. Figma

Il vecchio handoff sta perdendo importanza

Per anni abbiamo parlato di “handoff” come di un momento ben preciso del progetto. Il designer terminava il proprio lavoro, preparava specifiche, componenti, misure e comportamenti e consegnava tutto al team di sviluppo. In teoria era un passaggio ordinato. Nella pratica, spesso era l’inizio di una lunga serie di domande.

Come deve comportarsi questo componente in una situazione non prevista? Cosa succede se il testo è più lungo? Qual è lo stato di errore? Come si adatta questa schermata su una risoluzione intermedia? Questo valore è fisso oppure dinamico?

Molti problemi nascevano proprio perché design e sviluppo lavoravano in momenti diversi sullo stesso prodotto.

Oggi il modello sta cambiando. Figma descrive sempre più spesso un processo circolare, in cui design e codice non rappresentano più due estremi di una linea, ma due ambienti tra cui il lavoro può muoversi continuamente. Con Figma Make, per esempio, un designer può partire da un frame, trasformarlo in un prototipo interattivo basato su codice, modificarlo e continuare a iterare senza abbandonare completamente l’ambiente di progettazione. Figma

Il cambiamento non riguarda quindi soltanto gli strumenti. Cambia il modo in cui pensiamo al processo.

Il design non deve più necessariamente essere “finito” prima che inizi lo sviluppo.

Un designer deve quindi imparare a programmare?

È probabilmente la domanda più immediata. E secondo me la risposta è: dipende da cosa intendiamo per programmare.

Un UX/UI designer non deve necessariamente diventare uno sviluppatore frontend. Non deve per forza saper costruire un’applicazione complessa, gestire un backend, progettare un’architettura software o conoscere nel dettaglio ogni framework JavaScript.

Ma comprendere il funzionamento del codice è un’altra cosa.

Conoscere almeno i concetti fondamentali di HTML, CSS, responsive design, componenti, stati, variabili, dati e logiche condizionali può migliorare enormemente il modo in cui progettiamo un’interfaccia.

Non perché il designer debba sostituire lo sviluppatore, ma perché permette di progettare con maggiore consapevolezza.

Se sappiamo come funziona realmente un layout responsive, probabilmente eviteremo di progettare decine di schermate statiche senza considerare cosa succede tra un breakpoint e l’altro. Se comprendiamo cosa significa lavorare con componenti riutilizzabili, saremo più attenti alla coerenza del design system. Se conosciamo il concetto di stato, penseremo più facilmente a loading, errore, vuoto, disabilitato e successo.

Il codice, in questo senso, non diventa necessariamente una nuova professione. Diventa una nuova lingua da comprendere.

Capire il codice è diverso dallo scriverlo

Questa distinzione è importante.

Possiamo conoscere bene una lingua senza essere scrittori professionisti. Allo stesso modo, un designer può comprendere le logiche fondamentali dello sviluppo senza avere l’obiettivo di diventare uno sviluppatore.

Per un designer, sapere che una certa soluzione richiede una quantità sproporzionata di lavoro tecnico è utile. Capire che un componente può essere riutilizzato invece di essere ricostruito ogni volta è utile. Sapere che alcuni comportamenti apparentemente semplici possono diventare molto complessi quando entrano dati reali, permessi, errori e casi limite è utile.

Questa conoscenza cambia anche il confronto con gli sviluppatori.

La conversazione smette di essere semplicemente “questa è la schermata, realizzala così” e diventa più vicina a “questo è l’obiettivo che vogliamo raggiungere: qual è il modo migliore per costruirlo?”.

È una differenza enorme.

Perché un prodotto digitale non è un file Figma trasformato in codice. È il risultato di una serie di decisioni condivise.

Gli strumenti stanno cambiando il ruolo del designer

L’accelerazione più evidente arriva dall’intelligenza artificiale.

Figma Make permette già di generare codice funzionante attraverso il linguaggio naturale, ispezionarlo, modificarlo e continuare a lavorare sul prodotto nello stesso ambiente. Figma sta inoltre sperimentando flussi in cui il designer può lavorare direttamente su una codebase reale, apportare modifiche e arrivare fino alla creazione di una pull request. Figma

Questo scenario sarebbe sembrato molto meno realistico soltanto pochi anni fa.

Significa che un designer può iniziare a intervenire direttamente sul prodotto senza necessariamente conoscere ogni dettaglio tecnico dell’implementazione. Ma significa anche che diventa ancora più importante capire cosa sta facendo.

L’intelligenza artificiale riduce la barriera tecnica.

Non elimina la necessità di comprendere il risultato.

È lo stesso problema che abbiamo visto con la generazione delle interfacce: poter produrre qualcosa non significa automaticamente saper valutare se quel qualcosa è corretto.

Il rischio del “designer che fa tutto”

C’è però un rischio da evitare.

Quando gli strumenti rendono possibile fare più cose, è facile arrivare alla conclusione che una sola persona debba fare tutto.

Design, ricerca, copy, sviluppo, testing, analytics, strategia e magari anche gestione del prodotto.

Ma ampliare le proprie competenze non significa cancellare la specializzazione.

Uno sviluppatore esperto continuerà ad avere competenze che un designer non acquisisce semplicemente utilizzando un generatore di codice. Allo stesso modo, sapere utilizzare Figma non rende automaticamente uno sviluppatore un UX designer.

Le competenze profonde continuano ad avere valore.

La differenza è che oggi esiste una zona molto più ampia di sovrapposizione.

Il designer può arrivare più vicino al codice. Lo sviluppatore può intervenire prima nel processo di design. Il product manager può prototipare un’idea senza aspettare una fase dedicata.

Questa sovrapposizione può migliorare moltissimo il lavoro, a patto di non trasformarsi nella convinzione che tutte le professioni siano intercambiabili.

Dal mockup al prodotto reale

Uno dei vantaggi più interessanti di questa evoluzione è la possibilità di testare molto prima il comportamento reale di un’interfaccia.

Un mockup statico può nascondere molti problemi.

Una card sembra perfetta finché il titolo contiene tre righe invece di una. Una tabella funziona finché non arrivano cinquanta colonne. Un form è chiaro finché non dobbiamo gestire validazioni, errori, permessi e dati mancanti.

Quando il prototipo si avvicina maggiormente al prodotto reale, questi problemi emergono prima.

E questo può migliorare la qualità del design.

Gli strumenti code-backed permettono di sperimentare con contenuti più realistici, interazioni vere e comportamenti responsive senza aspettare necessariamente la fase finale dello sviluppo. Figma descrive proprio questa convergenza come un passaggio continuo tra canvas e codice, invece di un percorso a senso unico. Figma

Per il designer significa poter verificare meglio le proprie decisioni.

Non soltanto vedere come appare un’interfaccia.

Ma iniziare a capire come si comporta.

Cosa dovrebbe imparare davvero un UX/UI designer?

Se l’obiettivo non è diventare sviluppatori, quali competenze tecniche diventano allora più utili?

Secondo me alcune hanno un impatto molto maggiore di altre:

• comprendere la struttura di HTML e CSS;
• conoscere bene responsive design e breakpoint;
• capire il concetto di componenti e proprietà;
• conoscere stati e comportamenti dell’interfaccia;
• comprendere le logiche di un design system;
• sapere come vengono utilizzati dati reali;
• conoscere i principali vincoli tecnici del frontend;
• capire almeno a livello concettuale API, database e autenticazione;
• saper leggere una struttura di codice anche senza essere in grado di scriverla completamente;
• imparare a utilizzare gli strumenti AI senza trattare il codice generato come una scatola nera.

Non serve imparare tutto contemporaneamente.

Ma più comprendiamo il mezzo con cui il nostro progetto verrà costruito, più siamo in grado di progettare soluzioni realistiche.

La collaborazione resta la vera competenza

Forse il punto più importante non è quindi capire se il designer debba diventare anche sviluppatore.

La vera domanda potrebbe essere un’altra:

quanto deve essere in grado di lavorare con lo sviluppo?

Secondo il report Figma 2026, il 41% degli intervistati afferma che l’AI sta già cambiando il modo in cui i team collaborano, contro appena il 7% di due anni prima. Il cambiamento più interessante non è quindi soltanto l’aumento della produttività individuale, ma il modo in cui le competenze iniziano a mescolarsi durante la costruzione del prodotto. Figma

Un designer che comprende meglio lo sviluppo può comunicare in maniera più efficace.

Uno sviluppatore che comprende meglio il design può individuare prima problemi di esperienza.

E quando entrambi lavorano sul problema invece di limitarsi a difendere il proprio file o il proprio codice, il prodotto migliora.

Conclusioni

Il designer sta diventando anche sviluppatore? In parte sì, ma probabilmente non nel senso più letterale della domanda. Il cambiamento non consiste necessariamente nel trasformare ogni UX/UI designer in un frontend developer, ma nel rendere molto più sottile il confine tra ciò che viene progettato e ciò che viene costruito. Gli strumenti stanno facendo convergere canvas e codice, permettendo ai designer di arrivare molto più vicino al prodotto reale e agli sviluppatori di partecipare sempre prima alle decisioni progettuali.

Questo modifica inevitabilmente le competenze richieste. Capire come funziona un componente, cosa significa progettare un layout realmente responsive, come vengono gestiti gli stati o quali vincoli introduce un dato reale non è più una conoscenza marginale. Sono elementi che influenzano direttamente la qualità del design. Un designer non deve necessariamente sapere scrivere tutto il codice che serve per costruire un prodotto, ma comprendere almeno la logica con cui quel prodotto verrà realizzato può renderlo molto più efficace.

Allo stesso tempo, è importante non cadere nell’idea opposta: se l’AI permette a un designer di generare codice, questo non significa che la competenza dello sviluppatore sia diventata inutile. Gli strumenti possono ridurre la barriera di ingresso, automatizzare parti del lavoro e permettere a professionisti diversi di intervenire in territori che prima erano più lontani, ma la profondità delle competenze continua a contare. Un prototipo generato in pochi minuti e un prodotto robusto, accessibile, performante e mantenibile nel tempo rimangono due cose diverse.

Il vero cambiamento, quindi, potrebbe essere meno legato alla nascita di una figura professionale capace di fare tutto e molto più alla scomparsa di alcuni confini rigidi. Il designer non consegna più semplicemente un mockup allo sviluppatore. Lo sviluppatore non aspetta necessariamente che il design sia concluso per intervenire. Entrambi possono lavorare prima, insieme, sullo stesso problema.

Ed è probabilmente questa la direzione più interessante. Non designer che diventano sviluppatori o sviluppatori che diventano designer, ma professionisti che comprendono meglio il lavoro degli altri e riescono a muoversi con maggiore libertà tra progettazione e implementazione.

Per un UX/UI designer, quindi, imparare qualcosa di codice ha senso. Non perché debba cambiare mestiere, ma perché conoscere meglio il materiale con cui verrà costruito ciò che progetta gli permette di prendere decisioni migliori.

Il futuro del design potrebbe non essere scegliere tra canvas e codice.

Potrebbe essere imparare a lavorare bene con entrambi.