1. Usa una griglia
Lo sviluppo web è governato da regole, solitamente il CSS Box Model. Quando un design non segue un sistema di spaziatura coerente, lo sviluppatore deve interpretare ogni distanza separatamente, moltiplicando il rischio di micro-differenze.
Una griglia 8pt, un sistema di colonne e regole di spacing note riducono radicalmente le ambiguità e accelerano sia la realizzazione che il QA finale.
- Attieniti a un sistema di spaziatura coerente, ad esempio una griglia 8pt.
- Definisci chiaramente le larghezze dei container, ad esempio 1280px o 1440px.
- Non mescolare misure arbitrarie: 20px accanto a 22px generano incertezza.
2. Asset: esportabili vs CSS
Aiutami a mantenere il sito veloce. L'handoff non riguarda solo le forme visive: riguarda anche il peso della pagina finale. Ogni scelta sugli asset ha ripercussioni su performance, SEO e manutenzione.
SVG per icone e loghi, foto ottimizzate, gradienti CSS invece di immagini pesanti. Sono dettagli che fanno la differenza tra un sito che i clienti dell'agenzia amano e uno che li frustra.
- Icone e loghi dovrebbero essere SVG, non PNG.
- Prepara foto con aspect ratio standard come 16:9 o 4:3.
- Ombre e sfumature non dovrebbero essere appiattite nelle immagini se possono restare stili CSS.
- Riduci gli asset duplicati e fornisci sempre la dimensione nativa richiesta.
3. Stati responsivi
Inviare solo una vista desktop è come inviare metà progetto. Il 60-70% del traffico arriva spesso da mobile, e senza indicazioni chiare lo sviluppatore deve improvvisare su colonne, menu, padding e dimensione dei caratteri.
Non serve un mockup per ogni singola larghezza, ma servono almeno desktop, mobile e i casi tablet in cui il layout cambia davvero. Definire come collassano le sezioni evita due o tre cicli di revisione inutili.
- Desktop 1440px come vista principale.
- Mobile 375px o 390px per menu e stacking delle colonne.
- Tablet solo se il layout cambia drasticamente.
- Se una sezione ha quattro colonne su desktop e due su mobile, rendilo esplicito.
4. Hover e stati di interazione
Definisci cosa succede ai pulsanti e agli input quando cambiano stato. Hover, focus, active, disabled: ogni stato non definito viene implementato dal developer in base alla propria interpretazione, e raramente coincide con ciò che il designer aveva in mente.
Una pagina UI kit in Figma con pulsanti, input e tipografia funziona come unica fonte di verità. Un kit ben fatto elimina dozzine di domande e garantisce coerenza visiva su tutte le pagine.
- Includi stati hover, focus e active per tutti i componenti interattivi.
- Definisci lo stile dei link nel testo, non solo nei pulsanti.
- Prevedi lo stato disabled per form e pulsanti di invio.
5. Dal file di design a un sito WordPress funzionante
Un file Figma, PSD o XD è una rappresentazione visiva, non un sito funzionante: non dice come si comporta il layout a 768px, quale campo alimenta un titolo, o se una griglia a tre colonne è un loop di custom post type o tre campi ripetibili. Trasformare quell'intenzione visiva in struttura tecnica è il lavoro della fase di sviluppo.
Il processo segue fasi definite, ognuna con un output concreto: analisi del design e dei componenti, pianificazione tecnica (gerarchia dei template, custom post type, campi ACF, strategia responsive), markup HTML5 semantico, implementazione CSS e responsive, integrazione WordPress (functions.php, The Loop, tassonomie), poi ACF o metabox custom perché ogni area di contenuto sia modificabile senza toccare il codice.
- Quanti template di pagina ci sono davvero — home, landing, blog, pagina interna richiedono ciascuno un file template separato.
- Cosa è modificabile e cosa resta statico — questo definisce l'architettura dei campi ACF.
- Se le immagini hanno proporzioni fisse o serve una strategia di crop.
- Se la tipografia usa clamp() o passi fissi a ogni breakpoint, e come collassano i componenti a griglia su mobile.
6. Cosa si verifica prima della consegna
Prima di passare il progetto si fa una verifica su tre livelli. Visivo: il sito corrisponde al design — font, colori, spaziatura — confrontando direttamente file e browser. Funzionale: tutto quello che deve essere modificabile funziona — si aggiornano i campi ACF, si pubblica un post, si carica un'immagine, si invia un modulo, e si verifica che compaia correttamente sul frontend. Tecnico: il sito regge su dispositivi reali, non solo Chrome desktop — iOS Safari, Firefox, Edge, comportamento del menu su mobile, form su schermo piccolo.
Una build per agenzia deve anche sopravvivere all'handoff stesso: codice commentato e strutturato perché un altro sviluppatore possa continuare il progetto, documentazione tecnica del tema, CMS configurato per l'uso non tecnico, nessuna dipendenza nascosta da plugin o librerie non standard.
7. Formati di design supportati
Lavoro con i formati più comuni nelle agenzie.
- Figma — il più diffuso, facile da ispezionare ed esportare asset.
- PSD (Photoshop) — formato classico, estraggo layer e ottimizzo.
- Adobe XD — workflow simile a Figma, completamente supportato.
- Sketch — nativo Mac, supportato senza limitazioni.
8. Cosa ricevi alla consegna
Ogni progetto include un set di deliverable pensato per agenzie che devono poter gestire il risultato in autonomia.
- Tema WordPress custom completo — PHP, CSS, JavaScript pronti per la produzione.
- Documentazione tecnica del tema — guida per sviluppatori.
- Setup CMS — istruzioni per gestire contenuti con ACF.
- Supporto post-lancio di 30 giorni — correzioni e aggiustamenti minori.
- Repository Git — storia completa delle versioni e accesso al codice.
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.
Quanto tempo richiede una conversione design-to-WordPress?
Dipende dalla complessità: siti semplici (5–10 pagine) richiedono 3–4 settimane; siti medi (10–15 pagine) 4–5 settimane; progetti complessi con funzionalità custom 6–8 settimane.
Lavori anche con design non ancora responsive?
Sì. Se il design non prevede versioni mobile e tablet, le creo io durante lo sviluppo, adattando layout, tipografia e navigazione per ogni viewport.
Il tema funziona anche dopo il handoff, senza il tuo supporto?
Sì. Il codice è strutturato e documentato perché un altro sviluppatore o il team interno dell'agenzia possa intervenire senza dipendere da me.
Posso usare il tema per più clienti?
Ogni build è custom per il progetto specifico. Se servono basi riutilizzabili, possiamo concordare un approccio a starter theme white-label.
Prossimo passo
Hai un design pronto da convertire in WordPress?
Mandami i file e vediamo insieme come trasformarlo in un tema WordPress solido, pronto per handoff e produzione.
Parliamo del progetto