Quando abbiamo deciso di ricostruire il sito di MM Shopy Devs, ci siamo posti un obiettivo più ambizioso di "farlo bello". Volevamo la parità al pixel con i nostri design Figma, un CMS su misura utilizzabile da tutto il team, tre lingue e un'IA (Claude) a fare il grosso del lavoro di costruzione. Il nostro sito è diventato il banco di prova di un flusso di lavoro che ora usiamo con i clienti.
Questo è un racconto onesto di cosa ha funzionato, cosa si è rotto e cosa diremmo a chiunque volesse tentare lo stesso percorso. Ed è anche una risposta onesta a chi continua a sostenere "lo costruiamo in Claude con pochi prompt". Fidatevi: non è così.
Primo passo: il CMS
Il primo passo è stato costruire il CMS stesso, con controlli di backend e un editor visuale. Il nostro team vive e respira Liquid, quindi lo abbiamo usato come linguaggio di templating di base.
I risultati sono stati eccezionali. Claude ha fatto un lavoro davvero impressionante nel costruirlo, ma possiamo garantire che non è stato un lavoro di "pochi giorni". Ci sono volute moltissime iterazioni e passaggi. E il punto è questo: non è stata nemmeno la parte tecnicamente più complessa del progetto. Sì, bisogna essere preparati tecnicamente, sapere esattamente cosa chiedere e avere una conoscenza a 360 gradi del settore. Ma la vera sfida è arrivata dopo.
Secondo passo: design e testing
Tutto parte da Figma, esattamente come nei nostri progetti di design Shopify, costruito come un vero design system: componenti, varianti e variabili, non frame sparsi. La nostra UX Designer costruisce desktop e mobile come design separati e deliberati, con le proprie scale tipografiche.
Perché Figma e non Claude Design? Semplice: volevamo riprodurre ciò che i nostri veri clienti Shopify pretenderanno, cioè coerenza e un design system scalabile, e oggi solo Figma può offrirlo.
L'idea sembra semplice: Claude legge il file direttamente tramite l'API di Figma e l'integrazione MCP, e lo costruisce nel CMS. Nella pratica, questa è stata la vera sfida, e il punto in cui abbiamo passato la maggior parte del tempo a testare, iterare e testare di nuovo.
È anche il punto in cui la nostra UX Designer ha dovuto lavorare più duramente. Non su come apparivano i design, ma su come erano costruiti. Abbiamo fatto molti cicli di export e import nel CMS per verificare cosa Claude riesce davvero a leggere, cosa no, e dove servivano correzioni.
Componenti è la parola chiave. Per costruire con precisione, la cosa più importante sono i componenti e come sono strutturati. Poi abbiamo scoperto che il modo in cui un design è costruito tecnicamente conta moltissimo: cosa è contenuto dentro cosa, come è impostato ogni contenitore, e così via. Onestamente, pochissimi designer arrivano a questo livello di dettaglio quando costruiscono in Figma. Nella nostra esperienza è davvero raro. Ma lavorando con l'IA, la gerarchia degli elementi e le regole di stile applicate correttamente sono tra i fattori chiave per far capire a Claude come deve comportarsi ogni elemento.
Poi arrivano le annotazioni, un altro strumento essenziale che permette di dire a Claude "questo elemento deve comportarsi così e cosà, servono questi controlli", e via dicendo. Senza annotazioni, Claude è cieco. Ma attenzione: è molto facile che un'annotazione contraddica il design, e non devono mai essere usate come scorciatoia per non impostare correttamente il design.
Potremmo scrivere un intero articolo solo su ciò che abbiamo scoperto in questa fase. In sintesi: non è un processo lineare di design e consegna. Il designer deve sapere esattamente cosa sta facendo e correggere la rotta strada facendo.
Prima sfida: il risultato differisce dal design
Qui è dove abbiamo sbattuto la testa più volte. Il design è perfetto, Claude ha tutte le informazioni corrette e può leggere tutto. Allora perché ciò che costruisce è diverso?
Dobbiamo essere onesti: non abbiamo trovato il modo di eliminarlo. Claude si discosterà sempre dal design, a volte di una piccola percentuale, a volte di una più grande.
Come l'abbiamo risolto? "Semplice": abbiamo costruito un sistema di gate di QA. Claude costruisce, poi la build viene revisionata rispetto al design (e fidatevi, questo gate esegue quasi cento regole e controlli), poi gli errori vengono corretti automaticamente e infine l'origine di ogni errore viene tracciata e trasformata in una nuova regola perché non possa ripetersi nella build successiva.
Sembra semplice. Solo questo punto ci ha richiesto settimane di test prima di centrarlo. Lo abbiamo costruito in modo da poter misurare, dopo ogni prima build, la percentuale di differenza rispetto al design, e vi garantiamo che non è mai sotto il 10%. Senza un gate di QA adeguato (uno complesso, che combina diverse metodologie di QA), Claude semplicemente non è preciso.
Qualche lettore penserà: il 10% va bene. Dipende. I nostri sviluppatori sono pixel perfect, e i clienti con cui lavoriamo si aspettano esattamente questo. Una deviazione del 10% distribuita su ogni pagina crea una cascata di feedback e problemi che non possiamo permetterci.
Seconda sfida: codice caotico
Questo è ciò che ci ha spaventato di più quando abbiamo iniziato a leggere il codice reale prodotto da Claude.
Abbiamo scoperto qualcosa di interessante: una pagina può essere pixel perfect rispetto al mockup e sembrare impeccabile a prima vista. Ma apri il codice e trovi tutto fatto con CSS inline, oppure centinaia di classi create una per elemento. Per chi non lo sapesse: visivamente, il risultato è lo stesso. Tecnicamente, è un enorme pasticcio e un disastro per le performance.
La ragione è piuttosto semplice: Claude non può standardizzare i design token al posto tuo se non lo hai fatto tu per primo. Questo si ricollega alle regole di design, ma va oltre. L'intero design deve usare design token, con proprietà standardizzate come variabili.
Ed è questo che ci ha preoccupato di più. Noi siamo esperti e lo individuiamo in fretta. Ma di tutti quelli che stanno costruendo siti in produzione con Claude, siamo abbastanza sicuri che la maggior parte non stia controllando queste cose.
Cosa abbiamo davvero imparato
L'IA non è il sistema di qualità. Il processo lo è. Claude è straordinariamente veloce e davvero bravo a tradurre un file Figma ben strutturato in codice pulito. Ma la velocità senza gate produce solo risposte sbagliate più in fretta. La combinazione che funziona è: un file di design disciplinato, un'IA che legge dati invece di immagini, controlli automatici che non negoziano e un umano che continua a revisionare ogni pagina rispetto al mockup.
Cause profonde, non toppe. Quando qualcosa regrediva, risalivamo alla causa strutturale e sistemavamo quella, di solito trasformandola in un nuovo gate. Rattoppare i sintomi è il modo in cui una codebase marcisce in silenzio.
I design system ripagano due volte. Ogni ora che la nostra designer ha dedicato a componenti e variabili puliti in Figma ha fatto risparmiare molte volte quel tempo nella costruzione, perché un input pulito è la leva più grande sulla qualità dell'output dell'IA.
Il sito è ora online, trilingue, gestito dal CMS e verificato al pixel, e la stessa pipeline sta diventando la base di come costruiamo per i clienti. Se sei un brand o un'agenzia che sta valutando build assistite dall'IA, contattaci e parliamo di come applicarlo al tuo progetto.
