Generatori di interfacce: prototipo veloce

I generatori di UI (v0.dev, Lovable, bolt.new, Magic Patterns, UIzard) producono schermate intere a partire da un prompt visivo o testuale. Sono ottimi per esplorare, dannosi se confusi con base produzione. Saperli usare significa estrarne velocità senza ereditarne il debito.

Perché questa lezione conta

Un generatore ti dà in 30 secondi una schermata che ti farebbe perdere mezza giornata partendo da zero. Per validare un’idea con uno stakeholder, per esplorare varianti UI, per partire da una struttura piuttosto che da una pagina bianca, è imbattibile. Ma il codice prodotto ha problemi sistematici (markup eccessivo, accessibilità superficiale, dipendenze pesanti, stile incoerente con la tua codebase). Trasformarlo in base di lavoro produttiva richiede consapevolezza esplicita.

Obiettivo operativo

Alla fine devi saper:

1. nominare cosa generano bene e cosa generano male i tool di UI;
2. trasformare un output generato in qualcosa di portabile nella tua codebase;
3. valutare un prototipo UI con criteri oggettivi (struttura, accessibilità, stato, performance).

Nucleo della lezione

1. Cosa generano bene

Punti di forza concreti:

• Layout iniziali: griglie, sidebar, header, footer, dashboard a card. Pattern visti migliaia di volte.
• Stati UI comuni: loading, errore, vuoto, success. Il tool propone già le tre varianti.
• Microcopy: testi placeholder credibili, etichette, helper text. Da raffinare ma da non scrivere da zero.
• Varianti estetiche: stesso layout in 3 stili (minimal, glassmorphism, brutalist). Utile per esplorare direzione.
• Componenti ripetitivi: card prodotto, riga tabella, item lista. Boilerplate che salva tempo.
• Responsive starter: breakpoint base, mobile-first o desktop-first impostati.

Per questi task il generatore è un acceleratore reale. Output da rifinire, non da accettare crudo, ma punto di partenza solido.

2. Rischi frequenti

Cose che devi sapere e correggere quasi sempre:

• Markup eccessivo: 8 div annidati per fare un bottone. Tool ottimizzano per look, non per semantica.
• Dipendenze pesanti: import di libreria UI completa (Material UI, Chakra) per usare 2 componenti. Bundle gonfiato.
• Stile incoerente: il prototipo usa Tailwind con classi inline, il tuo progetto usa CSS modules. Va portato.
• Accessibilità superficiale: aria-label assenti, contrasto insufficiente, focus state mancanti, tab order rotto. Spesso i tool dichiarano “accessibile” e non lo è.
• Logica mischiata alla presentazione: state management dentro componenti UI senza separazione. Difficile da testare, difficile da riusare.
• Hard-coded data: dati finti dentro il componente invece che ricevuti come prop. Refactor obbligato per uso reale.
• Versioni discordanti: tool usa React 18, tu hai React 17 con codice legacy. Hooks o API non compatibili.

3. Da prototipo a base di lavoro

Sequenza per portare un output generato nella tua codebase:

• Pulizia struttura: collassa div inutili, usa elementi semantici (<header>, <nav>, <main>, <button> invece di <div onClick>).
• Estrazione componenti: ciò che si ripete diventa componente. Ciò che è specifico resta in pagina.
• Design token: sostituisci colori hardcoded con variabili (CSS custom properties, theme di Tailwind, design system). Stesso per spacing, typography.
• Stato fuori, prop dentro: dati che vengono dall’esterno passati come props. Stato locale solo per UI temporanea.
• Accessibilità: aria attributes dove servono, focus management, contrasto verificato (strumenti come Lighthouse, axe DevTools).
• Stile coerente: rimuovi classi/utility incoerenti col resto del progetto. Allinea naming.
• Dipendenze ridotte: rimuovi librerie non essenziali. Se usi 2 componenti di una lib enorme, valuta di scrivere quei 2 a mano.

Ogni passaggio è un commit separato. Non un grande refactor monolitico.

Procedura pratica

Workflow per usare un generatore in modo produttivo:

1. Definisci scope: cosa genero, per dimostrare cosa, a chi.
2. Genera: prompt chiaro con riferimento visivo se possibile.
3. Valuta con checklist (sotto). Se più del 30% va riscritto, non vale la pena: rigenera con prompt migliore o scrivi a mano.
4. Importa nello sandbox: progetto isolato, non subito nella codebase reale.
5. Pulisci (sequenza sezione 3) un commit per volta.
6. Integra: solo dopo cleanup, porta in codebase reale.

