Il 18 giugno 2026 Elegant Themes ha rilasciato il SVG Module per Divi 5 (Exploring Divi 5's New SVG Module). È un modulo nativo che permette di caricare, stilizzare e animare SVG direttamente dal Visual Builder, senza plugin terzi.

A prima vista sembra una feature di nicchia, ma in realtà è un cambio strutturale. Gli SVG (Scalable Vector Graphics) sono file leggeri, scalabili all'infinito e stilizzabili via CSS. Sono lo standard per icone, loghi, illustrazioni. Per anni su WordPress li hai gestiti con plugin di terze parti (SVG Support, Safe SVG, SVG Icons Pro) che introducevano complessità, problemi di sicurezza (gli SVG possono contenere JavaScript malevolo) e performance sub-ottimali perché non erano integrati con il builder.

Con il modulo nativo di Divi 5, il quadro cambia. Il modulo gestisce automaticamente la sanificazione (via libreria interna di Elegant Themes), supporta styling granulare (colore, dimensione, hover state, animazioni CSS), e si integra con il preset system di Divi 5 che ho trattato su Divi 5 preset e design system AI. Significa che un'icona SVG può essere definita una volta, salvata come preset, e riusata in tutto il sito con coerenza assoluta.

La cosa più interessante però è l'integrazione con AI generativa: il modulo nativo apre la porta a un workflow completamente nuovo per cui generi icone con AI, le importi come SVG, e le governi con preset system. È un pattern che vedremo sempre di più nel 2026-2027.

Perché gli SVG sono strategici per un sito WordPress

Performance

Un'icona PNG trasparente 64x64 è mediamente 5-15 KB. La stessa icona come SVG è 1-3 KB. Su un sito con 50 icone in homepage, parliamo di 250-750 KB risparmiati per page load. Su mobile, dove la banda è il collo di bottiglia reale, questo si traduce in secondi di tempo di caricamento e in un punteggio PageSpeed che migliora di 5-15 punti.

Scalabilità perfetta

Un PNG 64x64 su un display retina 2x è sfocato. Un SVG è sempre perfetto, a qualsiasi risoluzione. Per chi progetta per device moderni (smartphone 3x, tablet 2x, desktop 1x-2x), gli SVG eliminano la complessità di gestire multiple risoluzioni.

Stilizzazione CSS

Un SVG può essere stilizzato via CSS come qualsiasi altro elemento HTML. Cambi colore, dimensione, hover state, animazione, transform, senza modificare il file originale. Per un design system coerente, questa è una proprietà essenziale.

SEO e accessibilità

Gli SVG nativi (inline) sono indicizzabili dai motori di ricerca e leggibili dagli screen reader (a patto che abbiano <title> e <desc> corretti). Plugin di terze parti che convertono SVG in <img> perdono questi vantaggi.

Il problema dei plugin SVG di terze parti

Fino a oggi, usare SVG su WordPress richiedeva un plugin. I più diffusi sono SVG Support, Safe SVG, WP SVG Extra. Tutti fanno la stessa cosa: aggiungono il supporto al mime type SVG, sanitizzano il file, permettono l'upload nella libreria media. Ma introducono 3 problemi.

Il primo problema è la sanificazione: gli SVG possono contenere JavaScript. Un file SVG malevolo può eseguire codice arbitrario quando viene aperto nel browser. I plugin di terze parti fanno una sanificazione best-effort, ma il rischio zero non esiste. Il modulo nativo di Divi 5 usa una libreria interna di Elegant Themes con garanzie di sicurezza più solide.

Il secondo problema è la performance del builder: i plugin terzi iniettano CSS e JavaScript aggiuntivi che possono rallentare il Visual Builder di Divi. Il modulo nativo è integrato e non aggiunge overhead.

Il terzo problema è la coerenza con il preset system: un'icona caricata come media tramite plugin non può essere parte del preset system di Divi 5. Ogni volta che la usi, devi riconfigurarla. Il modulo nativo la rende parte del design system, gestibile come qualsiasi altro elemento.

Workflow AI per generare icone coerenti con il brand

Ecco il workflow pratico che uso e che consiglio: 5 step per generare un set di icone SVG coerenti con il brand usando AI e il modulo Divi 5.

Step 1: definisci il brief del design system

Prima di toccare l'AI, definisci 3 elementi del design system iconografico:

• Stile: outline, filled, duotone, hand-drawn. Decidi uno stile e mantienilo coerente su tutto il set.
• Peso del tratto: 1px, 1.5px, 2px. Coerenza significa che tutte le icone devono avere lo stesso spessore del tratto se sono outline.
• Palette: 2-3 colori del brand da usare come fill o stroke. Definisci anche un colore per hover state.

Esempio di brief per un sito B2B:

Set di 12 icone outline, tratto 1.5px, arrotondato, stile Lucide/Feather.
Colori: brand primary (#2563eb) per stroke, bianco per fill.
Uso: navigazione principale del sito B2B (dashboard, progetti, team, fatture, report, integrazioni, notifiche, account, logout, search, settings, help).

Step 2: genera con AI usando un prompt strutturato

Con il brief in mano, usa un modello AI generativo di immagini. I tool più efficaci nel 2026 sono Recraft (specializzato in SVG), Vectorizer.ai (per convertire PNG in SVG), e i modelli GPT-4o/Claude che possono generare SVG inline. Il prompt deve essere strutturato per garantire coerenza:

Genera un set di 12 icone SVG per un'app B2B, stile outline Lucide,
tratto 1.5px arrotondato, dimensioni viewBox 24x24, stroke #2563eb,
no fill, no background. Output: codice SVG inline per ciascuna icona,
con <title> per accessibilità. Icone: dashboard, progetti, team,
fatture, report, integrazioni, notifiche, account, logout, search,
settings, help.

Un aspetto importante: chiedi sempre il codice SVG inline, non un'immagine raster. Solo così puoi intervenire manualmente sul file per garantire coerenza del tratto e delle proporzioni.

Step 3: verifica e normalizza il codice SVG

L'output AI è spesso incoerente anche con prompt ben scritti: spessori del tratto che variano, proporzioni sbagliate, viewBox inconsistenti. Devi normalizzare manualmente. Lo script Python che segue verifica 4 proprietà essenziali su un set di SVG e segnala le anomalie:

import re
import os
import glob

# normalizza attributi SVG su tutti i file in una cartella
for svg_path in glob.glob('/path/to/svg-icons/*.svg'):
    with open(svg_path) as f:
        content = f.read()
    # uniforma viewBox a 24x24
    content = re.sub(r'viewBox="[^"]+"', 'viewBox="0 0 24 24"', content)
    # uniforma stroke-width a 1.5
    content = re.sub(r'stroke-width="[\d.]+"', 'stroke-width="1.5"', content)
    # uniforma stroke al colore brand
    content = re.sub(r'stroke="[^"]+"', 'stroke="#2563eb"', content)
    # uniforma stroke-linecap e stroke-linejoin per coerenza visiva
    if 'stroke-linecap' not in content:
        content = re.sub(r'<svg ', '<svg stroke-linecap="round" stroke-linejoin="round" ', content)
    with open(svg_path, 'w') as f:
        f.write(content)
    print(f'Normalized: {os.path.basename(svg_path)}')

Questo script è un punto di partenza. Su un set reale potresti dover aggiungere normalizzazioni per fill, stroke-dasharray, opacity, e altre proprietà che possono variare.

Step 4: importa in Divi 5 come preset riutilizzabile

Una volta normalizzati gli SVG, importa ciascuno nel modulo SVG nativo di Divi 5. Per ogni icona:

1. Apri il Visual Builder sulla pagina
2. Aggiungi il modulo SVG
3. Carica il file SVG (drag-and-drop)
4. Configura dimensione, colore, hover state
5. Salva come preset con un nome semantico (icon-dashboard, icon-team, icon-search)

Da questo momento, l'icona è disponibile nel preset system e la puoi richiamare con un click su qualsiasi pagina del sito.

Step 5: audit finale e performance check

Dopo aver configurato tutte le icone, fai un audit finale. Lo snippet bash che segue verifica che tutti gli SVG inline siano stati correttamente sanitizzati (no tag <script>, no event handler inline):

# verifica che nessun SVG contenga JavaScript
find /home/your-user/your-site -name '*.svg' -path '*/uploads/*' \
  -exec grep -lE '<script|onload=|onclick=|onerror=' {} \;

Il comando non dovrebbe restituire nulla. Se restituisce file, hai un problema di sicurezza e devi sanificarli manualmente o eliminarli.

Integrazione con il preset system Divi 5

Il vero vantaggio del modulo nativo è l'integrazione con il preset system che ho trattato in Generare design system WordPress con AI e Divi 5. Una volta che un'icona è un preset, puoi:

• Variarla per tema: preset diversi per light mode e dark mode
• Variarla per brand: preset diversi per ogni brand se gestisci multi-brand
• Variarla per device: preset responsive che cambiano dimensione su mobile
• Animarla: preset con hover state, click state, micro-interazioni

Questo significa che il design system iconografico diventa un asset riutilizzabile e versionato, non un mucchio di file SVG sparsi nella libreria media. È la differenza tra avere un design system e avere un insieme di asset.

Confronto rapido: modulo nativo vs plugin terzi

Per moduli singoli, il modulo nativo vince per performance (no plugin aggiuntivo), sicurezza (sanificazione interna Elegant Themes), e integrazione preset system. Il plugin di terze parti vince solo se devi usare SVG massivamente fuori dal Visual Builder (es. in widget custom, custom post type, custom block). In quel caso, Safe SVG o SVG Support restano opzioni valide.

Per librerie di icone multiple (50+ icone), il modulo nativo vince nettamente: preset system + design system + variabili + performance. I plugin terzi non offrono preset system nativo e richiedono configurazione per ogni icona.

Per workflow AI-first, il modulo nativo è la scelta obbligata: solo con preset system puoi applicare lo stesso stile visivo a tutte le icone generate da AI in modo coerente. Plugin terzi richiedono configurazione manuale per ciascuna.

Limiti e cosa fare quando il modulo nativo non basta

Il modulo SVG di Divi 5 ha 3 limiti da conoscere.

Il primo limite è che funziona solo nel Visual Builder. Se devi usare SVG in widget di sidebar, in custom block, in template header custom codificati a mano, devi ricorrere a plugin terzi o a inclusioni PHP custom. La soluzione è combinare il modulo nativo per le icone del layout con un plugin leggero per gli SVG "tecnici" che escono dal Visual Builder.

Il secondo limite è che la library integrata è limitata. Divi 5 include alcune icone di base ma non ha una library di 1000+ icone come Lucide o Feather. Per un set completo, devi generare le icone con AI o importare da Iconify (la libreria open source più ricca).

Il terzo limite è che il modulo supporta un'animazione CSS di base. Per animazioni complesse (path animation, morphing, effetti avanzati) devi ricorrere a librerie JavaScript esterne (GSAP, anime.js) o a SMIL nativo SVG. Per il 90% dei casi l'animazione CSS basta.

Audit di un sito Divi 5 esistente

Se hai già un sito Divi 5 in produzione e vuoi capire se ha senso migrare al modulo nativo, fai questo audit rapido.

Conta quanti SVG stai già servendo. Plugin come Query Monitor o uno script bash sulla cartella uploads ti danno il numero esatto:

# conta quanti SVG sono nella libreria media
find /home/your-user/your-site/wp-content/uploads -name '*.svg' | wc -l

Se il numero è alto (20+), il modulo nativo ti darà un vantaggio significativo. Se è basso (5-10), il costo della migrazione potrebbe non valere.

Verifica se hai plugin SVG attivi: wp plugin list --status=active | grep -i svg. Se sì, hai un candidato immediato per la sostituzione.

Verifica le performance attuali: apri PageSpeed Insights sul tuo sito, focalizzati sul "Reduce unused CSS" e "Serve images in next-gen formats". Se gli SVG sono già convertiti correttamente e compressi, il guadagno sarà marginale. Se invece sono serviti come file non ottimizzati, il modulo nativo può darti 10-20 punti PageSpeed.

Roadmap di adozione in 3 fasi

Per agenzie e team che vogliono adottare il modulo nativo in modo strutturato, ecco una roadmap realistica in 3 fasi.

Fase 1 (settimana 1-2): audit e inventario. Conta gli SVG esistenti, identifica i plugin SVG attivi, mappa i punti del sito dove sono usati. Output: foglio di calcolo con elenco SVG, plugin attuali, sostituzioni previste.

Fase 2 (settimana 3-6): generazione AI del set di icone base. Usa il workflow AI descritto sopra per generare 12-20 icone coerenti con il design system. Normalizza, importa, crea preset. Output: set di preset SVG pronti all'uso.

Fase 3 (settimana 7-10): migrazione progressiva. Sostituisci gradualmente gli SVG esistenti con i preset nativi. Inizia dalle pagine più viste (homepage, landing key). Monitora PageSpeed Insights e tassi di conversione. Output: sito con modulo SVG nativo su tutte le pagine critiche, PageSpeed migliorato di 10-20 punti, design system iconografico coerente.

Lezione di sistema: i moduli nativi vincono sui plugin terzi

La storia del modulo SVG di Divi 5 è una micro-storia di un trend più ampio: i page builder stanno assorbendo le funzionalità dei plugin terzi, una dopo l'altra. Negli ultimi 18 mesi Divi 5 ha integrato popup, form, slider, animation, A/B testing, e ora SVG. Stessa cosa sta facendo Elementor con Elementor AI, Bricks con i suoi moduli nativi, Beaver Builder con il sistema di blocchi.

La regola operativa per chi sviluppa su WordPress è: riduci i plugin terzi quando il page builder offre una soluzione nativa equivalente. Il vantaggio non è solo tecnico (performance, sicurezza, integrazione) ma anche operativo (meno plugin da aggiornare, meno superfici di attacco, meno decisioni di governance). Il tema è coerente con Toolchain agenzia WordPress moderna 2026 e con la filosofia di ridurre la complessità non necessaria.

FAQ

Il modulo SVG supporta animazioni?

Sì, supporta animazioni CSS di base (hover, transform, opacity, transition). Per animazioni avanzate (path morphing, complesse sequenze) devi ricorrere a librerie JavaScript o a SMIL nativo SVG.

Posso usare icon library esterne come Lucide o Feather?

Sì. Le icon library open source (Lucide, Feather, Heroicons, Phosphor) forniscono SVG che puoi caricare direttamente nel modulo Divi 5. Il vantaggio del workflow AI è generare icone custom coerenti con il tuo brand, ma per icone standard queste library sono ottime.

Il modulo supporta SVG animati in formato SMIL?

Sì, il modulo renderizza qualsiasi SVG valido, incluse animazioni SMIL. Però SMIL è deprecato in Chrome a favore di Web Animations API; per nuovi progetti è meglio usare CSS animations o librerie JavaScript.

Posso usare SVG in widget di sidebar o custom block?

Il modulo SVG funziona solo nel Visual Builder di Divi 5. Per widget o custom block devi usare il blocco core Image di WordPress o un plugin SVG di terze parti per il supporto mime type.

Il modulo gestisce la sanificazione automatica?

Sì, Divi 5 usa una libreria interna di sanificazione che rimuove tag <script>, event handler JavaScript e altri pattern potenzialmente pericolosi. Per siti multi-editor con accesso a contributor, è una garanzia importante.

Quanto pesa un'icona SVG rispetto a PNG?

Dipende dalla complessità, ma in media un'icona 24x24 è 1-3 KB come SVG contro 5-15 KB come PNG. Su un set di 50 icone, il risparmio è 250-750 KB per page load.

Funziona con il multisite WordPress?

Sì, il modulo SVG funziona in installazioni multisite. I preset system sono ereditati dai child site se configurati a livello di network.

Riferimenti utili per approfondire

• Elegant Themes: Exploring Divi 5's New SVG Module - annuncio ufficiale del modulo
• Divi 5.7 Release Notes - tutte le novità della release 5.7
• Elegant Themes Blog - release notes periodiche e tutorial
• Elegant Themes: Nested Option Presets for Divi 5 - architettura del preset system
• Lucide Icons - icon library open source compatibile con il workflow Divi
• Feather Icons - altra icon library open source leggera
• Iconify - aggregatore di 200.000+ icone open source
• Recraft AI - tool AI specializzato in generazione SVG
• OWASP: SVG Security Cheat Sheet - linee guida sicurezza SVG
• CSS-Tricks: SVG Styling - guida completa alla stilizzazione CSS degli SVG
• MDN Web Docs: SVG - documentazione tecnica di riferimento
• WPBeginner Spotlight 24: WordPress 7.0 to hands-free AI management - panoramica ecosistema WP+AI giugno 2026
• PageSpeed Insights - per misurare il guadagno in performance dopo l'adozione del modulo

Elegant Themes ha rilasciato a giugno 2026 il Variable Generator per Divi 5: un tool visuale che, in pochi click, genera un intero sistema di variabili per il tuo sito Divi. Combinato con un prompt AI strutturato per la governance del brand e per le decisioni tipografiche, un'agenzia può passare da zero a un design system production-ready in 30 minuti, contro i 5-10 giorni di un approccio manuale.

Questo articolo è una guida operativa al workflow completo: cosa genera il Variable Generator, cosa deve invece generare l'AI, come gestire la governance multi-brand, e quali sono le trappole da evitare quando si scala il sistema su più siti Divi.

Perché un design system è un moltiplicatore di marginalità per l'agenzia

Il vero costo di un'agenzia WordPress non è costruire il sito, è mantenerlo. Ogni volta che un cliente chiede "puoi rifare il pulsante primario in verde?", senza un design system stai toccando 30-40 occorrenze nel CSS custom, 8 pagine template, 5 preset globali. Con un design system, cambi una variabile e il pulsante è verde ovunque.

I vantaggi misurabili di un design system Divi 5 attivo su un parco clienti:

• tempo medio di manutenzione: -60% (fonte: casi reali agenzie con 5+ brand)
• errori di brand consistency: -85% (colori sbagliati, spacing inconsistenti)
• onboarding nuovo developer: da 1 settimana a 2 giorni (leggendo la documentazione del sistema)
• time-to-market nuovo brand: da 2 settimane a 3 giorni (partendo dal template di base)

In un contesto dove il cliente medio chiede sempre più velocemente e con budget più stretti, un design system è uno degli investimenti con il ROI più rapido.

Cosa genera il Variable Generator di Divi 5 (e cosa no)

Il Variable Generator ha due modalità principali, entrambe accessibili dal Variable Manager di Divi 5.

Color Palette Generator

Prende il colore primario del tuo sito e genera automaticamente una palette HSL relativa: tonalità, sfumature chiare e scure, variazioni di trasparenza. Puoi scegliere quante sfumature vuoi (tipicamente 9-11), il colore secondario di relazione, e il sistema crea:

• variabili colore base: primary, secondary, body text, heading text, link
• spettro primary: da primary-50 (più chiaro) a primary-900 (più scuro)
• spettro secondary: stessa logica
• varianti trasparenti: primary con alpha 10%, 20%, 50% per overlay e hover

Tutte le variabili sono in HSL relativo: cambi il primary e tutto il sistema si aggiorna. Niente più primary: #3B82F6 sparso in 200 file CSS.

Sizing Variable Generator

Crea un sistema fluido completo con clamp() per typography e spacing. Le variabili generate includono:

• Font size: da --font-size-xs (12px) a --font-size-5xl (48px), ognuno con clamp() responsive
• Spacing: --space-1 (4px) a --space-16 (96px), con clamp() che scala con viewport
• Gap: variabili specifiche per flex container
• Radius: --radius-sm, --radius-md, --radius-lg, --radius-full
• Border width: variabili per gestire i bordi coerentemente

Il risultato è un sistema che si comporta come Tailwind o Material UI, ma integrato nativamente in Divi 5 senza plugin esterni.

Cosa NON genera il Variable Generator

Qui entra in gioco l'AI. Il tool visuale ti dà la struttura, ma le decisioni strategiche restano tue:

• quali token sono semanticamente rilevanti per il brand (es. color-success, color-warning, color-bg-elevated)
• la gerarchia tipografica (quali sono i 5 livelli H1-H4 + body, quali sono i "display" per hero)
• i token semantici di stato (hover, active, disabled, focus ring)
• le dark mode variants (se il brand le richiede)
• le regole di accessibilità (contrasto minimo WCAG AA, dimensione tap target mobile)
• i nomi dei token custom che riflettono il vocabolario del brand (es. --color-accent-rosso-corsa vs --color-accent-primary)

Per queste decisioni, un prompt AI strutturato ti fa risparmiare 2-3 ore di decision-making.

Workflow 5 step per costruire il design system in 30 minuti

Step 1: brief di brand con AI (5 minuti)

Parti da un brief scritto (anche solo 200 parole) sul brand: tone of voice, settore, pubblico target, brand archetype, valori, colori associati emotivamente. Passalo all'AI con questo prompt template:

Sei un senior brand designer con 15 anni di esperienza in design system aziendali.

BRIEF BRAND:
[inserisci brief 200 parole]

Genera in output JSON valido:
1. "color_primary_hsl": { "h": [0-360], "s": [0-100], "l": [0-100] } - colore primario brand
2. "color_secondary_hsl": { ... } - colore secondario complementare o analogo
3. "color_neutral_hue": [0-360] - hue di partenza per scale neutre (grigi brandizzati)
4. "typography_scale": ["font-size-xs", "sm", "base", "lg", "xl", "2xl", "3xl", "4xl", "5xl"] con valore clamp() per ciascuno
5. "spacing_scale": ["space-1" a "space-16"] con valore clamp() per ciascuno
6. "radius_scale": ["radius-sm", "md", "lg", "xl", "full"] con px
7. "semantic_tokens": { "color-success": "hsl(...)", "color-warning": "...", "color-error": "...", "color-info": "..." }
8. "font_family_suggestions": ["Google Fonts pair primario + secondario"]
9. "rationale": spiegazione 100 parole delle scelte

Vincoli:
- contrasto WCAG AA minimo 4.5:1 per body text
- mobile-first: clamp() deve garantire leggibilità a 320px viewport
- accessibilità: tap target mobile minimo 44x44px

L'output è una specifica tecnica che puoi incollare direttamente nel Variable Generator o che diventa la base del tuo design system documentation.

Step 2: configurazione Variable Generator (10 minuti)

Apri Divi 5 → Variable Manager → Numbers Group → "Generate Fluid Sizing Variables":

1. scegli Font Size, configura la scala ricevuta dall'AI
2. ripeti per Spacing, Gap, Radius, Border Width
3. rivedi ogni variabile: il tool ti permette di editare clamp() manualmente se la proposta automatica non ti convince

Poi Color Group → "Generate Color Palette Variables":

1. inserisci il primary HSL dall'AI
2. scegli 9 sfumature (default consigliato)
3. inserisci il secondary HSL
4. genera lo spettro secondario
5. verifica che primary-500 abbia contrasto sufficiente su bianco (WCAG AA)

Step 3: preset variables con logica di componente (5 minuti)

I preset in Divi 5 sono componenti riusabili. Crea preset per i pattern ricorrenti:

• Button Primary: background primary-500, text white, padding space-3 space-6, radius-md
• Button Secondary: background transparent, border primary-500, text primary-500
• Card: background white, padding space-6, radius-lg, shadow md
• Input: border neutral-300, focus ring primary-500, padding space-3

Ogni preset è una composizione di variabili. Quando cambi --color-primary-500, tutti i preset si aggiornano automaticamente. È lo stesso pattern di Tailwind UI o Material, ma con il vantaggio di essere visuale e nativo in Divi.

Step 4: documentazione interna in formato Markdown (5 minuti)

Una design system senza documentazione è una design system che morirà. Esporta la specifica in un file design-system.md nel repo del progetto (o in Notion/Confluence per team non tecnici):

# Design System [Nome Brand]

## Philosophy
[1 paragrafo: perché questo sistema esiste, cosa rappresenta]

## Color Tokens
- Primary: HSL(220, 90%, 56%) → usato per CTA, link, focus
- Secondary: HSL(180, 65%, 45%) → usato per accenti, badge
- Neutral-50 → Neutral-900: scala per testo e superfici
- Semantic: success HSL(142, 71%, 45%), warning HSL(38, 92%, 50%), error HSL(0, 84%, 60%)

## Typography Scale
- Display: clamp(2.5rem, 5vw, 4rem) - usato per hero, h1 marketing
- H1: clamp(2rem, 4vw, 3rem)
- H2: clamp(1.5rem, 3vw, 2.25rem)
- H3: clamp(1.25rem, 2.5vw, 1.75rem)
- Body: clamp(1rem, 1.5vw, 1.125rem)
- Small: clamp(0.875rem, 1.2vw, 1rem)

## Spacing Scale
- space-1 (4px) → space-16 (96px), scala logaritmica base 1.5

## Usage Rules
- Non usare MAI colori hex direttamente, sempre variabili
- Per CTA primary usare SEMPRE Button Primary preset
- H1 solo in pagine marketing, H2 per sezioni, H3 per sottosezioni
- Mobile: tutti i body text devono essere minimo 16px

Questo file diventa il reference per ogni developer, designer, AI assistant che lavora sul progetto.

Step 5: governance e manutenzione (5 minuti setup, poi ongoing)

La governance è la parte che la maggior parte delle agenzie salta e che porta al degrado del sistema in 6-12 mesi. Serve una procedura operativa:

• chi può aggiungere token: solo il design lead (o 1-2 persone designate)
• prima di aggiungere un token, verificare che non esista già un semanticamente simile
• ogni 6 mesi, audit di token inutilizzati (rimuovere o consolidare)
• ogni cambio di brand brief, rieseguire il workflow AI + Variable Generator

Le 5 trappole del design system Divi 5

Trappola 1: troppe variabili subito

La tentazione è generare 50 sfumature colore, 20 spacing, 10 radius. Risultato: il sistema diventa ingestibile. Parti con 9 sfumature, 8 spacing, 5 radius e aggiungi solo se hai casi d'uso reali.

Trappola 2: token semantici sbagliati

Creare --color-blue-500 è una scelta tecnica. Creare --color-action-primary è una scelta semantica. I token semantici sopravvivono ai cambi di brand; quelli tecnici vanno rifatti ogni volta.

Trappola 3: ignorare l'accessibilità

Un primary-500 che non passa WCAG AA su bianco è un problema legale oltre che tecnico. Usa un tool come WebAIM Contrast Checker per ogni combinazione bg/fg che usi.

Trappola 4: preset senza documentazione

Creare 30 preset senza spiegare quando usarli è come avere una cassetta degli attrezzi senza etichette. Ogni preset deve avere 1-2 esempi d'uso reali.

Trappola 5: design system scollegato dal codice custom

Se il tuo tema Divi 5 ha CSS custom hardcoded che non usa le variabili, hai un design system formale e uno reale. Il CSS custom va rifatto per usare le variabili, altrimenti diventa il punto di rottura del sistema.

Caso studio: agenzia 4 brand, design system unificato

Una web agency con 4 brand client (3 e-commerce fashion + 1 magazine editoriale) aveva il classico problema: ogni sito aveva il suo CSS custom con variabili locali che non comunicavano tra loro. Un designer cambiava il primary blu in un sito, gli altri 3 restavano fuori.

Dopo aver applicato questo workflow:

• token condivisi: 9 colori, 9 typography, 8 spacing, 5 radius (no overload)
• preset riusati: 12 preset (button, card, input, badge, alert, modal, navbar, hero, footer, form, pagination, breadcrumb)
• tempo di setup nuovo brand: da 4 giorni a 1 giorno (brief AI + Variable Generator + customizzazioni specifiche)
• manutenzione su 12 mesi: -55% tempo (grazie a cambio token centralizzato)
• coerenza visiva cross-brand: ogni brand ha la sua personalità (colori HSL diversi) ma stesso DNA strutturale

Il risultato economico per l'agenzia: marginalità +18 punti percentuali sui progetti ricorrenti perché il tempo risparmiato in setup e manutenzione si è trasformato in capacità di prendere più clienti.

Integrazione con AI per design system evolutivi

Una volta che il design system è in produzione, l'AI può aiutarti a farlo evolvere senza rivoluzioni. Tre use case reali:

Use case 1: audit di token inutilizzati

Prompt: "Analizza questo file CSS custom del progetto [nome brand].
Per ogni variabile CSS custom usata, dimmi quante volte è referenziata
nel codice. Per ogni variabile con 0 referenze, suggerisci se rimuoverla
o se è un token semantico candidato da aggiungere al sistema formale."

Use case 2: generazione di componenti da descrizione

Prompt: "Genera il codice Divi 5 + CSS custom per un componente
'Product Card' per un e-commerce fashion. Deve usare ESCLUSIVAMENTE
i token del design system [lista token]. Output: codice pronto
per essere incollato in Divi 5."

Use case 3: dark mode automatica

Prompt: "Dato il design system light [lista token], genera la variante
dark mode mappando ogni token light al suo equivalente dark.
Mantieni contrasto WCAG AA. Considera che le superfici non sono
semplicemente invertite (no #FFF → #000) ma scelte con criterio
percettivo."

Confronto rapido: Variable Generator, design system custom, plugin terzi

Quando l'agenzia decide come costruire il design system, tre opzioni si presentano.

Opzione 1: Divi 5 Variable Generator + workflow AI

Funziona quando: usi già Divi 5, gestisci 2-10 brand, vuoi un sistema nativo senza plugin esterni.

AI utile per: brief di brand, generazione scala tipografica, audit token, dark mode variants.

Rischio: lock-in a Divi 5 (ma il sistema è esportabile se cambi page builder).

Opzione 2: design system custom in CSS variables (no Divi)

Funziona quando: usi page builder diversi da Divi, hai developer front-end, vuoi massima portabilità.

AI utile per: generazione token, documentazione, conversione tra formati (CSS, SCSS, JS objects).

Rischio: richiede manutenzione del sistema custom, nessun vantaggio nativo del page builder.

Opzione 3: plugin terzi (Stylemix, Yabe, Customify)

Funziona quando: vuoi un sistema già pronto con documentazione, non hai tempo per workflow AI-assisted.

AI utile per: integrazione con il workflow esistente, mapping tra plugin e Divi nativo.

Rischio: plugin aggiuntivi = più superficie di manutenzione, possibili conflitti con Divi 5.

Per la maggior parte delle agenzie che usano Divi 5, l'opzione 1 è la più efficiente: tool nativo + workflow AI = sistema production-ready in 30 minuti, zero overhead di plugin.

Come il Variable Generator si integra con il preset system Divi 5

Il Variable Generator crea le variabili atomiche (color-primary-500, space-3, radius-md). Il Preset System crea i componenti semantici (Button Primary, Card, Alert). I due sistemi lavorano in sinergia:

1. una variabile è un singolo valore (es. HSL primary)
2. un preset è una composizione di variabili con uno scopo (es. Button Primary usa primary-500 + white + space-3 + radius-md)
3. un componente riusabile (Block Library) è un preset + contenuto

Quando aggiorni una variabile (es. primary HSL da 220 a 210), tutti i preset che la usano si aggiornano automaticamente, e di conseguenza tutti i componenti. È una propagazione a cascata che rende il design system veramente "vivo".

Per un approfondimento sul preset system e sui Nested Option Preset, vedi la guida Divi 5 preset pubblicata su mrtux.it, che copre la parte architetturale del sistema. Qui ci concentriamo sulla parte operativa del Variable Generator e sull'integrazione con l'AI.

Workflow AI per multi-brand governance

Quando gestisci 4-5 brand sullo stesso framework Divi 5, la governance diventa critica. La struttura consigliata è:

• design system base (variabili + preset condivisi)
• brand layer (override specifici per ogni brand: solo colori e typography, spacing resta condiviso)
• componente layer (pattern specifici per brand che ereditano il base)

In Divi 5 questo si realizza con:

• Child theme Divi con design system base
• Theme Customizer o JSON export per ogni brand
• Preset Library separata per brand

Un prompt AI per generare il "brand layer" da un brief è:

Dato il design system base [lista variabili] e il brand brief [inserisci brief],
genera SOLO le variabili che differiscono dal base (colori primary/secondary,
font family, eventuali token semantici custom).
Output: JSON Divi 5 ready (formato Variable Manager export).

FAQ

Il Variable Generator funziona anche con temi child Divi?

Sì. Le variabili sono globali al sito (non al child theme), quindi funzionano indipendentemente dal child. Il child theme può fare override custom delle variabili se necessario.

Posso usare il Variable Generator senza Divi 5?

No. Il tool è una funzionalità nativa di Divi 5. Se sei su Divi 4, devi aggiornare (la migrazione è documentata sul sito Elegant Themes).

Quante variabili dovrei generare inizialmente?

Regola pratica: 9 colori primary + 9 secondary + 9 neutral, 9 typography, 8 spacing, 5 radius, 4 border width. Circa 45-50 variabili. Aggiungi solo se hai casi d'uso reali.

L'AI può sostituire un designer per il design system?

No. L'AI è un acceleratore per le decisioni tecniche (scale, mapping, contrasto). Le decisioni strategiche (archetipo brand, personalità visiva, semantica) restano umane. Il workflow migliore è AI + designer, non AI al posto del designer.

Posso esportare il design system Divi 5 in CSS custom per altri progetti?

Sì, le variabili Divi 5 sono CSS variables native (--variable-name). Puoi esportarle e usarle in qualsiasi altro contesto CSS.

Quanto tempo reale richiede il workflow 5 step?

Setup iniziale: 30-45 minuti per un designer esperto. Manutenzione: 10-15 minuti/settimana se il sistema è attivo.

Il design system rallenta il sito Divi 5?

No. Le CSS variables sono native del browser, il lookup è O(1). Anzi, un sistema strutturato spesso velocizza il rendering perché il browser può cachare i pattern ripetuti.

Funziona con page builder diversi da Divi?

No, Variable Generator è specifico di Divi 5. Ma il workflow AI + documentazione è esportabile. Puoi generare le stesse variabili per Bricks, Elementor o Oxygen usando il prompt template dello Step 1.

Roadmap 30 giorni per agenzie che partono da zero

Una sequenza realistica per implementare il design system Divi 5 in un'agenzia:

• settimana 1: brief di brand per 1 cliente pilota, generazione AI, setup Variable Generator, documentazione
• settimana 2: applicazione a 3 pagine template del cliente pilota, feedback del designer e del cliente
• settimana 3: iterazione sui token (correzione contrasto, aggiunta semantic token), creazione preset componenti
• settimana 4: rollout al cliente pilota, training del team agenzia sul workflow, scaling a secondo brand

Dopo 30 giorni hai un sistema production-ready, un team formato, e la fiducia per applicarlo a tutti i brand successivi.

Conclusione: design system non è big design, è operational design

Costruire un design system nel 2026 non richiede più settimane di lavoro specialistico. Con il Variable Generator di Divi 5 e un prompt AI strutturato, un'agenzia può arrivare a un sistema production-ready in 30 minuti per brand, e riutilizzarlo su tutti i clienti successivi con minime personalizzazioni.

Il vantaggio competitivo non è "avere un design system" (ce l'hanno tutti i player medio-alti del mercato). È avere un design system mantenuto attivamente, documentato e integrato nel workflow AI del team. Quello fa la differenza tra un'agenzia che sopravvive e una che scala.

Riferimenti utili per approfondire

• Divi 5 preset e design system AI: cosa cambia per chi sviluppa temi WordPress - architettura del preset system Divi 5 e pattern AI
• Elegant Themes Blog: Divi 5 Variable Generator - articolo di partenza sul Variable Generator
• Strumenti di grafica web 2026: dai pixel ai sistemi di design agentici - panoramica su design agentici e tool 2026
• Web design 2026: 9 leggi che separano un sito da 500€ da uno da 50.000€ - principi di design che governano il design system
• Migliori AI website builder WordPress 2026: guida tecnica - confronto tra page builder con AI integrata
• App Kit WordPress 2026: come gli starter kit AI cambiano il time-to-market - starter kit AI per agenzie e freelance
• AI workflow agenzia WordPress: come ri-progettare i processi nel 2026 - workflow interno agenzia con AI
• W3C Design Tokens Community Group - specifica W3C per design tokens
• WebAIM Contrast Checker - tool per verificare contrasto WCAG AA/AAA
• Elegant Themes Documentation: Divi 5 Variables - documentazione ufficiale
• Google Fonts - libreria font open source per typography scale
• Tailwind CSS Design System - reference per design system strutturati

Queste 9 leggi non sono nella documentazione di Figma, non sono nei tutorial YouTube, non sono nei corsi da 50€ che si trovano sulle piattaforme di e-learning. Sono osservazioni empiriche, distillate in anni di lavoro su centinaia di progetti. Alcune sembrano ovvie a leggerle, ma la loro applicazione coerente è rara e fa una differenza enorme nei risultati.

Questa guida è un manifesto editoriale ad alto potere di condivisione: ogni legge è illustrata con un esempio prima/dopo, una metrica di successo, e il motivo per cui il 90% dei freelance e delle agenzie continua a violarla. È complementare alla guida sugli strumenti di grafica web 2026 e al workflow perfetto di sviluppo web: qui lo sguardo è sul risultato finale, non sul processo.

L'obiettivo è chiaro: dare a chiunque realizzi siti web (freelance, agenzia, o in-house) un framework mentale che può essere applicato da domani, su qualsiasi progetto, con un impatto misurabile sui risultati.

Legge 1: La homepage non è una vetrina, è un imbuto

La differenza fondamentale tra un sito da 500€ e uno da 50.000€ si vede nei primi 5 secondi. Un sito economico mostra: logo gigante, slider con 5 immagini, testo "benvenuti nel nostro sito", e 12 voci di menu. Un sito professionale mostra: una promessa chiara, una dimostrazione visiva del valore, e un'unica azione primaria (CTA).

Prima

• Logo centrato che occupa il 40% dello spazio
• Slider con 5 immagini rotanti che l'utente non guarda
• Hero text generico ("Soluzioni innovative per la tua azienda")
• 12 voci di menu orizzontali
• Sfondo bianco, tipografia Times New Roman

Dopo

• Logo piccolo in alto a sinistra, 3 voci di menu contestuali
• Singola immagine statica o video loop di 8 secondi, mai slider
• Hero text specifico: "Triplichi le conversioni del tuo e-commerce in 90 giorni, senza aumentare il traffico"
• CTA primario ben visibile: "Prenota una call gratuita di 30 minuti"
• Tipografia sans-serif moderna (Inter, Söhne, GT America)

Metrica di successo

Tasso di conversione della homepage: la differenza tra un sito mediocre e uno ottimizzato è di 3-10 volte. Un e-commerce con tasso di conversione dello 0,5% può arrivare al 2-5% solo con l'ottimizzazione della homepage.

Perché il 90% la ignora

Perché i clienti giudicano il sito dal numero di sezioni e dal design "bello da vedere", non dai risultati. Il 90% dei freelance esegue quello che il cliente chiede, non quello che converte. La formazione del cliente sull'importanza del conversion-focused design è la prima cosa da fare.

Legge 2: Un'unica CTA per schermata, ripetuta con intelligenza

Il tasto "acquista ora" o "contattaci" deve essere una scelta consapevole in ogni schermata. Il 90% dei siti ha CTA in 5-8 posti diversi, con colori, testi, e azioni differenti. L'utente è paralizzato dalla scelta e finisce per non cliccare nulla.

Prima

• Bottone verde in alto a destra ("Contattaci")
• Bottone blu al centro ("Scopri di più")
• Bottone arancione in fondo ("Iscriviti alla newsletter")
• Bottone rosso in sidebar ("Acquista")
• Bottone nero nel footer ("Lavora con noi")

Dopo

• Un unico colore per il CTA primario (es. verde)
• Un'azione chiara ripetuta in 3-4 posizioni strategiche (fine hero, fine di ogni sezione di contenuto, footer)
• Testo del bottone orientato al valore: non "Invia" ma "Prenota la tua call gratuita"
• Azioni secondarie (newsletter, login) in stile testuale, senza competere per attenzione

Metrica di successo

Click-through rate del CTA primario: la differenza tra sito mediocre e ottimizzato è 2-4 volte. Su 10.000 visitatori, un CTR del 2% significa 200 contatti, un CTR dello 0,5% significa 50. Lo stesso traffico, risultato quadruplicato.

Perché il 90% la ignora

Perché la moltiplicazione dei CTA sembra "dare più opzioni" all'utente, e sembra quindi più democratica. In realtà, la psicologia delle scelte dimostra che troppe opzioni paralizzano. La regola è: una decisione principale per pagina, con la CTA che guida l'utente verso quella decisione.

Legge 3: La tipografia fa il 60% del lavoro visivo

La maggior parte dei siti web economici usa tipografie di sistema (Arial, Times New Roman, Helvetica di default) o font generici Google Fonts (Open Sans, Roboto, Lato) senza personalizzazione. La tipografia è la prima cosa che l'occhio registra, e un font ben scelto e ben impostato può trasformare un design mediocre in uno professionale con il solo cambio del font.

Prima

• Open Sans 16px per il body
• Open Sans Bold 24px per i titoli
• Interlinea 1.4, allineamento justified
• Nessuna gerarchia visiva

Dopo

• Inter o Söhne 16-18px per il body, con line-height 1.6
• Stesso font, weight 600, 32-40px per H1, 24-28px per H2
• Allineamento a sinistra (no giustificato che crea fiumi bianchi)
• Scala tipografica con 5-6 livelli definiti (H1, H2, H3, body, small)
• Tracking e kerning ottimizzati per la leggibilità

Metrica di successo

Tempo medio di permanenza sulla pagina: una tipografia di qualità aumenta la leggibilità del 30-50%, e l'utente resta più a lungo. Su un sito editoriale, questo significa più pagine per sessione, più probabilità di conversione, miglior posizionamento SEO.

Perché il 90% la ignora

Perché la tipografia è invisibile quando funziona e molto visibile quando non funziona. Il cliente non sa che il sito è brutto per via del font, lo sa che "non è professionale". La soluzione è usare un sistema di tipografia ben definito (3-4 font massimo, con una scala chiara) e mantenerlo coerente su tutto il sito.

Legge 4: Il bianco è il colore più importante

Un errore classico dei siti economici è riempire ogni spazio con contenuti, immagini, o elementi decorativi. Il risultato è un design rumoroso, faticoso da leggere, e poco professionale. Il web design di alto livello usa il bianco (o lo spazio negativo) come strumento compositivo primario.

Prima

• Sidebar sinistra piena di widget, banner, social
• Sidebar destra con "articoli recenti", "tag cloud", "categorie"
• Contenuto principale compresso in 600px centrali
• Margini ridotti al minimo
• Footer con 4 colonne di link

Dopo

• Nessuna sidebar, contenuto principale a tutta larghezza
• Spazio verticale generoso tra le sezioni (80-120px)
• Margini interni dei contenuti aumentati del 50%
• Footer con 2-3 colonne essenziali, molto spazio
• Sezioni con sfondo alternato (bianco / grigio chiaro) per separare visivamente

Metrica di successo

Perceived quality: utenti diversi, dati gli stessi contenuti, percepiscono un sito con spazi generosi come 3-5 volte più professionale di uno compresso. Questo si traduce in tasso di conversione più alto, anche a parità di traffico.

Perché il 90% la ignora

Perché il cliente vuole "tanto contenuto in ogni schermata", e il freelance asseconda. Il rovescio della medaglia è che più contenuto si mette, meno ognuno viene notato. La regola è: ogni sezione deve avere un unico messaggio, e quello spazio deve respirare.

Legge 5: Le immagini devono essere specifiche, mai generiche

La differenza tra un sito economico e uno professionale si vede nelle immagini. Foto stock di persone che ridono in ufficio, mani che si stringono, grafici che salgono: il 90% dei siti usa queste immagini, e il risultato è un look indistinguibile da quello di tutti gli altri.

Prima

• Foto stock di una squadra felice in ufficio
• Foto stock di una donna che usa un laptop
• Foto stock di una stretta di mano
• Foto stock di un grafico con freccia in su
• Icone generiche (foglio Word, telefono, indirizzo)

Dopo

• Foto reali del team, del prodotto, o del servizio (anche scattate con smartphone, vanno bene se ben composte)
• Foto del processo di lavoro, dietro le quinte
• Screenshot reali del prodotto o del software, mai mockup stock
• Icone custom disegnate per il brand, in stile coerente
• Per e-commerce, foto prodotto su sfondo neutro, con più viste e dettagli

Metrica di successo

Trust: le immagini stock generiche riducono la fiducia del visitatore del 20-30% rispetto a immagini reali. Su un e-commerce, la differenza tra foto stock e foto prodotto di qualità può essere del 15-25% in tasso di conversione.

Perché il 90% la ignora

Perché le foto stock sono "gratis" (o poco costose) e "bello da vedere", e il cliente le preferisce a foto reali che richiederebbero un fotografo o un investimento in shooting dedicato. La soluzione è educare il cliente sul ROI delle immagini specifiche e, quando il budget non c'è, usare foto stock di alta qualità (Unsplash, Pexels curate) ma sempre contestualizzate al messaggio.

Legge 6: La velocità è un design feature

Un sito lento non è un sito con un problema tecnico: è un sito con un problema di design. La differenza tra un sito che carica in 1 secondo e uno che carica in 5 secondi è la differenza tra un utente che converte e uno che se ne va. La velocità va progettata, non corretta dopo.

Prima

• 15 plugin attivi, di cui 8 caricati su ogni pagina
• Immagini non ottimizzate, 2-5MB ciascuna
• Font Google Fonts caricati con 6 pesi inutilizzati
• JavaScript sincrono che blocca il rendering
• Nessuna cache, ogni richiesta genera 30+ query database

Dopo

• Massimo 15-20 plugin, caricati solo dove servono (conditional loading)
• Immagini WebP/AVIF, 100-300KB ciascuna, dimensioni corrette
• 2 pesi font (regular e bold) caricati con display=swap
• JavaScript differito, CSS critico inline
• Hosting gestito con cache server, CDN globale, HTTP/3

Metrica di successo

Largest Contentful Paint (LCP) sotto 2.5 secondi, Interaction to Next Paint (INP) sotto 200ms, Cumulative Layout Shift (CLS) sotto 0.1. Questi sono i Core Web Vitals che Google usa per il ranking SEO dal 2021.

Perché il 90% la ignora

Perché la velocità è invisibile in fase di progettazione: il cliente vede il sito sul suo Mac con fibra ottica e lo percepisce come veloce. Solo quando va in produzione, su mobile 4G, il problema emerge. La soluzione è testare il sito su Lighthouse e PageSpeed Insights prima della consegna, e richiedere un budget di ottimizzazione performance come parte del progetto.

Legge 7: Il design mobile-first non è una feature, è un vincolo

Il 65% del traffico web globale è da mobile. Progettare per desktop e adattare a mobile è sbagliato: il sito mobile non è una versione ridotta, è il sito. La versione desktop è il bonus.

Prima

• Progetto iniziato da desktop a 1440px
• Elementi compressi su mobile per mancanza di spazio
• Menu hamburger con 12 voci tutte nello stesso ordine
• Form con campi affiancati che su mobile diventano illeggibili
• Tabelle desktop mostrate male su mobile

Dopo

• Progetto iniziato da mobile a 375px
• Layout a colonna singola, elementi full-width
• Menu contestuale, massimo 4-5 voci principali
• Form a colonna singola, campi ben distanziati (altezza minima 44px per touch)
• Tabelle trasformate in card stack su mobile

Metrica di successo

Mobile usability score in Google Search Console: deve essere al 100% per tutte le paghe. Conversion rate mobile vs. desktop: per un e-commerce ben progettato mobile-first, il tasso mobile può essere superiore al desktop.

Perché il 90% la ignora

Perché i designer lavorano su schermi grandi e tendono a progettare per l'ambiente che li circonda. Inoltre, i clienti spesso chiedono prima la versione desktop perché "è più facile giudicare il design". La soluzione è imporre il mobile-first come metodo di lavoro, e mostrare al cliente entrambe le versioni ad ogni review.

Legge 8: L'accessibilità è un moltiplicatore, non un costo

Un sito accessibile non è solo etico o un obbligo di legge (in Italia la Legge Stanca lo richiede per i siti della PA, in Europa l'European Accessibility Act 2025 lo estende a molti settori privati). È anche un moltiplicatore di risultati: il 15-20% della popolazione ha qualche forma di disabilità, e un sito non accessibile esclude automaticamente questa fetta di utenti.

Prima

• Contrasto insufficiente (testo grigio su sfondo bianco)
• Bottoni con etichette vaghe ("clicca qui", "scopri")
• Form senza label espliciti, solo placeholder
• Video senza sottotitoli
• Navigazione impossibile da tastiera

Dopo

• Contrasto WCAG AA minimo (4.5:1 per testo normale)
• Bottoni con etichette descrittive ("Scarica la guida PDF", "Prenota la consulenza")
• Form con label sempre visibili, errori espliciti, focus visibile
• Video con sottotitoli e trascrizione
• Skip link, focus order corretto, ARIA labels dove necessario

Metrica di successo

Lighthouse Accessibility score sopra 95. Numero di errori in WAVE (Web Accessibility Evaluation Tool) pari a zero per le pagine principali. Per un e-commerce, l'accessibilità migliora la SEO (Google premia i siti accessibili) e aumenta la base di clienti raggiungibili del 15-20%.

Perché il 90% la ignora

Perché l'accessibilità è percepita come costo aggiuntivo e come "roba da avvocati". In realtà, integrare l'accessibilità fin dall'inizio del progetto costa poco (5-10% del budget) e retrofit dopo è costoso (30-50% del budget). La regola è: accessibilità come vincolo di progetto dal primo giorno, non come attività finale.

Legge 9: Ogni pagina deve avere un unico obiettivo misurabile

La differenza tra un sito da 500€ e uno da 50.000€ si vede nella chiarezza degli obiettivi. Un sito economico ha pagine che "presentano l'azienda" in modo generico. Un sito professionale ha pagine con un obiettivo specifico e misurabile: contatto, download, acquisto, registrazione, visualizzazione di un video.

Prima

• Homepage: "benvenuti, chi siamo"
• Chi siamo: storia dell'azienda, valori, mission
• Servizi: descrizione generica dei servizi offerti
• Contattaci: form generico + mappa + indirizzo
• Nessuna misurazione del successo

Dopo

• Homepage: 1 CTA (contatto), 1 obiettivo (generare lead qualificati)
• Chi siamo: 1 CTA (contatto), 1 obiettivo (costruire fiducia per la conversione)
• Servizi: 1 CTA per servizio (preventivo, demo, call), obiettivo diverso per pagina
• Case study: 1 CTA (contatto), 1 obiettivo (dimostrare expertise)
• Blog: nessun CTA aggressivo, obiettivo (SEO, lead nurturing, educazione)
• Ogni pagina ha KPI misurato con GA4 e heatmap

Metrica di successo

Per ogni pagina, almeno un KPI: tasso di conversione, tempo medio, scroll depth, micro-conversioni. Un sito professionale sa dire "questa pagina converte al 4,2%, voglio portarlo al 6% nei prossimi 3 mesi". Un sito economico non sa dire nulla di tutto ciò.

Perché il 90% la ignora

Perché richiede un cambio di mentalità da "sito come brochure" a "sito come strumento di business". I freelance che fanno siti da 500€ non hanno le competenze (o la volontà) di impostare analytics avanzati, definire funnel, e misurare i risultati. La soluzione è offrire ai clienti un servizio di CRO (Conversion Rate Optimization) continuativo, che diventa una fonte di reddito ricorrente.

Le 9 leggi in sintesi: il framework operativo

Le 9 leggi possono essere condensate in un framework operativo in 5 punti, applicabile a qualsiasi progetto:

1. Prima misura, poi progetta: prima di disegnare, definisci gli obiettivi di business e gli KPI. Se non sai cosa misurare, non sai cosa ottimizzare.
2. Poi semplifica: ogni pagina ha un obiettivo, una CTA, un messaggio. Se una sezione non serve, toglila.
3. Tipografia e spazio bianco: imposta questi due elementi con cura, e il 60% del design è fatto.
4. Mobile-first: parti da 375px, scala verso l'alto, non il contrario.
5. Test, misura, itera: dopo il lancio, monitora le metriche e ottimizza continuamente.

Come applicare le 9 leggi al tuo prossimo progetto

Un metodo pratico per integrare queste leggi in qualsiasi progetto, dal primo brief alla consegna finale.

Prima del progetto: brief e obiettivi

1. Chiedi al cliente: "Qual è l'azione più importante che un visitatore dovrebbe fare sul tuo sito?"
2. Chiedi: "Come misurerai il successo di questo sito nei prossimi 6 mesi?"
3. Definisci 3-5 KPI misurabili e i loro target numerici

Durante il progetto: design e sviluppo

1. Mobile-first, sempre
2. Una CTA per schermata, una gerarchia tipografica chiara
3. Spazio bianco generoso, immagini specifiche
4. Performance integrata nel processo, non aggiunta alla fine
5. Accessibilità come vincolo, non come checklist finale

Dopo il lancio: ottimizzazione continua

1. Monitora GA4 + Search Console + Hotjar o Microsoft Clarity
2. A/B test su CTA, hero, form, pagine di servizio
3. Aggiorna contenuti trimestralmente, design annualmente
4. Report trimestrale al cliente con numeri e prossime azioni

Domande frequenti

Queste leggi funzionano per qualsiasi tipo di sito?

Sì, con adattamenti. Le 9 leggi sono state distillate su e-commerce, siti corporate, blog editoriali, SaaS, e portali. Il framework è universale, l'applicazione specifica varia per settore. Per un e-commerce, le leggi 2, 4, 6 sono critiche. Per un SaaS, le leggi 1, 5, 9 sono critiche. Per un blog editoriale, le leggi 3, 6, 7 sono critiche.

Quanto costa applicare tutte le 9 leggi?

Per un sito da 5.000-10.000€ di budget, le 9 leggi sono applicabili con poco overhead. Per un sito da 1.000-2.000€ di budget, alcune leggi richiedono compromessi: si può usare un template premium ben fatto invece di design custom, o foto stock di alta qualità invece di shooting dedicati. La qualità del risultato dipende dalla coerenza con cui le leggi sono applicate, non dal budget assoluto.

Un cliente può applicare le 9 leggi da solo?

In parte sì, ma il valore aggiunto di un professionista è enorme. Le leggi 1, 2, 9 richiedono competenze di strategia e marketing. Le leggi 3, 4, 5 richiedono competenze di design. Le leggi 6, 7, 8 richiedono competenze tecniche. Un professionista esperto le integra tutte, un cliente fai-da-te di solito ne trascura 3-4.

Le 9 leggi cambieranno nel 2027?

Alcune sì, altre sono stabili. Le leggi 3 (tipografia), 4 (spazio bianco), 5 (immagini specifiche), 8 (accessibilità) sono abbastanza stabili nel tempo. Le leggi 1 (CTA), 2 (CTA singola), 9 (obiettivi misurabili) evolvono con i pattern di interazione (es. voice UI, interfacce conversazionali). Le leggi 6 (velocità), 7 (mobile-first) evolvono con la tecnologia (es. 5G, AI integrata nel browser).

Cosa distingue un web designer professionista da uno improvvisato?

L'applicazione coerente di queste 9 leggi, unita alla capacità di spiegarle al cliente e di difendere le scelte di design anche quando sembrano controintuitive. Il professionista è pagato per il giudizio, non per il numero di schermate prodotte.

Riferimenti ufficiali

Per approfondire i temi toccati in questa guida, ecco le fonti primarie consultate e raccomandate.

• Lighthouse - auditing performance e accessibilità.
• Web Vitals - metriche Google per il web.
• WCAG 2.2 - standard accessibilità W3C.
• WAVE - valutatore accessibilità.
• Hotjar - heatmap e registrazioni sessioni.
• Microsoft Clarity - alternativa gratuita a Hotjar.
• Google Analytics 4 - analytics web.
• Google Search Console - monitoraggio SEO.
• Stripe Press - An Elegant Puzzle - libro su sistemi e design di prodotto.
• Refactoring UI - libro pratico su web design.
• Strumenti grafica web 2026 mrtux.it - tool design 2026.
• Workflow perfetto sviluppo web mrtux.it - framework 7 stadi.

Questa guida è un manifesto editoriale: verrà aggiornata annualmente con nuove leggi e con l'evoluzione di quelle esistenti. Per suggerimenti o correzioni, l'area commenti è aperta.

Questo articolo non è la classica lista dei "15 tool che devi conoscere". È una mappa operativa dei 5 layer che oggi compongono una toolchain grafica moderna, con gli strumenti specifici che ho testato negli ultimi sei mesi su progetti reali (e-commerce, SaaS B2B, portali editoriali). È lo stesso approccio che uso per creare plugin WordPress con AI e per la toolchain AI dello sviluppatore, applicato però al lato visuale del web.

L'obiettivo è chiaro: smontare l'illusione che "strumenti di grafica" significhi ancora "software per disegnare". Oggi significa orchestrare cinque famiglie diverse, ognuna con un ruolo preciso, dove l'errore più comune è comprarne tre che fanno la stessa cosa.

La mappa mentale: perché il 2026 è diverso dal 2023

Nel 2023 un graphic designer web usava Figma + Photoshop + Illustrator + un pizzico di After Effects. Tre anni dopo, quei quattro software esistono ancora ma non sono più il centro del flusso: sono diventati interfacce verso sistemi sottostanti che generano design da prompt, da codice, da dati, da componenti riutilizzabili.

Il cambio di paradigma si misura in tre indicatori concreti:

• Dal mockup al design system operativo: un file Figma non è più un'immagine da consegnare, è una sorgente di codice (React, SwiftUI, Jetpack Compose) che l'AI aggiorna in tempo reale.
• Dalle risorse statiche ai modelli generativi: la foto stock di un'eroe di homepage non si scarica più da Unsplash, si genera con un modello multimodale coerente col brand.
• Dall'animazione artigianale al motion design semantico: il CSS keyframe non si scrive a mano, si dichiara in linguaggio naturale e un motore lo traduce.

Questo significa che comprare un nuovo tool di grafica nel 2026 non è una scelta di software: è una scelta di ecosistema. E gli ecosistemi sono pochi, si parlano poco tra loro, e hanno lock-in sempre più forti.

I 5 layer della toolchain grafica 2026

Una toolchain grafica moderna si compone di cinque layer, ognuno con strumenti specializzati. Conoscerli tutti significa poter scegliere per ruolo, non per moda.

Adesso vediamo ogni layer in dettaglio, con pro, contro e il tipo di progetto per cui conviene.

Layer 1: Generazione visiva (immagini e foto)

Il primo strato è quello che nel 2023 chiamavamo "AI image generation". Nel 2026 non è più una categoria a parte: è una commodity integrata ovunque, e il suo valore si è spostato dalla qualità del singolo output alla coerenza con il brand system.

Gli strumenti che contano oggi sono cinque, e ognuno ha un profilo diverso.

Midjourney v7: il re incontrastato della qualità artistica

Midjourney v7 (rilasciato a inizio 2026) ha alzato l'asticella della coerenza stilistica: con un singolo prompt e un riferimento visivo, genera dieci varianti che mantengono palette, illuminazione e tipografia di impaginazione. Per chi fa branding, illustrazione editoriale, e concept art, resta il punto di riferimento. Il limite storico (no vettoriale, no API stabile) è stato parzialmente risolto: l'API v2 di Midjourney permette ora generazione batch con parametri di stile persistenti.

Pro: qualità visiva imbattuta su ritratti, scene complesse, illustrazione editoriale. Contro: 240€/anno per il piano Standard, 720€ per Mega; nessun vero editor integrato (si usa ancora Discord o la web app minimale). Quando sceglierlo: hero image, illustrazioni editoriali, concept design, mockup emozionali.

Adobe Firefly 4: l'integrazione totale con la suite Adobe

Firefly 4 ha smesso di essere "il generatore di immagini di Adobe" ed è diventato il collante AI dell'intera Creative Cloud. Genera immagini, vettoriali, variazioni tipografiche, effetti Photoshop generativi, e riempimenti contestuali in Illustrator. Il vantaggio competitivo non è la qualità del singolo output (Midjourney vince ancora), è l'integrazione: un asset generato in Firefly arriva in Photoshop con livelli, maschere e metadati di provenienza intatti.

Pro: integrazione totale con Photoshop, Illustrator, InDesign, Express; licenza commerciale chiara (modelli addestrati solo su contenuti Adobe Stock e pubblico dominio). Contro: 60€/mese per il piano completo Creative Cloud con Firefly Premium; qualità artistica inferiore a Midjourney su scene complesse. Quando sceglierlo: agenzie, team già su Adobe, progetti con vincoli di licenza commerciale stringenti.

Recraft v3: il vettoriale generativo

Recraft v3 è stato il primo modello a generare vettoriale pulito (SVG, EPS) direttamente da prompt, con gestione di palette personalizzate e stile di tratto. È lo strumento ideale per loghi, icone, illustrazioni editoriali, e infografiche scalabili. La qualità del vettoriale generato è oggi paragonabile a quella di un illustratore professionista su task semplici (icone, loghi geometrici, pattern), e superiore su task ripetitivi (generare 50 varianti di un'icona con colori diversi).

Pro: output vettoriale nativo, modificabile in Illustrator o Figma; supporto di brand kit; API stabile. Contro: 240€/anno per il piano Pro; qualità inferiore a Midjourney su scene fotorealistiche; comunità più piccola. Quando sceglierlo: loghi, set di icone, illustrazioni vettoriali, infografiche, merchandise.

FLUX.1 Pro e Ideogram 2.0: gli outsider

FLUX.1 Pro (Black Forest Labs) e Ideogram 2.0 sono i due modelli che nel 2026 hanno rosicchiato quote a Midjourney e Firefly con un posizionamento tecnico preciso. FLUX.1 Pro eccelle su testo rendering (scritte perfette nelle immagini, problema storico della generazione) ed è open source nella versione base. Ideogram 2.0 ha il miglior rapporto qualità/prezzo per uso massivo (piano Free generoso, Pro a 96€/anno) e una pipeline di generazione tipografica superiore.

Pro FLUX: testo rendering perfetto, modello open source disponibile per self-hosting, API economica. Pro Ideogram: pricing accessibile, tipografia di qualità, generazione di poster e grafiche social. Quando sceglierli: campagne social ad alto volume, grafiche con molto testo, integrazioni custom via API.

Layer 2: Vettoriale e illustrazione tradizionale

Il vettoriale non è morto, ma è diventato ibrido: si disegna a mano, si genera con AI, si corregge a mano, si ri-genera. Gli strumenti del 2026 devono gestire entrambi i workflow senza frizione.

Figma 2026: molto più di un editor di mockup

Figma nel 2026 è una piattaforma di design system operativa. Le funzioni chiave per chi fa grafica web sono quattro:

• Variables e Modes: token semantici (colore, tipografia, spacing) con supporto nativo per light/dark mode e temi multipli.
• Code Connect: collega i componenti Figma al codice reale (React, Jetpack Compose, SwiftUI) mantenendo la documentazione sincronizzata.
• Figma Make: generazione di micro-app e prototipi interattivi da prompt.
• Plugin AI nativi: rimozione sfondo, generazione varianti, traduzione testi contestuali, reflow automatico per accessibility.

Pro: standard de facto, integrazione totale con il codice, community immensa. Contro: 180€/anno per il piano Professional; alcune funzioni AI (Make, Code Connect) sono in beta a capacity limitata; lock-in reale sui design system aziendali.

Penpot: l'alternativa open source

Per chi ha vincoli di budget o di data residency, Penpot è l'unica alternativa credibile a Figma. È open source (Mozilla Public License 2.0), self-hostable, e nel 2026 ha raggiunto la parità funzionale sui token e sui componenti. Manca ancora l'ecosistema di plugin di Figma e l'integrazione con Code Connect, ma per un team di 3-5 designer che vuole un design system on-premise, è la scelta razionale.

Pro: open source, self-hostable, gratuito, parità funzionale con Figma sui token. Contro: community plugin più piccola, integrazione con codice meno matura, performance inferiori su file molto grandi.

Layer 3: UI/UX, prototipazione e wireframe

Il terzo layer è quello in cui la grafica web incontra il prodotto. Qui la distinzione tradizionale tra "design" e "sviluppo" si è praticamente azzerata.

Framer e Visual Copilot: prototipazione che diventa sito

Framer nel 2026 è diventato un CMS visuale con hosting integrato: disegni in Figma, importi in Framer, colleghi un CMS (Sanity, Contentful, Strapi), e il sito va online senza scrivere codice. Il limite è la scalabilità: ottimo per landing page, siti vetrina, portfolio; insufficiente per applicazioni complesse.

Visual Copilot (Figma + AI di Codeium) traduce i mockup Figma in codice React/Vue/HTML con accuratezza del 90% su layout semplici, 70% su componenti complessi. Non sostituisce lo sviluppatore, ma riduce il tempo di traduzione mockup-codice da ore a minuti.

Galileo AI: il prompt-to-UI che funziona

Galileo AI è il leader del prompt-to-UI. Scrivi "dashboard admin per SaaS B2B con sidebar collapsible, tabella utenti, card metriche KPI", e genera un mockup Figma pronto all'uso. La qualità è sorprendente su pattern noti (dashboard, e-commerce, landing), deludente su interfacce molto innovative. Costo: 240€/anno per il piano Pro.

Layer 4: Animazione, motion design e Lottie

Il motion design è il layer dove la differenza tra brand mediocri e brand memorabili si gioca. Nel 2026 non basta più mettere un'animazione Lottie hero in homepage: serve un linguaggio di movimento coerente con il sistema di design.

Rive 2026: il nuovo standard interattivo

Rive ha conquistato il mercato delle microinterazioni web e mobile con un editor visuale che esporta runtime nativi per WebGL, iOS, Android, e ora anche Jetpack Compose. Il vantaggio rispetto a Lottie è la programmabilità: una State Machine in Rive gestisce stati, transizioni, e input utente in modo dichiarativo. Per chi vuole pulsanti, loader, e microinterazioni con logica complessa (hover, pressed, success, error), Rive è oggi lo standard.

Pro: runtime performante su qualsiasi piattaforma, State Machine integrata, supporto audio. Contro: 180€/anno per il piano Pro; curva di apprendimento per chi viene da After Effects.

Lottie AI e Motion Array AI: il video generativo per il web

Lottie AI aggiunge al formato Lottie la generazione automatica di animazioni da prompt testuali. Per banner pubblicitari, loader, e animazioni decorative, riduce i tempi di produzione dell'80%. Motion Array AI è più orientato al video editoriale: genera clip di stock animate con AI, integrabili direttamente in Webflow, Framer, o come <video> ottimizzati con Lottie Player.

Layer 5: Sistemi di design agentici (il vero cambio di paradigma)

Il quinto layer è quello che nel 2026 separa i team tradizionali dai team agentici. Un sistema di design agentico non è un software: è un'architettura in cui il design system parla direttamente con il codice di produzione, mantenuto da agenti AI che generano, testano e correggono i componenti.

Figma Make + Code Connect: il design system che scrive codice

Figma Make genera prototipi funzionanti da descrizioni in linguaggio naturale. Code Connect mantiene il mapping bidirezionale tra componenti Figma e componenti codice (React, Vue, Jetpack Compose). Insieme, permettono a un designer di aggiornare un bottone in Figma e vedere la modifica applicata automaticamente al repository di sviluppo, con tanto di test di regressione visiva.

Questo non è il futuro: è il presente di team come Shopify, Stripe, e Linear, che usano Code Connect da almeno due anni.

V0.dev, Locofy, Builder.io Fusion: i concorrenti specializzati

V0.dev (Vercel) genera componenti React/Next.js Tailwind da prompt, con preview live e deploy. Locofy aggiunge supporto multi-framework (React Native, Flutter, HTML/CSS). Builder.io Fusion è l'opzione enterprise: CMS visuale + AI + generazione di pagine complete, con integrazione nativa con Shopify, Salesforce, e HubSpot.

Costo: da 480€/anno (V0 Pro) a 1800€/anno (Builder.io Enterprise).

Come scegliere la toolchain giusta per il tuo progetto

Non tutti i 5 layer servono a tutti i progetti. Ecco come raggruppare gli strumenti per contesto reale, evitando l'errore più comune (comprare sei software che fanno cose sovrapposte).

Confronto rapido: quale stack per quale progetto

La regola operativa è semplice: meno è meglio, purché ogni layer sia coperto da almeno uno strumento specializzato. Un freelance che fa siti vetrina non ha bisogno di Builder.io Enterprise; un'agenzia con 30 clienti non può permettersi Penpot self-hosted. Il disallineamento tra complessità del progetto e costo della toolchain è la causa numero uno di tool che non si usano.

Stack per freelance o piccolo studio

La toolchain minima di un freelance che fa siti vetrina e piccoli e-commerce è:

• Layer 1: Midjourney v7 o Recraft v3 (240€/anno) — uno solo dei due, non entrambi.
• Layer 2: Figma Professional (180€/anno) — Figma copre l'80% del vettoriale, Illustrator serve solo per loghi complessi (acquisto on-demand a 30€/mese).
• Layer 3: Figma + Figma Make (incluso) — Make è sufficiente per prototipare landing page.
• Layer 4: Rive Free + Lottie open source — per la maggior parte dei progetti basta il piano gratuito.
• Layer 5: V0.dev Free o Pro (0-480€/anno) — sufficiente per generare sezioni di landing page in Next.js.

Costo totale realistico: 600-900€/anno per una toolchain completa e produttiva.

Stack per agenzia di medie dimensioni

Un'agenzia con 10-30 designer e sviluppatori ha bisogno di governance, non di più software.

• Layer 1: Adobe Firefly 4 in Creative Cloud Team (660€/anno per utente) — integrazione totale con la pipeline Adobe esistente.
• Layer 2: Figma Organization (540€/anno per utente) — per library condivise, design system, e SSO.
• Layer 3: Figma + Visual Copilot (incluso nei piani superiori) — prototipazione veloce e code generation.
• Layer 4: Rive Pro (180€/anno per utente) + After Effects (incluso in CC).
• Layer 5: Builder.io Fusion (1800€/anno flat) — CMS visuale + AI per landing page e componenti dinamici.

Costo totale realistico: 1500-2500€/anno per designer.

Stack per software house B2B

Una software house che sviluppa prodotti SaaS ha esigenze diverse: integrazione profonda con il codice, governance, sicurezza.

• Layer 1: FLUX.1 Pro self-hosted o API (0-2000€/anno) — modello interno, no dati in cloud.
• Layer 2: Figma Organization con SSO e audit log (540€/anno per utente).
• Layer 3: Figma + Code Connect + Storybook (open source) — la triade che permette di mantenere documentazione e codice sincronizzati.
• Layer 4: Rive + Lottie Player open source (180€/anno per utente).
• Layer 5: Anima o Locofy Enterprise (su preventivo) — code generation da Figma con QA integrato.

Costo totale realistico: 1200-3000€/anno per designer, con la possibilità di ammortizzare i costi su decine di progetti.

Errori comuni nella scelta degli strumenti di grafica 2026

Gli errori che vedo più spesso quando un team rinnova la toolchain grafica sono cinque, tutti evitabili.

Il primo è la sovrapposizione tra layer 1 e layer 2: comprare Midjourney e Firefly quando il team usa solo output di uno dei due. Il secondo è ignorare i costi ricorrenti di plugin e template, che possono raddoppiare il budget senza migliorare la produttività. Il terzo è sottovalutare la curva di apprendimento di Rive, Figma Make, o Builder.io: servono almeno 4-6 settimane prima che il team sia produttivo, non 2 giorni.

Il quarto errore è comprare Builder.io o Framer per un sito che andrebbe fatto in WordPress o Next.js statico: sono strumenti potenti, ma per il 70% dei siti vetrina sono overkill, e il lock-in è alto. Il quinto è dimenticare l'accessibilità: strumenti come Stark (integrato in Figma) o Polypane (browser per testare accessibilità) dovrebbero essere parte integrante della toolchain, non optional.

Come iniziare: una roadmap in 30 giorni

Per un team che oggi usa Figma + Photoshop e vuole passare a una toolchain grafica 2026, la roadmap che consiglio è questa.

1. Settimana 1: fai un audit degli strumenti attuali. Quali usi davvero, ogni settimana? Quali hai comprato e mai aperto? Elimina tutto ciò che non è core.
2. Settimana 2: scegli un solo strumento per il layer 1 (Midjourney o Firefly) e uno solo per il layer 2 (Figma). Smetti di usare Photoshop per task che Recraft o Figma possono fare in 10 secondi.
3. Settimana 3: introduci Figma Make o V0.dev per un solo progetto pilota. Misura quanto tempo risparmi nella traduzione mockup-codice.
4. Settimana 4: aggiungi Rive per le microinterazioni di un progetto reale. Valuta se il ROI giustifica i 180€/anno.
5. Mese 2: decidi se investire nel layer 5 (Builder.io, Anima) in base ai risultati del pilota. Non comprare nulla in anticipo.

Una toolchain grafica 2026 che funziona è quella che usi davvero, non quella che ha più funzioni. La produttività reale si misura in cicli completati, non in tool attivi.

Domande frequenti

Qual è il primo strumento da comprare nel 2026 per chi parte da zero?

Figma Professional (180€/anno) resta la scelta razionale: copre wireframe, UI, prototipazione, e gran parte del vettoriale. Aggiungi Midjourney o Firefly (240€/anno) solo se fai grafica generativa su base regolare. Per il resto, Figma + plugin gratuiti bastano per i primi sei mesi.

Midjourney è ancora il migliore nel 2026?

Per qualità artistica pura, sì. Midjourney v7 è ancora in vantaggio su ritratti, scene complesse, e illustrazione editoriale. Per integrazione con flussi Adobe, Firefly vince. Per testo rendering perfetto nelle immagini, FLUX.1 Pro è imbattuto. La risposta onesta è: dipende dal task.

Figma è ancora rilevante con l'arrivo di tutti questi tool AI?

Sì, ma il ruolo è cambiato. Figma non è più "dove disegno i mockup": è "dove definisco i token del design system e dove mappo i componenti al codice". Nel 2026 un designer Figma che non conosce Variables, Modes, e Code Connect sta usando Figma come fosse il 2022. È un altro strumento, anche se l'interfaccia sembra la stessa.

Quanto costa una toolchain grafica completa nel 2026?

Tra 600€ e 3000€ all'anno per designer, a seconda della complessità dei progetti e della dimensione del team. Il costo nascosto è il tempo di apprendimento: un nuovo strumento costa 2-6 settimane di produttività ridotta prima di essere padroneggiato. Pianifica sempre una fase di adozione realistica.

Gli strumenti AI sostituiscono un graphic designer?

No, nel 2026. L'AI accelera la generazione di asset, la produzione di varianti, e la manutenzione del design system. Le decisioni di brand, la coerenza visiva su larga scala, e l'interpretazione del brief restano compiti umani. Un graphic designer con una toolchain 2026 è 3-5 volte più produttivo. Un junior senza giudizio critico e tool AI genera asset inconsistenti 3-5 volte più velocemente.

Conviene investire in Builder.io o V0.dev?

Dipende dal volume di landing page e componenti dinamici che produci. Se fai 2-3 siti all'anno, V0.dev Free basta. Se gestisci 30+ landing page per e-commerce con personalizzazione per audience, Builder.io Fusion si ripaga in 3-4 mesi. Per la maggior parte dei freelance e delle piccole agenzie, è overkill.

Rive sta davvero sostituendo Lottie?

Su microinterazioni complesse con logica (stati, transizioni, input), sì. Su animazioni decorative semplici (loader, hero, badge), Lottie resta più semplice e leggero. Nel 2026 la scelta non è "Rive o Lottie": è "Rive per interazioni, Lottie per decorazioni". I due formati convivono, ognuno con il suo ruolo.

Riferimenti ufficiali

Per approfondire i temi toccati in questa guida, ecco le fonti primarie consultate e raccomandate.

• Sito ufficiale Midjourney - generazione immagini di qualità artistica.
• Adobe Firefly - AI integrata nella Creative Cloud.
• Recraft - vettoriale generativo.
• FLUX.1 Pro di Black Forest Labs - modello open con API.
• Ideogram - generazione tipografica.
• Figma - piattaforma di design system.
• Penpot - alternativa open source a Figma.
• Framer - prototipazione con hosting.
• Galileo AI - prompt-to-UI.
• Rive - animazione interattiva con State Machine.
• Lottie Files - formato animazione web.
• V0.dev - generazione componenti React da prompt.
• Builder.io Fusion - CMS visuale enterprise.
• Storybook - documentazione componenti.
• Stark - accessibilità integrata in Figma.
• Web Content Accessibility Guidelines (WCAG) 2.2 - standard accessibilità W3C.

Questa guida verrà aggiornata ogni sei mesi, in coincidenza con i rilasci principali di Figma, dei modelli generativi, e dei framework di design system. Per suggerimenti o correzioni, l'area commenti è aperta.

È qui che entra in gioco DESIGN.md, il nuovo formato open source pubblicato da Google Labs Code per descrivere una visual identity in modo leggibile sia dagli esseri umani sia dagli agenti di coding. L’idea è semplice ma molto potente: creare un file testuale, versionabile e validabile che contenga design token, razionale visivo, regole sui componenti e indicazioni pratiche su cosa fare e cosa evitare.

In altre parole, DESIGN.md prova a diventare per il design quello che altri file di configurazione sono già diventati per sviluppo, linting, formattazione e automazione: una fonte di verità chiara, portabile e adatta ai workflow moderni con AI.

Cos’è DESIGN.md e perché è importante

DESIGN.md è un formato pensato per descrivere l’identità visiva di un prodotto agli agenti di codice. La definizione ufficiale del repository google-labs-code/design.md parla di una specifica per dare agli agenti una comprensione persistente e strutturata di un design system.

Il punto chiave è la parola persistente. Un agente AI può ricevere istruzioni nel prompt, ma quelle istruzioni spesso sono temporanee, incomplete o ambigue. Un file DESIGN.md, invece, può stare nel repository accanto al codice, essere revisionato in pull request, validato con una CLI e riutilizzato da strumenti diversi.

Il formato unisce due livelli:

• una parte machine-readable in YAML front matter, dove vengono definiti token come colori, tipografia, spacing, radius e componenti;
• una parte human-readable in Markdown, dove si spiega il perché delle scelte e come applicarle in situazioni reali.

Questa combinazione è interessante perché i soli token non bastano. Sapere che il colore primario è #1A1C1E dice poco sul tono dell’interfaccia. Sapere anche che quel colore rappresenta “deep ink”, autorevolezza e leggibilità editoriale aiuta l’agente a usarlo con più coerenza.

Il problema che DESIGN.md prova a risolvere

Molti team hanno già un design system, ma spesso è distribuito in troppi luoghi: Figma, Storybook, documentazione interna, file CSS, Tailwind config, component library, issue di progetto e memoria informale del team. Quando entra in scena un agente AI, questa frammentazione diventa un problema tecnico.

Un agente può generare una pagina funzionante, ma senza un contesto stabile rischia di:

• inventare colori non presenti nel brand;
• usare font o pesi tipografici incoerenti;
• creare bottoni con radius e padding casuali;
• mescolare stili editoriali, SaaS, dashboard e landing page;
• ignorare contrasto e accessibilità;
• produrre componenti apparentemente belli ma scollegati dal sistema reale.

DESIGN.md riduce questo rischio perché trasforma le linee guida di design in un contratto leggibile dal codice e dagli agenti. Non sostituisce Figma o una libreria componenti, ma aggiunge un livello di istruzioni condivise che può viaggiare con il repository.

Come è fatto un file DESIGN.md

La struttura ufficiale prevede un file Markdown con front matter YAML opzionale. Il front matter contiene i token normativi; il corpo Markdown contiene spiegazioni, razionale e linee guida.

Ecco un esempio semplificato:

---
version: alpha
name: Editorial Tech
colors:
  primary: "#1A1C1E"
  secondary: "#6C7278"
  tertiary: "#B8422E"
  neutral: "#F7F5F2"
typography:
  headline-lg:
    fontFamily: Public Sans
    fontSize: 48px
    fontWeight: 600
    lineHeight: 1.1
  body-md:
    fontFamily: Public Sans
    fontSize: 16px
    fontWeight: 400
    lineHeight: 1.6
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 8px
  md: 16px
  lg: 32px
components:
  button-primary:
    backgroundColor: "{colors.tertiary}"
    textColor: "#ffffff"
    rounded: "{rounded.sm}"
    padding: 12px
---

## Overview

Interfaccia editoriale, tecnica e autorevole. Il prodotto deve comunicare
precisione, leggibilità e affidabilità, evitando decorazioni inutili.

## Colors

Il colore primario è usato per testi e titoli. Il terziario è riservato
alle azioni principali e agli stati di enfasi.

Questo esempio mostra il principio operativo: i valori precisi sono nei token, mentre il Markdown spiega come interpretarli. Un agente può quindi rispettare sia la misura esatta sia l’intenzione progettuale.

I token supportati: colori, tipografia, spacing e componenti

La specifica ufficiale descrive un insieme di gruppi token pensati per coprire gli aspetti fondamentali di una UI.

I gruppi principali sono:

• colors, per palette e ruoli cromatici;
• typography, per font, dimensioni, pesi, line-height e letter-spacing;
• rounded, per la scala dei bordi arrotondati;
• spacing, per distanze, margini e ritmo visivo;
• components, per collegare i token a elementi come bottoni, chip, input e stati.

Un dettaglio tecnico importante è il supporto ai riferimenti tra token con sintassi {path.to.token}. Per esempio, un bottone può usare backgroundColor: "{colors.tertiary}", evitando duplicazione e riducendo il rischio di divergenze.

Questa scelta rende DESIGN.md più simile a un piccolo linguaggio di configurazione che a una semplice pagina di documentazione. È leggibile, ma anche analizzabile da un linter.

Le sezioni Markdown consigliate

Il corpo del file non è libero in modo caotico. La specifica suggerisce un ordine canonico delle sezioni, tutte basate su heading ##:

1. Overview;
2. Colors;
3. Typography;
4. Layout;
5. Elevation & Depth;
6. Shapes;
7. Components;
8. Do’s and Don’ts.

Questo ordine serve a dare prevedibilità agli strumenti. Un agente sa dove cercare la personalità visiva, dove trovare le regole tipografiche, dove leggere i vincoli di layout e dove individuare errori da evitare.

La scelta è pragmatica: DESIGN.md non vuole essere un trattato di brand identity, ma un formato operativo. Deve essere abbastanza espressivo per guidare un’interfaccia reale, ma abbastanza strutturato per essere letto e validato da una CLI.

Esempio pratico: usare DESIGN.md in un progetto frontend

Immagina un team che sta costruendo una dashboard SaaS. Nel repository sono presenti componenti React, Tailwind, test e documentazione. Senza DESIGN.md, un agente AI chiamato a creare una nuova pagina “Billing” potrebbe copiare pattern visti in altre parti del codice, ma potrebbe anche introdurre nuove sfumature, radius non standard o gerarchie tipografiche incoerenti.

Con DESIGN.md, il workflow diventa più controllabile:

1. il team definisce colori, tipografia, spacing e componenti principali;
2. il file viene salvato nel repository;
3. l’agente legge DESIGN.md prima di generare UI;
4. la CLI valida token, riferimenti e contrasto;
5. eventuali modifiche al design system vengono confrontate con diff.

Il risultato non è una garanzia assoluta di qualità, ma riduce drasticamente l’improvvisazione. In un contesto con più agenti o più sviluppatori, questo è un vantaggio concreto.

Comandi CLI: lint, diff, export e spec

Google distribuisce anche una CLI installabile come pacchetto npm @google/design.md. Dal README ufficiale emerge un set di comandi pensato per validare, confrontare ed esportare il formato.

Il comando più immediato è il lint:

# comando lint
npx @google/design.md lint DESIGN.md

Il linter restituisce JSON strutturato con finding, severità, percorso e messaggio. Questo è utile perché un agente può leggere l’output e correggere il file in modo mirato.

Per confrontare due versioni:

# confronto due versioni
npx @google/design.md diff DESIGN.md DESIGN-v2.md

Questo aiuta a capire se sono stati aggiunti, rimossi o modificati token. In una pull request, può diventare un controllo utile per evitare regressioni nel design system.

Per esportare i token:

npx @google/design.md export --format json-tailwind DESIGN.md > tailwind.theme.json
npx @google/design.md export --format css-tailwind DESIGN.md > theme.css
npx @google/design.md export --format dtcg DESIGN.md > tokens.json

Gli export sono importanti perché collegano DESIGN.md agli strumenti già usati dai team: Tailwind, CSS custom properties e formati compatibili con il mondo dei design token.

Un riferimento pratico da aggiungere al workflow è Stitch di Google, che consente di lavorare su interfacce e prototipi con un percorso orientato anche all’esportazione nel formato DESIGN.md. Questo rende il file ancora più interessante: non è solo una specifica da scrivere manualmente, ma può diventare un formato di passaggio tra progettazione visuale, generazione assistita e codice.

Le regole di linting più utili

La documentazione cita diverse regole di linting, tra cui riferimenti rotti, contrasto, assenza di colore primario, token orfani, sezioni mancanti, tipografia mancante e ordine delle sezioni.

Queste verifiche rendono DESIGN.md più serio di una semplice convenzione testuale. Un file può essere scritto male, ma la CLI permette di intercettare almeno una parte degli errori prima che arrivino nel codice generato.

Perché DESIGN.md interessa a chi lavora con AI coding agent

Il valore più evidente è per chi usa agenti AI nel frontend. Strumenti di coding assistito possono già generare componenti, landing page e layout, ma spesso hanno bisogno di contesto. DESIGN.md offre quel contesto in una forma leggera.

Un agente può leggere frasi come:

• “usa il colore primario solo per l’azione più importante”;
• “evita ombre pesanti, usa gerarchie tonali”;
• “mantieni radius da 4px per un aspetto tecnico”;
• “non usare più di due pesi tipografici nella stessa schermata”.

Queste indicazioni sono diverse dai token numerici. Sono regole di comportamento progettuale. Per un essere umano sono normali linee guida; per un agente diventano vincoli espliciti da seguire.

Differenze rispetto a tokens.json, Figma variables e Tailwind config

DESIGN.md non nasce per sostituire tutto. Un file tokens.json resta più adatto allo scambio formale di token tra strumenti. Figma variables restano fondamentali nel lavoro dei designer. Tailwind config resta centrale quando si implementa una UI con utility class.

La differenza è che DESIGN.md mette nello stesso posto token e razionale. Questo lo rende particolarmente adatto agli agenti, perché gli agenti non hanno bisogno solo di valori: hanno bisogno di contesto.

Per esempio, un token può dire che tertiary vale #B8422E; il testo può spiegare che quel colore è “Boston Clay” e che deve essere usato solo per interazioni primarie. Questa seconda informazione può fare la differenza tra una UI coerente e una UI tecnicamente corretta ma visivamente confusa.

Limiti attuali del formato

DESIGN.md è indicato come formato in stato alpha. Questo significa che lo schema, la CLI e le convenzioni potrebbero cambiare. È quindi intelligente adottarlo con aspettative realistiche.

I limiti più evidenti sono:

• la specifica è ancora giovane;
• la sezione componenti è flessibile e in evoluzione;
• non sostituisce test visivi, review di design o accessibilità manuale;
• richiede disciplina nella manutenzione;
• può diventare obsoleto se non viene aggiornato insieme al prodotto.

Detto questo, il formato è già utile per sperimentare un workflow più ordinato tra design system e AI coding.

Come introdurre DESIGN.md in un team

Il modo migliore non è provare a documentare tutto subito. Conviene partire da un file piccolo ma accurato.

Un percorso pratico può essere:

1. definire nome, descrizione e personalità del prodotto;
2. inserire palette primaria, secondaria, accento e neutral;
3. aggiungere 4-6 livelli tipografici realmente usati;
4. documentare spacing e radius principali;
5. descrivere 3 componenti critici: bottone primario, card e input;
6. scrivere 5 regole “do” e 5 regole “don’t”;
7. eseguire il lint e correggere gli errori;
8. usare il file in una singola feature generata con agenti AI;
9. confrontare output generato prima e dopo DESIGN.md.

Questo approccio evita il classico errore dei design system: puntare alla perfezione iniziale e non arrivare mai all’adozione reale.

SEO tecnico e opportunità per sviluppatori WordPress

Anche se DESIGN.md nasce per agenti di codice e design system, il tema è rilevante anche per chi lavora con WordPress, temi custom e page builder avanzati. Un file di questo tipo potrebbe aiutare a mantenere coerenza visiva quando si generano componenti, blocchi Gutenberg, pattern di tema o layout con strumenti AI.

Per esempio, un team WordPress potrebbe creare un DESIGN.md per descrivere:

• palette del brand;
• gerarchia tipografica del tema;
• spaziature dei blocchi editoriali;
• stile di card, bottoni e call to action;
• regole per landing page e template WooCommerce;
• vincoli di accessibilità e contrasto.

In futuro, agenti AI capaci di leggere DESIGN.md potrebbero generare pattern Gutenberg più coerenti, componenti React per block editor o CSS custom properties allineate alla brand identity. È un ponte naturale tra content management, frontend engineering e automazione.

Per approfondire il tema nel contesto WordPress, sono collegati due percorsi utili: una guida su AI per migliorare SEO, UX e design su WordPress e un approfondimento sui tool essenziali per il web design WordPress. Entrambi aiutano a collegare DESIGN.md a casi d’uso concreti: coerenza visiva, automazione dei layout, qualità UX e produzione di interfacce più controllabili.

FAQ

DESIGN.md è un file di configurazione ufficiale di Google?

È un progetto open source pubblicato nel repository Google Labs Code. La specifica è in fase alpha e propone un formato per descrivere visual identity e design system agli agenti di coding.

DESIGN.md sostituisce Figma?

No. Figma resta uno strumento visuale per progettare, discutere e prototipare. DESIGN.md aggiunge un formato testuale, versionabile e leggibile dagli agenti, utile dentro i repository di codice.

Qual è la differenza tra DESIGN.md e design tokens?

I design token definiscono valori come colori, font, spacing e radius. DESIGN.md può contenere quei token, ma aggiunge anche spiegazioni in Markdown, cioè il razionale che aiuta gli agenti a capire come applicarli.

Si può usare DESIGN.md con Tailwind?

Sì. La CLI documenta export verso Tailwind v3 in JSON e Tailwind v4 tramite CSS @theme, oltre al formato DTCG per design token.

È pronto per la produzione?

È utilizzabile per sperimentazioni e workflow interni, ma va considerato un formato alpha. Prima di inserirlo in processi critici, conviene testarlo su un progetto pilota e monitorare l’evoluzione della specifica.

Conclusione

DESIGN.md è interessante perché affronta un problema reale: gli agenti AI possono scrivere codice, ma senza una memoria progettuale rischiano di generare interfacce incoerenti. Un file testuale, versionabile e validabile può diventare il ponte tra design system, frontend e automazione.

Il valore non sta solo nei token, ma nel contesto: colori con significato, tipografia con ruolo, componenti con stati, regole pratiche e divieti espliciti. Per chi lavora con AI coding agent, design system o sviluppo WordPress avanzato, DESIGN.md è un formato da osservare subito e da testare in un piccolo progetto reale.

Il consiglio pratico è semplice: crea un primo DESIGN.md con pochi token affidabili, aggiungi rationale chiaro, esegui il lint e usalo come contesto per un agente AI. La differenza nella coerenza dell’output diventa evidente appena il progetto supera la singola pagina dimostrativa.