Gli strumenti generativi ci fanno risparmiare tempo prezioso, ma finiscono anche per occuparsi della progettazione al posto nostro. La domanda rimane: quali compiti possiamo delegare loro senza compromettere la nostra competenza e quali, per quanto noiosi e dispendiosi in termini di tempo , sono quelli che plasmano il nostro sviluppo?

Ho partecipato al keynote di Figma Config 2026. Gli annunci si susseguivano senza sosta: shader generati da una semplice descrizione, una vera e propria timeline di animazione integrata nella tela, plugin creati definendo un intent, un agente in grado di eseguire interi flussi di lavoro. Sono rimasto sbalordito. Riuscivo già a immaginare le applicazioni: risparmio di tempo, risultati più convincenti e clienti più coinvolti.

E poi, all'improvviso, ho capito . Con un semplice comando, Figma ha fatto quello che facevamo noi agli inizi della nostra carriera.

Mi sono rivisto anche a dodici anni, il giorno in cui ho scaricato Photoshop. Ho imparato da solo, per tentativi ed errori: ritoccando una foto, progettando un poster, animando, cercando per ore l'effetto giusto, la tipografia giusta, la texture giusta, imparando a lavorare con livelli e maschere. Ricordo soprattutto la gioia che provavo dopo, quando, dopo diversi tentativi falliti, finalmente funzionava. E spesso, è stato proprio sbagliando che ho scoperto qualcos'altro: un processo inaspettato, un risultato che non avevo cercato e che alla fine ho preferito. Quelle ore di creazione, errori inclusi, non sono state solo un addestramento tecnico. È lì che si sono formati il ​​mio occhio , la mia tecnica , la mia logica di designer.

Oggi, chi è agli inizi non ha necessariamente bisogno di seguire quel processo. Descrive ciò che desidera – un effetto, un'animazione, un prodotto, un'interfaccia – e lo strumento lo crea per lui. Il tempo risparmiato è reale. Ma mi pongo una semplice domanda: se non creiamo più le cose da soli, come facciamo a imparare? E in definitiva, è davvero necessario saper fare le cose per diventare un bravo designer?

Giudicare e agire: distinzione e dipendenza

Un designer esperto che rifiuta un progetto non sempre tocca il file: nota che la gerarchia tipografica è debole, che un volume manca di tensione, che la navigazione non è intuitiva. Vede cosa va corretto, anche se non sempre è in grado di implementare la correzione da solo. Ma il suo occhio si è affinato durante l'esecuzione. Giudicare e creare sono due competenze diverse. Lo sviluppatore che esamina il codice generato in pochi secondi si trova nella stessa situazione: giudica senza scrivere, ma può farlo solo perché ha scritto prima.

Perché questo occhio , anche quando sembra un dono, si acquisisce . Si forma concependo, fallendo e arbitrando, progetto dopo progetto, per anni. Questa è l'intera tesi di Dewey: non impariamo ricevendo, impariamo facendo, e poi sperimentando le conseguenze delle nostre azioni. Bourdieu chiama questo talento incarnato , questo "senso del gioco" che nessuna regola trasmette e che solo una prolungata immersione stabilisce, habitus. Rumi, molto prima di loro, aveva già contrapposto la conoscenza ricevuta dall'esterno, che paragonava all'acqua convogliata attraverso un tubo e che alla fine ristagna, alla conoscenza verificata da sé, che sgorga come una sorgente e rimane vibrante. Munari, dal canto suo, ci ricorda la prospettiva del creatore: l'immaginazione non nasce dal nulla, cresce con ciò che si padroneggia. Concepite diventa facile, diceva, quando si sa come farlo.

Non tutti i compiti che richiedono molto tempo sono uguali.

È qui che sta la vera differenza. Alcune attività sono noiose e superflue : ritagliare, ridimensionare un centinaio di elementi visivi, esportare varianti, rinominare i livelli, aggiornare un sistema di progettazione su trenta schermate, collegare i link di navigazione in un prototipo. Le comprendiamo fin dalla prima schermata; le successive ventinove non ci insegnano nulla. Automatizzarle non aggiunge nulla alla nostra formazione.

Altre attività sono ardue perché ci plasmano : comporre un layout da zero, perfezionare la forma di un prodotto, progettare un percorso esplorando diverse alternative, trovare la giusta gerarchia delle informazioni e, soprattutto, realizzare con successo una transizione o un effetto complesso: cercare, commettere errori, ricominciare da capo, finché non ne comprendiamo il funzionamento. Queste ore "perse" affinano il nostro occhio, la nostra tecnica e, gradualmente, la velocità con cui le eseguiamo. Affrettarsi significa ottenere il risultato senza comprenderlo a fondo o padroneggiarlo.

