Da Figma a WordPress: dai token del design a theme.json e blocchi, senza perdere fedeltà

Gran parte del mio lavoro con le agenzie comincia da un file Figma. Il problema non è far somigliare il sito al design nella schermata a 1440 pixel: è farlo restare fedele a 375, a 1920, con un titolo di tre righe, con un'immagine mancante, nello stato di errore di un modulo, e dopo che il cliente ha modificato la pagina per sei mesi. Questo è il metodo con cui porto un design in WordPress senza perderlo per strada.

Prima del codice: leggere il file

Una lettura tecnica del file Figma prima di stimare evita metà dei problemi. Cosa controllo:

• variabili e stili: colori, tipografia, spaziature e raggi sono definiti come variabili, o ogni elemento ha valori propri?
• componenti e varianti: pulsanti, card e campi sono componenti con varianti e stati, o copie scollegate?
• auto layout: gli elementi sono impaginati con auto layout, che si traduce direttamente in flexbox, o posizionati a mano?
• larghezze di riferimento: esiste almeno la versione mobile, e cosa succede tra una larghezza e l'altra?
• stati e casi limite: hover, focus, errore, vuoto, caricamento, testi lunghi.

Quello che manca si segnala subito all'agenzia, con domande precise. Indovinare un comportamento non disegnato è la prima fonte di revisioni.

Dai token a theme.json

Le variabili di Figma diventano i token del tema. In WordPress il posto giusto è theme.json:

• palette con i colori del design, e disattivazione dei colori personalizzati, così l'editor non permette tinte fuori sistema;
• tipografia: famiglie, dimensioni con valori fluidi (clamp()) che interpolano tra mobile e desktop invece di saltare a ogni breakpoint;
• spaziature come scala, usata da blocchi e template;
• larghezze di contenuto e larghezze estese.

Il vantaggio è doppio: il front-end usa variabili CSS generate da un'unica fonte, e l'editor mostra al redattore solo le scelte coerenti con il design.

Da componenti Figma a blocchi

Ogni componente ricorrente diventa un blocco o un pattern:

• componenti semplici (pulsanti, citazioni) come stili di blocco su blocchi nativi;
• sezioni ricorrenti come pattern bloccati nella struttura e liberi nei contenuti;
• componenti con dati (schede servizio, membri del team, eventi) come blocchi su misura con campi definiti, alimentati da tipi di contenuto dedicati.

Le varianti di Figma diventano attributi del blocco, non classi aggiunte a mano dal redattore.

Layout: auto layout, grid e container query

L'auto layout si traduce in flexbox con gap; le griglie di Figma in CSS Grid. Per i componenti che compaiono in contesti di larghezza diversa (una card in una colonna stretta o in una sezione larga) uso le container query: il componente si adatta allo spazio che ha, non alla larghezza della finestra. È la differenza tra un componente davvero riutilizzabile e uno che funziona solo dove è stato disegnato.

Dove si perde la fedeltà

Gli errori che vedo più spesso nei passaggi fatti di fretta:

• dimensioni fisse in pixel copiate dal file, che si rompono a qualunque altra larghezza;
• font caricati con varianti in più o senza le metriche giuste, con spostamenti al caricamento;
• immagini senza proporzioni definite e senza le dimensioni responsive generate dal tema;
• stati di focus e di errore mai disegnati e quindi mai sviluppati;
• un page builder usato per «fare prima», che produce un markup lontano dal design e affida al redattore la coerenza.

Verifica con anteprime

Lavoro su un ambiente di staging con anteprime condivise: l'agenzia confronta il sito con il file mentre si costruisce, non alla fine. La verifica finale comprende le larghezze intermedie, i casi limite, i Core Web Vitals e un controllo di accessibilità su contrasti, focus e moduli.

La consegna al redattore

Un tema fedele il giorno del lancio può perdere fedeltà in sei mesi, se il pannello lascia troppa libertà. Per questo la consegna comprende scelte precise:

• pattern bloccati nella struttura e liberi nei contenuti, così una sezione non si smonta trascinando un blocco;
• blocchi disponibili limitati per tipo di contenuto: in una scheda servizio non serve l'intero catalogo dei blocchi;
• ruoli con permessi coerenti: chi scrive articoli non modifica i template;
• campi con indicazioni su lunghezze consigliate di titoli e testi, che sono i primi a rompere un layout;
• una breve guida con le regole del design applicate ai contenuti: formati delle immagini, uso dei titoli, testi alternativi.

È il lavoro meno visibile del passaggio da Figma a WordPress, ed è quello che fa la differenza tra un sito che resta come è stato disegnato e uno che si degrada pagina dopo pagina.

Come la vedo io

Il passaggio da Figma al codice è la parte del lavoro che preferisco, e lo faccio con la stessa logica qualunque sia la destinazione. Quando il cliente ha bisogno di un pannello per gestire i contenuti, WordPress a blocchi con theme.json è un'ottima scelta: è così che ho realizzato il sito di Dotcampus, traducendo una grafica volutamente fuori dagli schemi in blocchi che il team aggiorna da solo, e il sito di Olio Intini, fedele alla grafica consegnata dal cliente.

Quando il pannello non serve, porto gli stessi token in un tema Tailwind per Nuxt, ed è ancora più diretto: le variabili di Figma diventano le variabili del tema, una per una. In entrambi i casi niente page builder: il design merita un codice scritto per lui.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto, anche in white-label. Sviluppo da Figma con token, blocchi su misura e anteprime condivise, e segnalo i problemi del file prima di stimare, non dopo.

Se hai un design da sviluppare, scrivimi: in una chiacchierata di circa 20 minuti leggiamo il file insieme. Il servizio è in Da Figma a WordPress.