Workflow

Processi ridisegnati, con il prima e il dopo

In un ecommerce come GUESS il tempo non si perde nelle grandi decisioni, ma nei passaggi ripetuti ogni giorno: un ticket ricopiato, una landing che aspetta uno sviluppatore, un report da compilare. Qui ci sono quelli che ho tolto, ognuno con il tempo di prima e quello di adesso.


Progetto 1

Design system agentico

35-55 giorni di lavoro risparmiati a ogni redesign

Il problema

Il design system viveva in Figma ed era scritto per le persone: quando usare un componente, cosa non farci, quali regole di accessibilità rispettare stava nelle review e nella testa di chi c'era da più tempo. Un agente AI non può chiedere cosa intendevamo, e ogni redesign passava comunque da settimane di schermate disegnate e poi ridisegnate in codice.

La soluzione

In due settimane ho estratto dalla libreria Figma i design token, come valori e come significati, e ho scritto per ogni componente un contratto: a cosa serve, varianti e stati, con cosa si compone, cosa non si deve mai fare, regole di accessibilità. Tutto vive in un repository che leggono sia il team sia Claude, collegato a Figma e Storybook via MCP. Claude compone il prototipo in un playground Next.js usando solo i componenti esistenti, e tipi, test e controlli di accessibilità decidono cosa entra.

Il risultato

Il prototipo esce prima di Figma: lo rivediamo nel playground, il sì lo diciamo lì, e solo dopo arriva su Figma e Storybook già pronto per lo sviluppo. Un redesign completo che prima richiedeva un mese ora esce in una settimana, e il tempo recuperato va su strategia ed esperienza utente.

Prima40-60 giornateUn mese di lavoro per 2-3 persone su ogni redesign
Ora5 giornateUna settimana per una persona
Risparmio35-55 giorniDi lavoro recuperati su ogni redesign

Prima ogni redesign voleva dire un mese di schermate disegnate in Figma da 2-3 designer e poi ridisegnate in codice. Ora una persona scrive il brief, Claude compone il prototipo con i componenti del design system e in una settimana è approvato e pronto per lo sviluppo.

Progetto 2

Claude + Figma + Jira

Da 1,5 ore a 4 minuti a ogni sprint (–95%)

Il problema

A fine sprint i mockup erano pronti, ma la parte più lenta doveva ancora arrivare: tradurre a mano il lavoro di design dentro Jira. Story, task, subtask, criteri di accettazione e note per gli sviluppatori erano lavoro ripetitivo che non aggiungeva niente al prodotto.

La soluzione

Ho collegato Figma, Claude e Jira in un workflow unico. Claude legge mockup e commenti direttamente da Figma via MCP, analizza struttura, componenti, stati e interazioni, e genera Epic, Story, Task e Subtask organizzati per logica di sviluppo.

Il risultato

La prima esecuzione ha creato 23 ticket in 4 minuti, con descrizioni e criteri di accettazione già scritti. Nessun copia-incolla, meno fraintendimenti e meno riunioni per spiegare cosa voleva dire quel commento sul mockup.

Prima1,5 orePer scrivere a mano 23 ticket Jira copiando dal file Figma
Ora4 minutiClaude legge Figma via MCP e apre i ticket da solo
Risparmio–95%Del tempo di handoff: quasi un'ora e mezza restituita a ogni sprint

Prima a ogni fine sprint story, task, subtask e criteri di accettazione passavano da Figma a Jira con il copia-incolla, un ticket alla volta. Ora Claude genera Epic, Story, Task e Subtask già scritti e organizzati: a me resta solo la revisione.

Progetto 3

Contentsquare + Claude AI Workflow · DX Awards 2026 1° premio · Best Use of AI

2,5 giorni di lavoro risparmiati ogni settimana

Il problema

Quando un KPI scendeva, il team doveva muoversi a mano tra dashboard di Contentsquare, registrazioni di sessione, heatmap, viste sul funnel, segnali di frustrazione e log degli errori, prima di scrivere le conclusioni e aprire i ticket. Ogni indagine portava via ore: si approfondivano solo i segnali più critici, mentre attriti che pesavano sul fatturato restavano nascosti troppo a lungo.

La soluzione

Ho collegato Claude a Contentsquare tramite il server MCP ufficiale, trasformando un'analisi complessa in una conversazione. Oggi si fanno domande su abbandoni al checkout, rage click, errori tecnici, frustration score o variazioni del funnel settimana su settimana, e tornano indicazioni già ordinate per priorità con i link alle sessioni. Ho configurato anche workflow ad agenti per report giornalieri, monitoraggio dei KPI, avvisi in tempo reale, diagnosi delle cause e apertura dei ticket su Jira.

