Nell'era dell'AI il wireframe conta più di prima

Oggi possiamo descrivere un'idea ad un modello e ricevere, in pochi secondi, un'interfaccia completa: componenti, colori, animazioni e tutto il codice pronto all'uso in pochissimi prompt, sia FrontEnd che Backend. È una cosa straordinaria ma, allo stempo, porta con sè diversi problemi.

Quando produrre codice diventa così veloce ed economico, la tentazione è una sola: andare dritti al risultato: apriamo l'editor (o il prompt) e cominciamo a creare la nostra applicazione, prima ancora di aver capito cosa stiamo costruendo o quale sia il flusso migliore per renderla usabile e gradevole per gli utenti finali (non solo graficamente ma soprattutto a livello di user experience).

E proprio perché l'AI ha reso banale generare codice e UI, l'analisi del progetto e il wireframe low-fidelity sono diventati ancora più importanti.

Il paradosso della velocità#

C'è un costo nascosto nella velocità.

Generare la cosa sbagliata in fretta non ti fa risparmiare tempo: ti fa accelerare nella direzione sbagliata.

Prima dell'AI, costruire una schermata costava ore. Quel costo funzionava da freno naturale: prima di scrivere codice ti fermavi a ragionare (o almeno così si sarebbe dovuto fare 😅), perché rifare tutto era costoso e quindi doloroso. Oggi quel freno non c'è più. Posso generare cinque versioni di una dashboard nel tempo di un caffè, tutte bellissime e, allo stesso tempo, tutte potenzialmente inutili se non ho prima risposto alle domande che contano:

• Qual è il problema reale che sto risolvendo?
• Chi sono gli utenti e qual è il loro flusso di lavoro in base al ruolo?
• Quali sono i dati in gioco, da dove arrivano e come presentarli?
• Quali sono i casi limite, gli stati vuoti, gli errori?

Nessun modello risponde a queste domande al posto tuo. Può aiutarti a esplorarle, ma la regia resta tua.

Analisi prima di tutto#

"Analisi del progetto" suona come una parola da consulenza, ma è una cosa molto concreta: mettere su carta cosa deve fare il prodotto, prima di decidere come deve apparire.

Significa elencare le funzionalità, descrivere i flussi principali ("l'utente arriva qui, fa questo, succede quest'altro"), mappare le entità e le relazioni tra i dati, individuare gli stati dell'interfaccia. È un lavoro poco glamour e per questo lo saltiamo quasi sempre. Ma è esattamente il lavoro che ti evita di rifare tre volte la stessa schermata perché ti eri dimenticato dei filtri di ricerca, di uno step intermedio o di cosa succede quando l'utente non ha i permessi o ha un ruolo differente.

Perché low-fidelity (e non high-fidelity)#

Qui sta il punto più frainteso. Un wireframe non deve essere bello.
Deve essere veloce da cambiare e brutto abbastanza da non affezionarsi.

Il low-fidelity ha tre superpoteri:

1. Disaccoppia la struttura dall'estetica. Quando lavori con box grigi e testo segnaposto, sei costretto a ragionare su gerarchia, posizione e flusso. Non puoi nasconderti dietro un font bello o un'ombra ben fatta.

2. Sposta la conversazione sul punto giusto. Mostra un mockup high-fidelity a un cliente e ti chiederà di cambiare il blu. Mostragli un wireframe e ti parlerà del flusso. È un filtro che ti regala il feedback che serve davvero, nella fase in cui serve davvero.

3. Costa pochissimo buttarlo via. Il valore di un wireframe è proprio nel poterlo cestinare senza rimpianti. Più tempo investi nel renderlo perfetto, più diventi prigioniero della prima idea.

Il wireframe come strumento di accordo (e di preventivo)#

Un altro motivo per usare i wireframe risolve un problema, molto concreto, che chi lavora con i clienti conosce bene: il wireframe è il modo più rapido per mettersi d'accordo su cosa costruirai.