Il criterio dipende dal livello di esperienza: un compito che rappresenta un valido allenamento per un principiante diventa superfluo per un dipendente senior che lo ha svolto migliaia di volte. Questa è la logica e la responsabilità del management: un buon manager assegna un compito ingrato a un dipendente junior non per efficienza, ma perché è lì che cresce. Se l'IA assorbe questi compiti di formazione, il dipendente junior perde il suo terreno di apprendimento . Non produce né giudica a sufficienza per sviluppare le proprie competenze o il proprio giudizio. Freire contrapponeva già il deposito passivo della conoscenza, in cui le informazioni vengono riversate in una mente che le riceve senza agire, alla prassi , in cui azione e riflessione si alimentano a vicenda. Morin aggiunge che il giudizio è una facoltà che si allena: una mente ben formata, capace di collegare idee e individuare errori, non si costruisce accumulando risposte preconfezionate. Un recente sondaggio condotto da Microsoft Research e Carnegie Mellon supporta questa idea: i professionisti che mantengono uno sguardo critico sulle produzioni dell'IA sono coloro che hanno fiducia nelle proprie capacità.

Senza fare il profeta dell'estinzione

Non si tratta di annunciare la fine di tutto, come quando si pensava che la stampa avrebbe ucciso la scrittura o la fotografia la pittura. Ogni volta, il vecchio è sopravvissuto, e spesso ha acquisito nuovo valore. Il lavoro del designer lo dimostra già: quando la produzione diventa abbondante e accessibile, il valore si sposta altrove.

Il gesto , innanzitutto, non scompare: cambia status . Baudrillard lo illustra bene: in un mondo saturo di copie senza originali, ciò che diventa raro acquista valore. Il fatto a mano, il processo visibile , la traccia del tentativo e dell'errore riacquistano valore proprio perché sono diventati l'eccezione. Un'interfaccia generata in tre secondi è a malapena distinguibile da mille altre; ciò che la rende unica è il terreno esplorato, gli utenti osservati, i prototipi scartati prima di questa. Ciò che si credeva perduto ritorna attraverso il suo valore.

L'impatto, a quel punto, diventa determinante. Come ci ricordava Papanek mezzo secolo fa, un progetto non si giudica dal fascino della sua forma, ma dalle sue conseguenze ecologiche, sociali e politiche . Ciò che distinguerà un'opera dall'altra domani avrà meno a che fare con la qualità della superficie che con le domande che l'hanno preceduta. Per chi? A quale costo? Con quale cura? Mentre la macchina assorbe l'esecuzione, ciò che rimane al progettista è proprio ciò che Papanek identificava come l'essenza della professione: la responsabilità di ciò che si porta nel mondo.

Que faire

Il primo compito del progettista, e soprattutto del manager, è ora quello di stabilire le priorità . Quali compiti dovrebbero essere delegati alla macchina senza perdere nulla? Quali dovrebbero essere mantenuti, non per nostalgia dell'atto fisico, ma perché contribuiscono alla formazione della persona che li esegue? Automatizzare un compito tedioso senza considerare ciò che ha insegnato al dipendente junior significa confondere il risparmio di tempo con il progresso.

Findeli propone il seguente criterio: nel design, si pensa veramente solo agendo , all'interno di un progetto reale. Proteggere la formazione, quindi, non significa vietare gli strumenti. Significa preservare, in ogni percorso di apprendimento, i momenti in cui si progetta dall'inizio alla fine, con sufficiente frequenza e per un tempo adeguato, affinché la mano , l' occhio e la mente possano svilupparsi insieme.

Forse, quindi, la vera domanda non è "dobbiamo sapere come farlo?", ma quella che dovremmo porci prima di ogni compito che affidiamo alla macchina: è tempo che risparmiamo o conoscenza che perdiamo?

riferimenti

• Baudrillard, Jean. Simulacri e simulazioneParigi, Galilea, 1981.
• Bourdieu, Pierre. PraticitàParigi, Edizioni di Minuit, 1980.
• Dewey, John. L'arte come esperienza. Trad. J.-P. Cometti et al., Parigi, Gallimard, coll. « Folio Essais », 2010 [ed. originale L'arte come esperienza, 1934].
• Findeli, Alain. “Ricerca basata su progetti: un metodo per la ricerca nel design”. Atti del primo Simposio sulla Ricerca nel Design, Swiss Design Network, Basilea, 2005.
• Freire, Paulo. Pedagogia degli oppressi. Parigi, La Découverte, 2001 [edizione originale] Pedagogia degli oppressi, 1968].
• Lee, Hao-Ping (Hank), Advait Sarkar, Lev Tankelevitch, Ian Drosos, Sean Rintel, Richard Banks e Nicholas Wilson. "L'impatto dell'IA generativa sul pensiero critico: riduzione dello sforzo cognitivo e effetti sulla fiducia auto-riferiti da un sondaggio sui lavoratori della conoscenza." Atti della conferenza CHI del 2025 sui fattori umani nei sistemi informaticiYokohama, ACM, 2025, pp. 1-22. DOI: 10.1145/3706598.3713778. PDF ad accesso aperto: https://www.microsoft.com/en-us/research/wp-content/uploads/2025/01/lee_2025_ai_critical_thinking_survey.pdf
• Morin, Edgar. La mente ben formata. Ripensare la riforma, riformare il pensiero.. Parigi, Seuil, 1999.
• Munari, Bruno. Da cosa nace cosa. Supportato da una metodologia softwareRoma-Bari, Laterza, 1981.
• Papanek, Victor. Progettare per il mondo reale: ecologia umana e cambiamento socialeNew York, Pantheon Books, 1971.
• Rumi, Jalal ad-Din. Mathnawi, libro IV. XIII secolo.

 

Hend Daoud Metoui, Progettista di prodotto presso UX-Republic