Rassegna stampa

Il risultato

Primo premio nella categoria Best Use of AI ai DX Awards 2026. Il tempo di diagnosi è passato da 2-4 ore a meno di 5 minuti, accorciando i cicli di ottimizzazione e portando il team da uno stato di continua emergenza a decisioni prese sui dati. Il workflow traccia una linea diretta dall'anomalia all'intervento di sviluppo, e rende i dati di comportamento accessibili e utili tutti i giorni.

Prima2-4 orePer ogni diagnosi, tra dashboard, sessioni registrate e heatmap
Ora< 5 minutiUna domanda a Claude e la diagnosi arriva già ordinata per priorità
Risparmio2,5 giorni a settimanaSolo dai report giornalieri: prima mezza giornata ogni giorno, ora arrivano da soli

Prima ogni calo di un KPI significava ore passate a incrociare a mano i dati di Contentsquare, e il report quotidiano si prendeva mezza giornata di lavoro. Ora l'analisi è una conversazione, e gli agenti preparano report, avvisi e ticket Jira senza che nessuno apra una dashboard.

Apri la presentazione completa

Progetto 4

Pubblicazione dei contenuti ecommerce

Quasi un giorno di lavoro risparmiato a ogni pagina

Il problema

Creare contenuti editoriali per il sito GUESS richiedeva un coordinamento pesante tra design, sviluppo e contenuti. Il ciclo di produzione era lento e faticoso, e pubblicare una home o una landing slittava di continuo.

La soluzione

Ho costruito un workflow asciutto che ha reso i team autonomi e ridotto lo sviluppo manuale. I designer creavano i moduli in Figma; io li trasformavo in componenti React tramite esportazione del codice, li arricchivo con variabili per valuta, paese, lingua e altre condizioni, e li compilavo per la compatibilità con tutti i browser e i dispositivi. I moduli finivano poi in un generatore interno con oltre 30 componenti e diverse varianti.

Il risultato

Il team Content Delivery pubblicava una pagina in pochi minuti inserendo solo testi, link e immagini. Il team ha smesso di aspettare uno sviluppatore per pubblicare, e la stessa pagina è uscita uguale in ogni mercato.

Prima1 giornoPer pubblicare una home o una landing, tra design, sviluppo e QA
Ora1 oraIl team compone la pagina nel generatore con moduli già pronti
Risparmio~7 oreQuasi una giornata di lavoro per ogni pagina pubblicata

Prima ogni home o landing passava dalle mani di uno sviluppatore e richiedeva una giornata intera prima di andare online. Ora il team Content Delivery sceglie i moduli, inserisce testi, link e immagini e pubblica da solo, in tutti i paesi e le lingue.

Progetto 5

A/B test come processo continuo

Da 1 a 8 test A/B al mese

Il problema

Al team ecommerce mancava un processo strutturato e trasversale per testare le idee. Ipotesi, esecuzioni e risultati erano sparsi tra strumenti e persone diverse, e decidere era lento e spesso soggettivo.

La soluzione

Ho creato un processo unico di A/B test che coinvolge tutti i team ecommerce di GUESS. Su una board ClickUp ho strutturato l'intero percorso: generazione delle idee, qualificazione, approvazione, test attivi e documentazione dei risultati. Ho introdotto il framework PXL per valutare in modo oggettivo impatto, confidenza e sforzo su domande standardizzate, così da dare priorità sui dati.

Il risultato

Il nuovo processo ha reso possibile sperimentare di continuo, ha allineato meglio i team e accorciato i cicli di validazione. Le decisioni sono diventate più chiare, più misurabili e più fondate. Dall'ipotesi si arriva a sviluppo, QA e rilascio senza strappi.

Prima1 test al meseIdee sparse tra strumenti e persone, priorità decise a sensazione
Ora8 test al meseUn'unica board ClickUp dall'idea al rilascio, priorità con il framework PXL
Risultato8×Esperimenti in più ogni mese

Prima un'idea di test doveva farsi strada tra email, riunioni e opinioni, e si riusciva a lanciarne uno al mese. Ora ogni ipotesi entra nella stessa board, viene valutata su impatto, confidenza e sforzo, e arriva a sviluppo e QA senza attese.

Progetto 6

CRO come processo continuo

Da 1 intervento al mese a 15 a settimana

Il problema

Attriti e bug lungo il percorso dell'utente causavano abbandoni e rallentamenti, ma il modo di individuarli, metterli in ordine e risolverli era frammentato. Le indicazioni che arrivavano dagli strumenti di analytics restavano spesso inutilizzate.