Un mockup low-fidelity è un linguaggio condiviso. Non richiede competenze tecniche, quindi cliente, PM e sviluppatore guardano lo stesso disegno e parlano della stessa cosa. È molto più difficile fraintendersi davanti a quattro box che davanti a un documento di requisiti scritto, dove ognuno immagina un'interfaccia diversa nella propria testa.

E qui arriva il vantaggio economico: una volta che schermate e flussi sono sul tavolo, puoi contarli. Quante viste, quanti stati, quante interazioni, quali integrazioni, e tradurre tutto questo in giornate, e quindi in un preventivo.

Senza wireframe, qualsiasi stima è un numero buttato lì; con il wireframe stai quotando qualcosa di visibile e verificabile, e puoi anche spiegare al cliente perché ha un determinato costo.

Infine, la parte che ti risparmia tante (ma tante) rotture di scatole e discussioni future: allega il wireframe al contratto. Questo processo ti permette di definire il perimetro del lavoro nero su bianco: quello che è disegnato è incluso, quello che non c'è è una change request, da concordare e ri-quotare. Non è una questione di sfiducia, è il contrario: gli accordi chiari proteggono il rapporto. Il giorno in cui arriva il classico "ma non c'era anche la dashboard con i grafici?", la risposta non è una discussione, è un disegno condiviso e firmato.

Wireframe nell'era dell'AI: il tuo prompt migliore#

C'è poi un motivo nuovo, che dieci anni fa non esisteva.

Oggi un mockup low-fidelity è anche il miglior input possibile per gli strumenti AI di generazione. Se passi a un modello una descrizione vaga, ottieni un risultato generico. Se gli passi un wireframe chiaro, con la struttura, i blocchi, i flussi già ragionati, l'output migliora drasticamente.

Il wireframe, in altre parole, è diventato la specifica. È il documento che traduce "voglio una cosa così" in qualcosa che un LLM (o un collega) può eseguire senza riempire i buchi a caso.

Garbage in, garbage out vale più che mai: la qualità di ciò che generi è limitata dalla chiarezza di ciò che chiedi.

Chi salta questa fase molto probabilmente consegnerà prima, ma accumula rework. Chi parte dal wireframe dà all'AI una direzione precisa, e arriva più lontano con meno tentativi.

Il punto d'incontro con lo spec-driven development#

Se questo discorso ti suona familiare, è perché stai descrivendo, dal lato interfaccia, esattamente la filosofia dello spec-driven development (SDD), l'approccio che nell'ultimo anno è diventato il modo "serio" di lavorare con gli agenti di coding.

L'idea di fondo dello SDD è che la specifica, non il codice, sia la fonte di verità: prima scrivi cosa deve fare il sistema, da lì derivi il piano, lo spezzi in task e solo alla fine generi il codice. Quando i requisiti cambiano, modifichi la spec e rigeneri. È nato nel 2025 come risposta diretta ed evoluzione del "vibe coding": agenti che producono codice plausibile ma che deriva dall'intento, inventano API e si degradano man mano che il progetto cresce. Ed è per questo che oggi molti big player e diversi sviluppatori stanno proponendo strategie e tool per lo SDD: da GitHub Spec Kit a AWS Kiro, da OpenSpec fino a Claude Code e Antigravity.

Il legame con il discorso di prima è diretto: il wireframe è la spec dell'interfaccia.

Pensaci. Una spec testuale descrive il comportamento del sistema: regole, vincoli, criteri di accettazione. Ma da sola è cieca sul layout e sul flusso. Un wireframe low-fidelity descrive l'altra metà: dove stanno le cose, come l'utente si muove tra le schermate, qual è la gerarchia delle informazioni.

Le due cose insieme formano un'immagine completa dell'intento, e senza la parte visiva, l'AI riempie i buchi sul layout in modo arbitrario.