Salto del passaggio 3 è errore principale: prototipi sporchi finiscono in produzione perché “tanto è solo per ora”.

Laboratorio guidato

Genera una schermata di dashboard (sidebar + header + 4 card metriche + tabella) con il tool che preferisci. Valuta con questa checklist:

Struttura:

• elementi semantici usati correttamente?
• gerarchia heading (h1, h2, h3) coerente?
• numero medio div annidati ragionevole (≤3 per blocco)?

Stato:

• loading state presente?
• empty state presente?
• error state presente?

Accessibilità:

• contrasto colori ≥ 4.5:1 per testo normale?
• focus state visibile su elementi interattivi?
• aria-label su icone-only buttons?
• form con label associate (<label for>)?

Responsive:

• mobile <640px funzionante?
• nessun overflow orizzontale?
• target tap ≥ 44x44px?

Performance:

• dipendenze pesanti aggiunte?
• immagini ottimizzate (formato, sizing)?

Conta i sì. Se <70%, l’output non è pronto: rigenera o riscrivi.

Output atteso

Un report di revisione UI strutturato per checklist sopra, con: voce → stato (sì/no/parziale) → azione richiesta. Documento di una pagina che diventa la lista di task per portare il prototipo in produzione.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: sfruttare i generatori visuali per esplorare prodotto e UI, mantenendo attenzione a codice, accessibilità e portabilità. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Cosa generano bene: layout iniziali, stati UI comuni, microcopy, varianti estetiche, componenti ripetitivi.
• Rischi frequenti: markup eccessivo, dipendenze pesanti, stile incoerente, accessibilità superficiale, logica mischiata alla presentazione.
• Come trasformare un prototipo in base di lavoro: pulizia, semantica, design token, componentizzazione.

3. Applicazione: svolgi il laboratorio: generare una schermata di dashboard e valutarla con una checklist di struttura, gerarchia, stati e accessibilità. L’output da ottenere è: un report di revisione UI con modifiche da fare prima di portare il prototipo in una codebase reale.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• ho generato almeno una schermata e l’ho valutata con checklist;
• ho identificato 3 rischi specifici del codice generato dai tool che uso;
• so quando un prototipo va buttato e quando vale la pena raffinarlo;
• ho un sandbox separato per generazioni UI, non mischiate alla codebase reale.

Errori comuni

Trattare il prototipo come finito. Funziona sul demo, allora va in produzione. Risultato: bundle gonfio, accessibilità rotta, debito tecnico immediato.

Importare l’intera libreria UI del tool nel proprio progetto. v0 genera in shadcn/ui, tu usi MUI. Importare entrambe = doppio peso e stili in conflitto. Scegli una.

Non testare con tastiera. Mouse-only è metà del lavoro. Tab attraverso la pagina, controlla focus order, attiva con Enter/Space.

Ignorare la performance. Generatori non ottimizzano: caricano tutto. Lighthouse score basso = utenti veri lo sentiranno.

Skippare lo step di pulizia. “Lo pulirò dopo” → non lo si pulisce mai. Pulizia deve essere parte del workflow, non opzionale.

Prompt di lavoro

Genera una [tipo schermata] per [contesto].

Vincoli tecnici:
- framework: [React/Vue/Svelte/HTML]
- stile: [Tailwind/CSS modules/CSS-in-JS] — solo questo
- componenti UI: [shadcn/ui / Radix / nessuna libreria pesante / lista esplicita]
- target accessibilità: WCAG AA, contrasto ≥ 4.5:1, focus visibile, aria dove necessario

Includi obbligatoriamente:
- empty state
- loading state
- error state
- responsive mobile (≥320px) e desktop

Evita:
- librerie UI non listate sopra
- classi inline non riutilizzabili
- div decorativi inutili (max 3 livelli annidati per blocco)
- testo lorem ipsum (usa microcopy plausibile in italiano)

Output: file unico, codice pronto da incollare in sandbox.

Esercizio finale

Prendi una schermata che hai realmente in produzione (o che hai disegnato a mano). Generala con un tool. Confronta: tempo per generare vs tempo per produrre la versione finale (cleanup incluso). Tempo totale è davvero più basso del costruire da zero? Per quale tipo di schermate il vantaggio è netto, per quali no? Quella distinzione diventa la tua regola personale.