Quando lavorare tanto non significa capire di più.
Perché produrre decine di deliverable impeccabili ti sta allontanando dal vero obiettivo.
Un articolo di: Virginia Norrito
La favola che ci siamo raccontati
Per molto tempo il design è stato incorniciato come un sistema quasi deterministico. Framework come il Double Diamond, il Design Thinking o i modelli “discover–define–develop–deliver” hanno contribuito a costruire una narrativa potente: se segui il processo, arrivi a una buona soluzione.
Jenny Wen (Design Lead in Claude e ex Director Design in Figma) durante il suo speech al Hatch Conference di Berlino 2026 mette in discussione proprio questo presupposto e io concordo con lei.
Il processo non è mai stato una garanzia di qualità. È stato, piuttosto, un modo per rendere il lavoro dei designer leggibile e accettabile all’interno delle organizzazioni. Funziona bene soprattutto come linguaggio condiviso con stakeholder, product manager e business.
Il problema nasce quando quel linguaggio viene scambiato per realtà.
Nella pratica, i progetti non rispettano quasi mai la linearità dei framework. Le fasi si sovrappongono, le decisioni vengono prese prima di avere tutti i dati, e spesso si torna indietro continuamente. Eppure, continuiamo a raccontare il lavoro come se fosse ordinato, forse per deformazione professionale, forse perché, in quanto designer, siamo amanti della perfezione.
Questa distanza tra racconto e realtà è il primo punto critico: il processo diventa una rappresentazione semplificata, utile per comunicare, ma pericolosa se presa alla lettera.
Quando lavorare tanto non significa capire di più.
C’è una scena che si ripete spesso: team che producono documenti impeccabili, presentazioni curate, artefatti perfetti. Personas dettagliate, journey map eleganti, flussi disegnati con precisione chirurgica.
Tutto sembra funzionare. Tutto sembra “design fatto bene”.
Eppure, quando (e se) il prodotto arriva nelle mani delle persone, qualcosa non torna.
Il punto è sottile ma decisivo: fare design non significa produrre output, significa produrre comprensione. E queste due cose non sempre coincidono.
Puoi passare settimane a costruire una rappresentazione perfetta dell’utente senza aver mai davvero capito come si comporta. Puoi disegnare un’esperienza fluida sulla carta che nella realtà si inceppa dopo due clic.
Il processo, quando diventa una sequenza da rispettare invece che un mezzo per scoprire, smette di aiutare. Diventa una messa in scena.
Il rischio è quello che in ambito Lean viene chiamato “false sense of progress”: stai producendo output, ma non stai riducendo l’incertezza, stai completando checklist operative, ma non stai davvero apprendendo.
E quello che manca è proprio il collegamento diretto tra attività e apprendimento. Ogni deliverable dovrebbe rispondere a una domanda precisa. Se non lo fa, è solo overhead.
L’accelerazione che ha cambiato tutto
Il punto di rottura, secondo la magica Wen, è l’arrivo dell’AI nei workflow di design
Strumenti come Figma Make, Loveble, Uizard, Midjourney, o Framer permettono oggi di generare interfacce, flussi e contenuti in tempi drasticamente ridotti. Ma ancora più importante: permettono di passare rapidamente da idea a prototipo testabile.
Questo riduce il costo dell’esplorazione.
Prima, il processo serviva anche a ottimizzare le risorse: non potevi permetterti di costruire troppe soluzioni, quindi dovevi “pensare bene prima”. Oggi questa limitazione è molto meno rilevante
Puoi creare un prototipo ad alta fedeltà in poche ore, testarlo con utenti reali tramite strumenti come Maze, Useberry o sessioni remote, raccogliere feedback e iterare subito.
In questo scenario, la sequenza rigida del processo perde valore. Non perché sia sbagliata, ma perché non è più necessaria per gestire il rischio.
Il rischio si gestisce direttamente attraverso l’esperimento.
Imparare diventa più importante di dimostrare
Il design smette di essere una disciplina orientata alla produzione di deliverable e diventa una disciplina orientata alla riduzione dell’incertezza.
Questo avvicina molto il design a pratiche come Lean UX e Continuous Discovery.
L’obiettivo non è completare fasi, ma validare ipotesi.
In questo contesto, strumenti come:
- prototipi ad alta fedeltà testati precocemente
- A/B testing
- usability testing rapido
- fake door test
- esperimenti su micro-feature
diventano più rilevanti di documenti statici.
Wen suggerisce implicitamente che il designer dovrebbe pensare più come uno sperimentatore che come un esecutore di processo.
Ogni attività dovrebbe rispondere a una domanda: “Cosa stiamo cercando di imparare?”
Se non c’è una risposta chiara, probabilmente quell’attività non è necessaria.
Il momento in cui “abbastanza buono” non basta più.
Con la democratizzazione degli strumenti, produrre interfacce funzionali è diventato relativamente semplice. Dico relativamente perché è giusto sottolineare che la qualità dell’output è comunque subordinata alla necessità di un linguaggio tecnico e alla conoscenza approfondita del problema e del prodotto.
Per generare un’interfaccia funzionale e coerente (non solo esteticamente gradevole), il designer deve saper tradurre le esigenze in un linguaggio che l’AI possa comprendere in termini di Gerarchia visiva, Pattern UI/UX, Design System, Vincoli di responsiveness etc..
Detto ciò resta un dato di fatto: oggi produrre una UI ordinata, coerente e funzionante non è più una competenza rara. Tra design system maturi, librerie di componenti, template e AI generativa, gran parte del lavoro esecutivo è stato standardizzato.
Puoi aprire Figma, usare una UI kit ben fatta, farti generare varianti da un AI plugin e arrivare in poco tempo a qualcosa che, oggettivamente, “funziona”. Navigabile, pulito, comprensibile.
Di conseguenza, il valore del designer si sposta.
Non è più nella capacità di costruire wireframe puliti o UI coerenti ma nella qualità delle decisioni a monte.
Qui entrano in gioco competenze più difficili da formalizzare:
- capacità di framing del problema
- priorizzazione delle ipotesi
- lettura critica dei dati
- sensibilità nel bilanciare bisogni utente e vincoli di business.
Wen parla di “taste”, ma non in senso estetico. Piuttosto come capacità di riconoscere cosa è rilevante e cosa no, cosa semplificare e cosa approfondire.
In un contesto in cui tutti possono produrre output, ciò che conta è la direzione.
Più potere, meno alibi.
L’adozione di questi strumenti e approcci riduce la dipendenza da altri ruoli per esplorare soluzioni.
Un designer oggi può:
- generare copy con AI
- creare prototipi interattivi senza sviluppo
- testare rapidamente con utenti
- simulare scenari complessi
Questo aumenta l’autonomia, ma elimina anche molte giustificazioni tradizionali.
Non si può più dire che non si è testato per mancanza di tempo o risorse. Non si può più rimandare la validazione alla fase finale.
Il lavoro diventa più diretto e più esposto.
E soprattutto, il designer non può più nascondersi dietro il processo. Il processo non prende decisioni: le prendono le persone.
Usare il processo senza diventarne dipendenti.
Ma è importante chiarire un punto: non si tratta di eliminare il processo.
Il processo rimane utile, e in alcuni casi è ancora la scelta più efficace.
Quando il problema è chiaro, ben definito e a bassa incertezza ad esempio un miglioramento incrementale, una feature già validata, o l’applicazione di pattern consolidati ; seguire un processo più strutturato può aiutare a muoversi in modo fluido verso la delivery.
In questi contesti, il processo funziona bene perché:
- le domande principali hanno già una risposta
- il rischio è relativamente basso
- l’obiettivo è eseguire con precisione, non esplorare
Qui framework e metodologie diventano acceleratori. Permettono di allineare rapidamente il team, distribuire il lavoro, ridurre ambiguità operative e arrivare alla fase di implementazione in modo più ordinato.
Il problema non è come usare una metodologia, ma quando usarla.
Il problema nasce quando questo stesso approccio viene applicato indiscriminatamente anche a contesti ad alta incertezza.
Wen critica proprio questo automatismo: usare sempre lo stesso processo, indipendentemente dalla natura del problema.
Non tutti i problemi richiedono discovery approfondita.
Non tutti i progetti richiedono settimane di ricerca.
Ma, allo stesso tempo, non tutti possono essere trattati come pura delivery.
La differenza sta nella capacità di leggere il contesto.
Un designer maturo sa distinguere quando:
- serve esplorazione (problema poco chiaro, alto rischio, molte incognite)
- serve esecuzione (problema definito, soluzioni già validate)
E adatta il livello di processo di conseguenza.
Questo è il passaggio chiave: il processo smette di essere una sequenza fissa e diventa uno strumento modulabile.
Metodologie come Design Thinking, Double Diamond o Lean UX non vengono abbandonate, ma usate in modo intenzionale. Non perché “si fa così”, ma perché in quel momento servono davvero.
In pratica, il designer non “segue il processo”.
Seleziona, combina e riduce il processo in base a ciò che deve ottenere.
E questo richiede una competenza nuova: sapere non solo come usare una metodologia, ma quando usarla — e quando no.
Se il processo non è più il centro, allora cosa resta?
La domanda che rimane è quasi scomoda: se il processo perde centralità, a cosa servono davvero i designer?
Non a seguire una sequenza. Non a produrre deliverable. Non a “fare bene le fasi”.
Quello spazio è sempre più occupato da tool, automazioni e AI.
Il ruolo del designer si sposta altrove, e diventa più difficile da definire proprio perché meno standardizzabile.
Serve qualcuno che sappia decidere cosa vale la pena costruire, prima ancora di costruirlo. Qualcuno che sappia muoversi nell’incertezza senza nascondersi dietro un framework. Qualcuno che non confonda l’output con l’impatto.
In un contesto in cui generare soluzioni è facile, il valore sta nel filtrare. Nel dire no più spesso che sì. Nel capire quali problemi sono reali e quali sono solo rumore organizzativo.
Wen suggerisce, che il designer diventa una figura di decisione e direzione, più che di esecuzione.
Una figura che:
- usa il processo quando serve, ma non ne dipende
- usa l’AI come leva, ma non come sostituto del pensiero
- costruisce solo ciò che ha senso validare
- accetta che la chiarezza emerga facendo, non pianificando
In questo senso, il designer è sempre meno un “maker di interfacce” e sempre più un interprete di complessità.
Qualcuno che connette segnali deboli, dati incompleti, vincoli di business e bisogni umani per prendere decisioni migliori — più velocemente degli altri.
Il processo non scompare. Ma smette di essere il protagonista.
Smette di essere una stampella a cui aggrapparsi per sentirsi nel giusto.
E quando quella stampella viene meno, rimane solo ciò che conta davvero:
la qualità del giudizio.
Ed è esattamente lì che, oggi, si gioca il valore del design.
(per approfondire qui il talk di Jenny Weng da cui ho tratto ispirazione per questo articolo)