Negli ultimi mesi, come Circle Leader del team HCD, mi sono ritrovata spesso a raccontare la stessa storia a colleghi e clienti: abbiamo usato l'AI per fare in un giorno quello che prima richiedeva una settimana. È una storia vera, e di episodi così ne abbiamo accumulati diversi — codice legacy analizzato in poche ore, trascrizioni di call trasformate in requisiti strutturati, brand identity trasformate in design system nel giro di una mattina.

Ma più raccontavo questi casi, più mi accorgevo che il punto interessante non era la velocità in sé. Il punto era cosa succedeva subito dopo che l'AI aveva prodotto il suo output.

Perché quei documenti, quelle epiche, quei prototipi non restavano mai fermi: diventavano il pretesto per portare le persone giuste in una stanza, stakeholder, utenti, sviluppatori, a discutere, correggere, decidere insieme. E da quella discussione, quasi sempre, tornavamo di nuovo all'AI con input nuovi, per produrre la versione successiva.

È in questa alternanza, l'AI che struttura, le persone che decidono insieme, l'AI che struttura di nuovo, che ho iniziato a vedere il cambiamento vero nel modo in cui lavoriamo. In questo articolo provo a raccontarlo attraverso tre progetti reali su cui il team HCD ha lavorato negli ultimi mesi.

Caso 1: senza design system, senza documentazione, senza tempo

È inizio agosto quando il nostro team viene chiamato in corsa su un progetto già avviato, per progettare la UX/UI di un nuovo modulo finanziario: i professionisti del settore dovevano poter analizzare dati da fogli Excel e trasformarli, quasi in automatico, nei parametri di configurazione di un prodotto finanziario complesso.

Tre vincoli, tutti insieme. Nessun accesso al design system del cliente , solo permessi e tempi di provisioning che non potevamo aspettare. Un dominio poco intuitivo, quello dei certificati finanziari, dove sbagliare l'equilibrio tra ciò che dare per scontato e ciò che spiegare voleva dire consegnare un'interfaccia chiara a chi l'aveva progettata e incomprensibile a chi l'avrebbe usata. E il tempo, il vincolo più spietato: il front-end aveva bisogno del disegno dei flussi in pochi giorni, alcuni stavano per andare in ferie, il cliente voleva un proof of concept per il rientro a settembre — e quasi tutto quello che si sapeva del progetto era stato detto a voce, in call, mai scritto.

Invece di rincorrere mesi di contesto a forza di riunioni, abbiamo usato l'AI (stavamo testando Cowork di Claude Pro) per comprimere il tempo necessario a costruire conoscenza condivisa. Due sole call: nella prima il front-end del cliente ci ha mostrato a schermo il design system che non potevamo raggiungere direttamente; nella seconda il product owner ci ha raccontato il tool a modo suo. Abbiamo trascritto entrambe con Gemini e caricato trascrizioni e screenshot in un progetto Claude, da cui abbiamo costruito, insieme all'AI, un documento dettagliato di epiche e user story, non un riassunto delle call, ma una vera trasformazione da conversazioni sparse a requisiti strutturati e leggibili da chiunque nel team.

Il documento da solo non bastava: serviva che tutti noi, front-end, back-end, cliente e stakeholder, lo validassero insieme. In meno di un'ora di riunione, letto riga per riga e corretto dal vivo, avevamo finalmente requisiti scritti e condivisi da tutte le parti coinvolte, non più detti a voce in call diverse, in momenti diversi, da persone diverse. È stato quel documento a permetterci di lavorare in autonomia nelle settimane successive, mentre buona parte del team cliente era in ferie.

Con i requisiti fissati siamo passati a Figma, dove l'agente AI integrato nei file di design ci ha aiutato a ricreare componenti coerenti con il design system partendo solo dagli screenshot raccolti in call, non avevamo la libreria vera, ma immagini abbastanza fedeli da costruirci sopra un flusso credibile. In quattro giorni il flusso chiave era completamente disegnato e condiviso col front-end.

Quando il cliente è rientrato a settembre, si è trovato davanti un flusso già mockuppato: non si è ripartiti da zero, ma corretto e rifinito qualcosa di già solido. L'AI non ha progettato al posto nostro, non ha capito da sola il dominio, non ha parlato con gli stakeholder: ha compresso il tempo necessario a trasformare conoscenza dispersa, call, screenshot, ricordi di riunione, in artefatti condivisibili e validati da tutto il team. In un contesto senza accessi, tempo e documentazione, non era un lusso: era la differenza tra arrivare pronti al rientro dalle ferie o restare fermi a riallineare tutti su una call di tre settimane prima.

Caso 2: "Rifateci la UI" non era la vera richiesta

Un cliente che vende dati di mercato in tempo reale: quotazioni di metalli, cambi valuta, indici, per un pubblico di trader. ci chiede di rifare l'interfaccia della sua area riservata: un terminale finanziario verticale costruito quindici anni fa e mai più ripensato. La richiesta sembrava semplice: "è vecchia, rifatecela". Fermarsi lì avrebbe però significato rispondere alla domanda sbagliata. Le domande vere erano altre, e il cliente stesso non aveva gli elementi per porsele: quanto del problema è grafico e quanto è nella struttura sottostante? Conviene rifare tutto, solo il front-end, o solo alcune parti? E con quale tecnologia, dato che oggi non esiste alcun sistema di componenti condiviso e ogni schermata è stata costruita a sé?

