Torna alle risorse
Design-to-codeWorkflowRisorsaAggiornato 17 giugno 2026

Da Figma a WordPress: come funziona davvero il processo.

Ricevere un file Figma approvato non significa avere tutto il lavoro davanti. Significa avere tutto il lavoro di interpretazione ancora da fare. Come si passa da un layout statico a un sito WordPress che regge su tutti i dispositivi, con contenuti reali e modifiche future già in testa.

1. Il file Figma non è ancora un sito

Un file Figma è una rappresentazione visiva. Non descrive come si comporta il layout a 768px, non dice quale campo ACF alimenta quel titolo, non specifica se quella griglia a tre colonne è un loop di custom post type o tre campi ripetibili.

Tutte queste domande restano aperte fino a quando lo sviluppatore non le risolve — spesso in silenzio, spesso senza nemmeno segnalare che c'era un punto da chiarire. Non è un problema del designer. Il design comunica intenzioni visive. Trasformarle in struttura tecnica è il lavoro di chi sviluppa.

2. Cosa si fa prima di aprire l'editor

Prima di scrivere una riga di codice c'è una fase di lettura del file che molti sviluppatori saltano o fanno di fretta. Serve capire quanti template distinti ci sono davvero, quali componenti si ripetono, cosa il cliente dovrà poter modificare e cosa invece è statico.

  • Quanti template di pagina ci sono? Home, landing, blog, pagina interna: ognuno richiede un file PHP separato.
  • Cosa è modificabile dal cliente e cosa no? Questo cambia l'architettura dei campi ACF e la struttura del tema.
  • Le immagini hanno proporzioni definite o sono libere? Se non lo sono, serve una strategia di crop.
  • Ci sono font personalizzati? Vanno caricati da Google Fonts, Adobe Fonts oppure dai file locali.

3. Struttura del progetto WordPress

La struttura dipende da quante parti mobili ha il design. Un sito con cinque template e contenuti quasi statici non richiede la stessa architettura di uno con loop dinamici, filtri, custom post type multipli e moduli avanzati.

Per la maggior parte dei progetti agenzia la base funziona così: tema child o tema custom, campi ACF per i contenuti modificabili, template PHP per ogni tipo di pagina, CSS dei componenti separato dal CSS globale. Non è l'unica soluzione possibile, ma tende a essere quella più leggibile sei mesi dopo il lancio.

4. Il responsive non si improvvisa

Il file Figma mostra quasi sempre solo il desktop. A volte il mobile. Raramente i breakpoint intermedi.

Il lavoro sul responsive non è ricalcare il design: è interpretarlo in modo che regga su tutte le larghezze che designer e cliente non hanno mai visto insieme. Questo richiede alcune scelte che lo sviluppatore prende in autonomia.

  • I padding e i margin scalano con una logica fluida o ci sono salti netti tra breakpoint?
  • La tipografia usa clamp() o segue passi fissi a ogni breakpoint?
  • I componenti a griglia collassano verticalmente o si restringono in modo proporzionale?

5. Cosa si verifica prima di consegnare

Prima di passare il progetto si fa una verifica su tre livelli.

Il primo è visivo: il sito corrisponde al design? Font, colori, spaziatura. Si confronta il file Figma con il browser in modo diretto.

Il secondo è funzionale: tutto quello che deve essere modificabile funziona? Si apre il backend, si aggiornano i campi ACF, si verifica che le modifiche appaiano correttamente sul frontend. Si aggiorna un post, si carica un'immagine, si invia un modulo.

Il terzo è tecnico: il sito regge su dispositivi reali? Non solo Chrome desktop. iOS Safari, Firefox, Edge. Il menu si apre su mobile, le immagini non escono dal viewport, i moduli funzionano su schermo piccolo.

Domande frequenti

Quante revisioni sono necessarie su un progetto da design approvato?

Dipende dalla qualità del file e dalla chiarezza del brief iniziale. Con un file ben preparato e una lettura attenta in fase iniziale, di solito bastano una o due tornate di feedback. I problemi più frequenti emergono dove il design non specifica il comportamento responsive o i casi limite dei contenuti.

È necessario che il designer sia coinvolto durante lo sviluppo?

Non costantemente. Ha senso coinvolgerlo su decisioni che non era possibile definire prima: comportamenti responsive non specificati, varianti di contenuto non previste nel design, componenti che si comportano diversamente con dati reali rispetto ai placeholder.

Prossimo passo

Hai un file Figma approvato e cerchi qualcuno che lo trasformi in WordPress?

La pagina del servizio Design-to-WordPress spiega come lavoro su build da design approvato per agenzie.

Vai al servizio Design-to-WordPress