La soluzione

Ho costruito un processo che coinvolge più team e usa Contentsquare per individuare attriti UX, problemi di usabilità e bug tecnici. Tutto confluisce in una dashboard ClickUp dedicata, e da lì ogni problema prende una di due strade parallele: miglioramento UX e design, oppure correzione e sviluppo. Dopo il rilascio si monitorano i risultati per capire l'impatto economico reale.

Il risultato

Il processo ha creato un ciclo di ottimizzazione continuo e guidato dai dati, ha reso i problemi più visibili e ha ridotto molto i tempi di risoluzione. Oggi il team sa quali interventi portano fatturato vero e può dare priorità di conseguenza.

Prima1 intervento al meseAttriti e bug scoperti tardi, segnalazioni che restavano ferme
Ora15 interventi a settimanaContentsquare li fa emergere, ClickUp li smista tra UX e sviluppo
Risultato~65×Interventi in più ogni mese, con l'impatto misurato dopo il rilascio

Prima i dati di analytics restavano nei report e solo un problema al mese arrivava fino alla correzione. Ora ogni attrito individuato prende subito la sua strada, miglioramento UX o fix di sviluppo, e dopo il rilascio se ne misura l'effetto sul fatturato.

Progetto 7

Descrizioni prodotto e traduzioni con AI

4,5 ore risparmiate a ogni descrizione (–90%)

Il problema

Scrivere descrizioni prodotto curate e coinvolgenti per oltre 45 paesi e 15 lingue richiedeva un lavoro manuale enorme. Il processo era lento, poco uniforme e dipendeva molto dal singolo copywriter. Anche tradurre grandi quantità di testo creava colli di bottiglia tra i team.

La soluzione

Ho progettato e sviluppato un'app interna integrata con OpenAI che genera descrizioni prodotto curate e orientate alla SEO partendo dall'immagine e dagli attributi. Per le traduzioni ho scritto anche uno script su Google Sheets che traduce in blocco gli intervalli di celle selezionati, restituendo subito tutte le lingue.

Il risultato

Una descrizione passa da ore a minuti, con lo stesso tono in tutte le lingue. Il copywriter non scrive più da zero: rivede e decide.

Prima5 orePer una descrizione prodotto scritta e tradotta a mano
Ora30 minutiGenerata dall'AI da immagine e attributi, tradotta in blocco
Risparmio4,5 oreOltre mezza giornata di lavoro per ogni descrizione, –90%

Prima ogni descrizione dipendeva da un copywriter e poi da un lungo giro di traduzioni tra i team, con un tono diverso da mercato a mercato. Ora l'app interna scrive la descrizione orientata alla SEO e lo script su Google Sheets la porta in tutte le lingue in un colpo solo.

Progetto 8

Pubblicazione dei contenuti su Marketing Cloud

4-5 giorni di lavoro risparmiati a ogni campagna

Il problema

L'editor email di Salesforce Marketing Cloud era troppo limitato e lento per gestire campagne su oltre 45 paesi e 15 lingue. Creare e adattare i template richiedeva un lavoro manuale lungo, che rallentava tutta la macchina del marketing.

La soluzione

Ho costruito un processo parallelo, dall'inizio alla fine, che ha tolto di mezzo la complessità operativa. I grafici creavano i moduli in BeeFree con un editor visuale; i moduli venivano esportati come HTML pienamente responsive e arricchiti con AMPscript dai team UX e sviluppo. Ho realizzato un generatore interno con cui il team Web Marketing monta i template con tutta la logica già dentro: condizioni, variabili, contenuti dinamici. Al team resta da caricare testi, traduzioni, immagini e link in un unico file.

Il risultato

Chi lavora nel marketing monta un'email da solo, in tutte le lingue e i paesi, senza toccare codice. Il lavoro tecnico si fa una volta, nel generatore, non a ogni invio.

Prima2-3 ore per versioneEmail di immagini statiche, duplicata a mano per ogni mercato e lingua
Ora1 oraUna sola email dinamica che gestisce tutti i mercati e le lingue
Risparmio4-5 giorniDi lavoro per ogni campagna, con 15 lingue da coprire

Prima le email erano immagini statiche senza variabili, ogni versione andava rifatta per mercato e lingua e i template erano gli stessi da anni. Ora con BeeFree si arriva a 50 template nuovi in un giorno, e la stessa email cambia testi per genere, generazione (millennial, Gen Z) e singolo cliente: cose che prima erano impossibili.