Qui l'AI è entrata prima ancora del disegno di una singola schermata. Con gli agenti co-pilot già in uso al team dev/arch abbiamo fatto analizzare la codebase esistente, centinaia di pagine, nessuna documentazione aggiornata, per ricostruire come funzionava davvero il prodotto e separare due cose che nella richiesta del cliente erano mescolate: i pain point che un nuovo front-end può risolvere da solo, e quelli che sono un vincolo del back-end e spostano quindi la scelta verso un intervento più profondo. In parallelo abbiamo fatto uno scouting mirato di framework e librerie, per arrivare in stanza non con un'opinione ma con una rosa già motivata.

C'è stato poi un passaggio che ha reso il lavoro credibile agli occhi del cliente in un modo che un semplice mockup non avrebbe potuto: un agente Figma ha letto il sito pubblico del cliente, l'unico materiale di brand disponibile in chiaro, per estrarne colori, tipografia e regole di base dell'identità visiva. Con quelle regole abbiamo personalizzato due librerie di componenti candidate, Ant Design e PrimeReact, trasformandole da template generici in due proposte che già "parlavano" la lingua visiva del cliente, applicate a schermate vere del prodotto.

Il risultato portato in stanza non erano tre tavole di stile: erano tre varianti concrete di come l'applicativo avrebbe potuto diventare, ciascuna ancorata a un framework indicato e a un perimetro di intervento dichiarato, cosa andava rifatto davvero, e cosa no. Il lavoro è durato circa sei ore, non una settimana. Ma la parte che conta non è la velocità: è che avere tutto nero su bianco, l'analisi del codice, la motivazione delle scelte tecniche, le schermate, ci ha permesso di aprire la conversazione da un punto di validazione, non da un foglio bianco. Il cliente non ha dovuto fidarsi della nostra parola: ha discusso su qualcosa di già scritto, e lo ha corretto dove non tornava.

Caso 3 — Mappare un processo molto complesso

Il terzo caso è diverso: qui non entriamo su un progetto nuovo, ma su uno strumento interno esistente da anni, cresciuto in modo organico per governare l'intero ciclo economico di un progetto, dalla vendita alla fatturazione, con logiche di calcolo, ruoli e casistiche accumulate nel tempo e mai messe per iscritto tutte insieme. Anche qui il nostro team viene coinvolto in corsa, su un processo che altri avevano già in parte discusso in call a cui non avevamo partecipato. Stakeholder distribuiti su funzioni diverse, chi vende, chi pianifica l'esecuzione, chi fattura, ognuno con un pezzo di verità, nessuno con il quadro intero. E una mole di logica di dominio che non possedevamo: regole di competenza economica legate al codice civile, coefficienti che cambiano in base a come viene erogato un servizio, differenze sottili tra "erogato" e "lavorato" che condizionano cosa viene davvero fatturato.

Avevamo però materiale prezioso: documentazione procedurale già scritta da chi gestiva il processo, fogli di mappatura tra i campi dei sistemi coinvolti, screenshot dello strumento esistente con i suoi flussi, spesso poco intuitivi e frutto di anni di aggiustamenti. Abbiamo raccolto tutto, trascrizioni, procedure, mappature, screenshot, in un progetto dedicato su Claude, costruendo un documento di epiche e user story che collegava ogni requisito alla sua fonte esatta.

È qui che è cambiato il modo di lavorare in modo più netto rispetto agli altri due casi. Ogni volta che, disegnando un flusso, veniva un dubbio su come si comportasse davvero il sistema in un caso particolare, la prima mossa non era più scrivere a chi conosceva il processo, spesso irraggiungibile nell'immediato, ma tornare al materiale già raccolto e chiederlo all'AI, che nel frattempo aveva costruito una conoscenza cumulativa di tutte le call e i documenti caricati. Solo dopo, con un'ipotesi già solida in mano, tornavamo dal team con qualcosa di concreto, una mappatura, un prototipo cliccabile, un elenco di casi, da far validare e correggere, per ripartire da lì.

Questo ciclo, mappare, chiedere all'AI, tornare dal team, validare, ripartire, lo abbiamo ripetuto più volte nel giro di poche settimane, e non si è ancora concluso: la quantità di eccezioni e vincoli da tenere in equilibrio richiede iterazioni continue. Oggi validiamo ancora principalmente con chi possiede il processo a livello di prodotto. Il passo che manca, e che sappiamo essere decisivo, è allargare la validazione a chi quel processo lo vive ogni giorno sul campo, gli altri stakeholder e gli utenti finali non ancora entrati nella stanza. È lì che il ciclo tornerà a chiudersi, ed è lì che capiremo davvero quanto della mappa che abbiamo ricostruito corrisponde al terreno.

---

Vale la pena chiarirlo: l'AI non salta il passaggio più complesso, ma rende il confronto tra persone ancora più necessario e immediato.

Il vero ostacolo nei progetti non è lo sviluppo o il design, ma raggiungere una certezza condivisa su cosa costruire. L'AI accelera questo processo, ma la decisione finale resta un momento d'incontro umano.

Il team HCD esiste per questo: trasformare rapidamente gli output dell'AI in soluzioni validate e pronte da realizzare. Se l'AI analizza la complessità dei dati, sono le persone a darvi valore e a prendere decisioni condivise.

Contattate il team HCD per collaborare e trasformare i dati in scelte concrete. Lavoriamo insieme per trasformare gli output dell'AI in decisioni condivise, validate e pronte per essere costruite.