In SDD si ripete spesso che "lo spec è il prompt". Io aggiungerei un corollario per chi lavora sul frontend: il mockup è la parte della spec che tutti sanno leggere. Una spec scritta la capisce uno sviluppatore; un wireframe lo capiscono anche il cliente, il PM e il designer. È il documento di intento più democratico che hai.

C'è anche uno spettro di "quanto" spec-driven vuoi essere: c'è chi tiene la spec come guida e mantiene il codice a mano (spec-first), chi la fa convivere col codice (spec-anchored), chi la considera l'unico artefatto e genera tutto il resto (spec-as-source).

Non devi scegliere il livello più estremo per trarne valore: anche solo formalizzare l'analisi e disegnare quattro wireframe è fare spec-driven development, nella sua forma più leggera e onesta.

Separare il cosa dal come ti dà più controllo sul risultato finale e l'AI lavora molto meglio dentro confini chiari che dentro un prompt vago.

Perché ho creato mokup.dev#

Tutto questo discorso, per me, era diventato un attrito quotidiano. Volevo creare wireframe velocemente, ma gli strumenti che avevo sottomano mi remavano contro:

• Figma è potentissimo, ma ti spinge naturalmente verso l'high-fidelity. Apri un file per fare quattro box e ti ritrovi mezz'ora dopo a scegliere i raggi di bordatura.

• Strumenti come Claude Design e Stitch hanno comunque tempi di generazione lunghi e costi che probabilmente aumenteranno sempre di più. E io non voglio vincolarmi! Inoltre sono più adatti a creare i layout definitivi e quindi rappresentano lo step successivo.

• Gli strumenti "da wireframe" classici sono spesso poco pratici da usare o non possiedono tutte le funzionalità necessarie per un flusso di lavoro efficiente. E anche se li possiedono ho deciso di crearmi un tool su misura, che posso estendere in base alle necessità e che sono certo sarà utile a molti: mokup.dev.

• La carta (o il tablet) è perfetta per pensare e buttar giu qualche idea, ma son difficili da mantenere o modificare (SPOILER: in mokup.dev ho inserito una funzionalità che ci permette di importare una bozza fatta a mano, o un disegno, e convertirlo in un mockup interattivo che puoi modificare facilmente ).

Volevo qualcosa che mi tenesse dentro la "modalità pensiero": veloce, low-fidelity per scelta progettuale, immediato da condividere e pensato per il flusso di lavoro moderno, dove il mockup non è il punto d'arrivo, ma il punto di partenza per costruire (anche con l'AI).

Da qui è nato mokup.dev: lo strumento che già oggi utilizzo quando devo iniziare a buttar giu un'idea o a pianificare le funzionalità di un progetto e ragionare sulla struttura, prima di aprire l'editor. Niente fronzoli, niente tentazione di lucidare i pixel: solo lo spazio per buttare giù l'idea, capire se regge, e poi passare al codice con le idee chiare.

In più è un'ottimo strumento per la formazione, per creare contenuti per siti web, libri e slides.

mokup.dev è attualmente in beta privata, in fase di test e sviluppo. Tuttavia è già ampiamente utilizzabile e totalmente gratuito.
Tutte le immagini di questo articolo sono state realizzate con Mokup.

In sintesi#

Il valore di un developer, oggi, si sta spostando. Scrivere codice è sempre più una commodity; decidere cosa costruire e come strutturarlo è la parte che l'AI non può rubarti. Può aiutarti, ovviamente, ma l'ultima decisione dovrebbe essere sempre la tua.

Quindi, la prossima volta che parte un progetto, resisti alla tentazione del layout perfetto e del codice generato al primo prompt. Fermati cinque minuti.

• Fai l'analisi.
• Disegna quattro box brutti.
• Capisci il flusso (anche discutendone con clienti e collaboratori)
• Butta via il lavoro e prova un'altra strada con un altro mockup

Tutto ad una velocità estrema.

Alla fine di questo processo l'applicazione sarà praticamente pronta. Dovrai solo mandarla in pasto all'AI per la fase finale o implementarla manualmente.