Un mockup è una rappresentazione abbastanza definita di un progetto da permettere di valutarne l’aspetto prima che il prodotto finale sia completato. Nel web design può essere una schermata ad alta fedeltà di un sito o di un’app; nella grafica può mostrare un logo su un’insegna, un packaging o un biglietto da visita; nella presentazione di un prodotto può simulare il risultato dentro uno smartphone, un laptop o una scena realistica.
Il termine viene però usato con significati diversi. Per orientarsi conviene partire dalla domanda che questa rappresentazione deve aiutarti a risolvere, invece di trattarla come una semplice “versione bella” di un wireframe.
In questa guida vediamo che cos’è un mockup, a cosa serve, come distinguerlo da wireframe e prototipo, come costruirne uno e quali strumenti scegliere in base al lavoro da fare.
Cos’è un mockup
Nel senso più generale, è un modello o una simulazione usata per mostrare come potrebbe apparire un risultato prima della sua realizzazione definitiva.
Nel digitale il termine indica spesso una rappresentazione visiva ad alta fedeltà: tipografia, colori, immagini, spaziature, componenti e gerarchie sono già abbastanza vicini alla direzione finale. Questo non significa che debba coincidere pixel per pixel con ciò che verrà sviluppato. Deve però essere abbastanza concreto da consentire una valutazione utile.
Il punto importante è distinguere rappresentazione e funzionamento. Una schermata può farti vedere come dovrebbe apparire un’interfaccia; non dimostra automaticamente come si comporterà nel browser, se sarà accessibile, se reggerà contenuti diversi o se il flusso sarà facile da usare.
Perché “mockup” può indicare cose diverse
Nel lavoro reale la stessa parola può descrivere almeno tre oggetti differenti.
Il primo è il mockup UI, cioè una schermata di sito o app con un livello di dettaglio visuale elevato. È quello che normalmente interessa quando si parla di web design, UI design e progettazione di interfacce.
Il secondo è il mockup grafico, usato per simulare l’applicazione di un progetto visuale su un supporto: un logo su una targa, una copertina su un libro, un’etichetta su una confezione.
Il terzo è il mockup di presentazione, in cui un design già esistente viene inserito in una scena o dentro il frame di un dispositivo per mostrarlo in modo più contestualizzato.
Queste tre accezioni possono sovrapporsi, ma non rispondono alla stessa domanda. Nel primo caso devi valutare soprattutto il design dell’interfaccia; nel secondo vuoi immaginare una resa su un supporto reale; nel terzo stai soprattutto cercando un modo efficace per comunicare il progetto.
Quando il contesto non è evidente, conviene quindi specificare: mockup UI, mockup sito web, mockup grafico, mockup di packaging o mockup di presentazione.
Cosa mostra e cosa non dimostra
Una rappresentazione ad alta fedeltà può mostrare molto bene:
- gerarchia visiva;
- tipografia;
- palette;
- immagini;
- spaziature;
- componenti;
- relazione tra contenuti;
- direzione estetica;
- possibili stati visuali.
Ma una schermata statica non dimostra, da sola:
- che la navigazione sia comprensibile;
- che i flussi funzionino;
- che l’interfaccia sia accessibile;
- che il responsive sia stato risolto;
- che il codice sia robusto;
- che il sito sia veloce;
- che i contenuti reali entrino senza rompere il layout;
- che gli utenti riescano a completare un’attività.
Questa distinzione evita un errore frequente: approvare un progetto perché “sembra finito” quando, in realtà, è stata validata soprattutto la sua resa visiva.
A cosa serve davvero un mockup
Serve quando riduce un’incertezza concreta. Se non sai quale decisione deve rendere più facile, rischia di trasformarsi in una tavola di presentazione molto curata ma poco utile.
Valutare l’aspetto prima dello sviluppo o della produzione
Nel web design permette di discutere la UI prima che ogni scelta venga trasformata in codice.
Puoi controllare se la gerarchia è chiara, se la tipografia funziona, se le immagini hanno il peso giusto, se le call to action emergono abbastanza e se il linguaggio visivo è coerente con il progetto.
Questo passaggio è diverso dalla progettazione del layout di un sito web. Il layout riguarda soprattutto disposizione e relazioni tra gli elementi; qui, invece, quella struttura viene resa visualmente più definita.
Lo stesso principio vale nella grafica. Prima di stampare un packaging o applicare un’identità su decine di supporti, una simulazione può far emergere problemi di proporzioni, contrasto e leggibilità che su una tavola neutra erano meno evidenti.
Allineare cliente, designer e sviluppatori
Molte incomprensioni nascono perché le persone stanno discutendo oggetti diversi.
Un cliente può interpretare un wireframe come una proposta grafica povera. Un designer può considerare una schermata “quasi finale”, mentre uno sviluppatore la legge come una semplice indicazione visiva. Una rappresentazione ben contestualizzata riduce parte di questa ambiguità, perché rende più esplicite le decisioni già prese e quelle ancora aperte.
Non elimina però la necessità di spiegare il progetto.
Se una schermata contiene un menu, un accordion, un form o un componente con più stati, conviene chiarire cosa è solo rappresentato e cosa è già stato definito a livello di comportamento. Più il progetto è complesso, meno una singola immagine può sostituire specifiche, componenti e prototipi.
Presentare un progetto senza confondere presentazione e test
Questo tipo di visual è anche un ottimo strumento di presentazione. Inserire un sito dentro un laptop o mostrare un logo su una targa aiuta chi guarda a immaginare il progetto fuori dal file di lavoro.
Il problema nasce quando l’effetto scenico sostituisce la verifica.
Una schermata dentro un dispositivo elegante può sembrare convincente anche se il testo è poco leggibile, la navigazione è confusa o il layout si rompe appena cambia la lunghezza dei contenuti. Per questo presentazione e validazione devono restare due funzioni distinte.
Può rendere un progetto più comprensibile; non deve renderlo artificialmente più credibile di quanto sia stato realmente verificato.
Tipi di mockup: sito web, grafica e prodotto
Non esiste un unico formato corretto. La scelta dipende da che cosa stai progettando e dal tipo di decisione che devi prendere.
Mockup di un sito web o di un’app
Con mockup sito web si indica normalmente una rappresentazione ad alta fedeltà di una o più pagine. Rispetto a una bozza strutturale, qui entrano in gioco il sistema visivo e i contenuti con un livello di realismo maggiore.
Una schermata web utile dovrebbe mostrare almeno le condizioni necessarie per giudicare davvero l’interfaccia. Una homepage perfetta a una sola larghezza non basta se il progetto dovrà funzionare su schermi diversi.
Per questo, quando è materiale, conviene rappresentare:
- desktop e mobile;
- titoli di lunghezza realistica;
- componenti con contenuti diversi;
- stati vuoti o di errore;
- hover, focus o varianti rilevanti;
- menu e navigazione;
- form;
- elementi ripetibili.
Nel lavoro del web designer questo artefatto diventa quindi più utile quando non è una schermata isolata, ma una rappresentazione coerente di regole che potranno sopravvivere all’implementazione.
Mockup grafico per logo, stampa e packaging
Un mockup grafico serve soprattutto a simulare l’applicazione di un progetto su un supporto.
Per un logo, ad esempio, può essere utile vedere il segno su un’insegna, un documento, un biglietto da visita o un packaging. Ma questa simulazione non dovrebbe essere il luogo in cui il logo viene giudicato per la prima volta.
Nella guida su come creare un logo il principio è lo stesso: prima vengono struttura, leggibilità e stress test; solo dopo ha senso osservare il marchio in contesti realistici.
Se un logo funziona soltanto su una fotografia con luce perfetta, texture premium e prospettiva costruita apposta, la presentazione sta nascondendo il problema invece di rivelarlo.
Mockup di presentazione su device e scene realistiche
Questo è il formato che incontri spesso nei portfolio, nelle presentazioni e nelle pagine prodotto.
Una schermata viene inserita dentro uno smartphone, un tablet o un computer; una grafica viene applicata a un oggetto; un packaging viene collocato in una scena fotografica.
È utile per raccontare il progetto e mostrare il contesto d’uso. È meno utile quando devi verificare dettagli di interfaccia, comportamento o accessibilità.
La regola pratica è semplice:
Più aumenta il realismo della scena, più devi controllare che il contesto non distragga dal problema che stai cercando di valutare.
Wireframe, mockup e prototipo: quali sono le differenze
Wireframe, mockup e prototipo vengono spesso descritti come tre gradini obbligatori dello stesso processo. È un modello utile per orientarsi, ma non è una legge.
La distinzione più solida non riguarda l’ordine, bensì che cosa ciascun artefatto permette di valutare.
| Artefatto | Cosa mette a fuoco | Fedeltà visiva tipica | Interazione | Domanda principale |
|---|---|---|---|---|
| Wireframe | struttura, contenuti, priorità, flussi | bassa o media | non necessaria | Dove stanno le cose e cosa deve esserci? |
| Mockup | resa visiva, gerarchie, UI, contenuti realistici | medio-alta o alta | normalmente non centrale | Come dovrebbe apparire? |
| Prototipo | comportamento, navigazione, stati, flussi | variabile | sì, quando serve | Cosa succede quando l’utente interagisce? |
La parola chiave è “tipica”. Un wireframe può essere dettagliato. Un prototipo può essere volutamente grezzo. Una schermata ad alta fedeltà può contenere più stati. La fedeltà non basta, da sola, a definire il ruolo dell’artefatto.
Il wireframe definisce soprattutto struttura e gerarchia
Il wireframe serve a discutere il progetto quando colori, fotografie e dettagli visuali rischierebbero di distrarre.
Ti costringe a concentrarti su domande come:
- quali contenuti devono esserci?
- in quale ordine?
- quali azioni sono prioritarie?
- come si sposta l’utente?
- quali blocchi appartengono alla stessa funzione?
Non è necessariamente una bozza “brutta”. È un modello deliberatamente semplificato, utile quando la struttura deve ancora cambiare velocemente.
Il mockup rende valutabile la direzione visiva
Quando struttura e contenuti sono abbastanza stabili, permette di passare dalla domanda “cosa deve esserci?” alla domanda “come deve apparire?”.
Qui entrano tipografia, palette, immagini, componenti e gerarchie visuali. È anche il momento in cui emergono problemi che nel wireframe non potevi vedere: un titolo troppo lungo per il trattamento tipografico scelto, un contrasto insufficiente, una card che dipende da fotografie tutte identiche, una CTA che perde peso.
Non dovrebbe quindi limitarsi ad abbellire il wireframe. Deve mettere alla prova la direzione visuale con condizioni abbastanza realistiche.
Il prototipo aggiunge comportamento e interazione
Il prototipo diventa utile quando la domanda non è più soltanto “come appare?”, ma “cosa succede se faccio questo?”.
Collegamenti tra schermate, menu, overlay, transizioni, form e percorsi possono essere simulati prima dello sviluppo. La fedeltà del prototipo dipende dal test: per verificare un flusso può bastare un prototipo semplice; per valutare microinterazioni o una presentazione avanzata può servire un livello maggiore.
Se il tuo obiettivo è osservare come le persone completano un task, una schermata statica non basta. Entri nel territorio della prototipazione e della user experience.
Quando non serve creare tutti e tre
Non ogni progetto richiede la sequenza completa wireframe → mockup → prototipo.
Una landing molto semplice, basata su un design system già consolidato, può passare rapidamente dalla struttura alla UI. Un nuovo prodotto con flussi complessi può richiedere diversi prototipi ancora prima di avere una grafica raffinata. Un progetto di branding può usare simulazioni di applicazione senza avere nulla a che fare con un wireframe.
La domanda da fare non è:
Quale fase devo completare adesso?
È:
Quale incertezza mi impedisce di prendere la prossima decisione?
Se devi capire la struttura, lavora sul wireframe. Se devi giudicare la resa visuale, costruisci il mockup. Se devi verificare comportamento e percorso, passa al prototipo.
Come creare un mockup partendo da ciò che devi validare
Un buon risultato non nasce dal software. Nasce da un criterio.
Prima di aprire Figma, Penpot, Canva o Photoshop, definisci che cosa dovrà permetterti di decidere.
1. Definisci la decisione che il mockup deve rendere possibile
Scrivi una domanda concreta.
Per esempio:
- questa gerarchia visuale rende chiara l’offerta?
- il nuovo logo regge su un supporto reale?
- la pagina prodotto mantiene leggibilità con contenuti realistici?
- la versione mobile conserva le priorità?
- il cliente deve approvare una direzione visuale o un comportamento?
Una domanda vaga come “vediamo come viene” produce facilmente una tavola piena di dettagli ma senza un criterio di valutazione.
Se invece sai che devi scegliere tra due gerarchie visuali, puoi costruire il materiale esattamente per quella decisione.
2. Parti da contenuti, struttura e vincoli realistici
La rappresentazione non dovrebbe vivere in condizioni artificialmente perfette.
Usa titoli plausibili, testi abbastanza vicini alla lunghezza reale, immagini con proporzioni realistiche e quantità di contenuto coerente con il prodotto.
Sul web considera anche i vincoli che il file grafico tende a nascondere:
- schermi più stretti;
- zoom;
- contenuti dinamici;
- nomi molto lunghi;
- prezzi;
- messaggi di errore;
- assenza di immagini;
- traduzioni;
- dati caricati dall’utente.
Una schermata che funziona solo con quattro parole di titolo e tre card identiche non ha ancora dimostrato di essere robusta.
3. Costruisci la resa visiva senza dimenticare stati e responsive
A questo punto puoi definire tipografia, colori, spaziature, immagini e componenti.
Per un progetto web, ragiona per sistema. Se un pulsante compare in più pagine, non dovrebbe diventare ogni volta un elemento diverso. Se una card può contenere quantità differenti di testo, il design deve prevederlo.
Anche il responsive va considerato prima dell’handoff.
Non significa disegnare ogni possibile larghezza. Significa verificare i cambi strutturali: quando due colonne diventano una, quando il menu cambia, cosa resta prioritario, come si comportano immagini e controlli.
La soluzione più utile non è quella che controlla ogni pixel. È quella che rende esplicite abbastanza regole da ridurre le ambiguità successive.
4. Raccogli il feedback giusto per questa fase
Il tipo di feedback deve essere coerente con ciò che stai mostrando.
Se presenti una schermata statica, ha senso chiedere:
- la gerarchia è chiara?
- il tono visivo è coerente?
- i contenuti principali emergono?
- questa direzione rappresenta correttamente il brand?
- i componenti sono comprensibili?
Ha meno senso chiedere se “il checkout è facile da usare” quando nessuno può ancora usarlo.
Quando il feedback riguarda flussi, comprensione di un task o interazione, prepara un prototipo e un test adeguato. Separare le domande rende anche le revisioni molto più gestibili: non stai chiedendo un’opinione generica sul design, ma una valutazione legata alla fase del progetto.
Quale strumento usare per creare un mockup
Non esiste un programma migliore in assoluto. Esistono strumenti più adatti a un tipo di lavoro e a un certo workflow.
Figma o Penpot per siti, app e interfacce
Per UI e web design ha senso usare strumenti costruiti attorno a frame, componenti, layout, varianti e prototipazione.
Figma è particolarmente utile quando la progettazione fa parte di un sistema più ampio: componenti riutilizzabili, responsive, collaborazione, prototipi e handoff. La stessa Figma mette a disposizione template per website mockup come punto di partenza per diversi scenari.
Penpot è un’alternativa orientata a design e prototipazione, con la possibilità di collegare schermate e costruire flussi interattivi.
La scelta non dovrebbe dipendere dalla presenza della parola “mockup” nel menu del software. Per un’interfaccia conta soprattutto poter gestire bene struttura, componenti, stati e passaggio verso il prototipo.
Canva e i generatori di mockup per la presentazione
Se il problema è mostrare rapidamente una grafica dentro un dispositivo, su un prodotto o in una scena, uno strumento di presentation mockup può essere più rapido di un editor UI.
Canva Mockups include scenari per siti web, dispositivi, stampa, abbigliamento e altri prodotti.
È il caso tipico in cui una ricerca come mockup online nasconde un intento diverso da “progettare l’interfaccia di un sito”: l’utente spesso ha già una grafica e vuole semplicemente contestualizzarla.
Questi generatori sono comodi per presentazioni, portfolio e materiali marketing. Non sostituiscono però il file sorgente del progetto né il lavoro necessario per verificare responsive, stati e comportamento.
Photoshop e PSD quando serve un compositing più realistico
Photoshop resta utile quando il risultato dipende da fotografia, prospettiva, texture, luci, ombre e compositing.
Molti file PSD usano gli Smart Objects di Photoshop per sostituire la grafica sorgente mantenendo trasformazioni ed effetti non distruttivi.
È una logica diversa dal progettare una UI.
Se devi creare un’interfaccia composta da decine di schermate e componenti, un editor orientato al product design è normalmente più adatto. Se devi inserire un’etichetta su una bottiglia fotografata con pieghe, riflessi e prospettiva, Photoshop può essere la scelta più sensata.
Lo strumento viene dopo il tipo di problema.
Come capire se un mockup è fatto bene
Un mockup efficace non si misura da quanto sembra costoso o fotorealistico. Si misura da quanto bene rende valutabile il progetto.
Non deve essere soltanto convincente a colpo d’occhio
Una schermata può impressionare nei primi tre secondi e fallire appena inizi a leggerla.
Controlla se la gerarchia continua a funzionare senza lasciarti guidare dall’effetto complessivo. Il titolo è davvero leggibile? Le CTA emergono? I contenuti secondari hanno il peso giusto? La pagina sembra coerente anche quando la osservi come sistema e non come poster?
Nel web design puoi fare un test semplice: sostituisci i contenuti perfetti con contenuti più scomodi. Allunga un titolo, rimuovi un’immagine, aggiungi una riga a una card. Se il progetto perde subito equilibrio, hai appena individuato un vincolo importante.
Contenuti, stati e vincoli devono essere plausibili
Il realismo utile non coincide con il fotorealismo.
Per un’interfaccia, contenuti realistici e stati credibili valgono spesso più di una scena spettacolare. Un ecommerce dovrebbe prevedere prezzi, disponibilità, nomi di prodotto differenti, messaggi e condizioni che possono davvero comparire.
Una dashboard dovrebbe considerare almeno la differenza tra dati presenti, dati assenti ed eventuali errori se questi stati sono importanti per il prodotto.
Il principio è evitare il happy path permanente: progettare soltanto la condizione ideale e lasciare allo sviluppo tutti i casi reali.
Deve restare coerente con ciò che verrà davvero realizzato
Una rappresentazione utile non promette caratteristiche che il prodotto non potrà mantenere.
Nel web questo significa tenere conto di contenuti dinamici, CMS, browser, responsive, performance, accessibilità e componenti reali. Non devi risolvere ogni dettaglio tecnico dentro il file di design, ma devi evitare una direzione che dipende da condizioni impossibili o troppo fragili.
L’handoff funziona meglio quando designer e sviluppatore condividono non solo la schermata, ma anche le regole: spaziature, componenti, varianti, priorità e comportamento atteso.
Il progetto visuale deve ridurre l’interpretazione, non spostarla semplicemente alla fase successiva.
Errori da evitare quando usi un mockup
Il problema più comune non è usare male il software. È chiedere a questo artefatto di risolvere un problema che appartiene a un’altra fase.
Curare il visual prima di aver risolto la struttura
Passare troppo presto all’alta fedeltà rende costose le modifiche.
Quando hai già scelto immagini, colori, icone e dettagli, eliminare una sezione o cambiare completamente la gerarchia sembra una perdita di lavoro. Questo crea un incentivo psicologico a difendere una struttura debole soltanto perché è già stata rifinita.
Se il problema è ancora “quali contenuti servono e in quale ordine?”, resta più a lungo sul wireframe o su una rappresentazione semplificata.
La fedeltà dovrebbe aumentare quando diminuisce l’incertezza strutturale.
Confondere un’immagine statica con un test di usabilità
Una schermata può mostrare un bottone nel posto giusto. Non può dimostrare che una persona sappia quale bottone usare per raggiungere un obiettivo.
Può mostrare un menu elegante. Non dimostra che la sua organizzazione sia comprensibile.
Può mostrare un checkout ordinato. Non dimostra che il flusso sia semplice da completare.
Quando la domanda riguarda comportamento, comprensione e task reali, servono interazione, osservazione e un metodo di test coerente.
Usare un mockup realistico come prova di qualcosa che non è stato ancora costruito
Più la rappresentazione è realistica, più può creare l’impressione che il prodotto esista già.
In una presentazione interna può essere innocuo. In una pagina commerciale, in un portfolio o in una comunicazione pubblica conviene invece distinguere chiaramente ciò che è illustrativo da ciò che è reale.
Non usare una schermata simulata per suggerire metriche, funzioni, risultati o stati che non sono stati verificati. Lo stesso vale per i mockup generati con strumenti di intelligenza artificiale: possono essere ottimi per spiegare una direzione, ma non diventano automaticamente prova dell’esistenza o del funzionamento di quell’interfaccia.
Un buon mockup rende visibile un’idea. La credibilità arriva dal modo in cui dichiari correttamente che cosa quella rappresentazione può dimostrare.
Conclusione
Il modo più utile di pensare a un mockup è questo: non è un risultato finale in miniatura, ma uno strumento per prendere una decisione prima del risultato finale.
Se devi capire struttura e priorità, lavora sul wireframe. Se devi valutare la resa visiva, il mockup è l’artefatto giusto. Se devi verificare comportamento e flussi, passa a un prototipo.
Questa distinzione evita anche di scegliere lo strumento troppo presto. Figma o Penpot hanno senso quando stai progettando un’interfaccia e vuoi conservarne struttura, componenti e stati. Canva e i generatori online sono più rapidi quando devi presentare una grafica in un contesto. Photoshop diventa utile quando la simulazione richiede compositing e realismo fotografico.
La qualità, quindi, non dipende da quanto il risultato è spettacolare. Dipende da una domanda più concreta: ti permette di vedere il problema che devi risolvere, oppure lo rende soltanto più bello da guardare?