Wireframe, mockup e prototipo sono tre artefatti diversi prodotti in sequenza durante il processo di design. Confonderli porta a revisioni costose e incomprensioni con il cliente o il team di sviluppo. Nei progetti che seguiamo, una delle domande più frequenti dei clienti è "posso vedere subito com'è il sito?" — la risposta giusta è no, perché prima di sapere com'è il sito bisogna sapere come funziona, e questo richiede wireframe e validazione di UX prima di toccare i colori.
Wireframe: la struttura senza lo stile
Il wireframe è un disegno in scala di grigi (o a matita) che mostra la struttura di una pagina: dove vanno l'header, le sezioni di contenuto, le CTA, la sidebar. Non ha colori, non ha font scelti, non ha immagini reali. È deliberatamente grezzo per forzare le conversazioni su struttura e flusso, non su estetica. Si crea in ore, non in giorni. In Figma usiamo componenti wireframe con placeholder per i testi e rettangoli grigi per le immagini. La deliberata mancanza di stile è un feature, non un bug: impedisce al cliente di concentrarsi sul colore del bottone quando il problema reale è che il flusso di checkout ha 7 passaggi invece di 3.
Esistono due livelli di fedeltà per i wireframe. Low-fidelity (lo-fi): schizzi a mano o digitali molto approssimativi, usati nelle prime iterazioni per esplorare velocemente. High-fidelity (hi-fi): wireframe digitali con contenuto rappresentativo, annotazioni precise e struttura finale, usati per la presentazione al cliente e come base per il design UI. Nella nostra pratica, partiamo sempre da lo-fi collaborativi in sessioni di workshop con il cliente (anche remote con FigJam), poi passiamo a hi-fi per la validazione formale.
Mockup: la UI ad alta fedeltà, statica
Il mockup applica il design system al wireframe: colori reali, tipografia definitiva, icone, spaziature precise. È una rappresentazione visiva pixel-perfect dell'interfaccia finale, ma statica — non è cliccabile. I mockup si usano per la review estetica con il cliente e come riferimento per gli sviluppatori. In Figma i mockup con Auto Layout e design token sono già "codice-ready": le misure in pixel corrispondono alle unità CSS. Il Dev Mode di Figma permette agli sviluppatori di ispezionare ogni elemento e copiare direttamente il codice CSS corrispondente.
Un mockup professionale include tutti gli stati dell'interfaccia: default, hover, focus, active, disabled, error, loading. Uno dei problemi più comuni nei progetti di sviluppo è ricevere mockup solo per lo stato "happy path" e non sapere cosa mostrare quando l'utente fa qualcosa di inaspettato. Nei nostri deliverable includiamo sempre una pagina dedicata agli stati di errore, ai casi edge, e ai componenti nei loro vari stati. Questo può sembrare un eccesso inizialmente, ma riduce drasticamente le domande del team di sviluppo durante l'implementazione.
Prototipo: l'esperienza interattiva
Il prototipo è un mockup reso cliccabile con connessioni tra le schermate. Permette di simulare flussi reali (es. aggiungere un prodotto al carrello, completare un form) e di fare test utente senza scrivere una riga di codice. Strumenti come Figma Prototype, Framer, o ProtoPie consentono transizioni animate, microinterazioni e scroll behavior realistici. Framer in particolare permette di aggiungere logica condizionale, rendering di dati live e componenti React nativi. Il valore principale del prototipo è questo: permette di scoprire i problemi di usabilità quando costa poco correggerli (in Figma), non quando costa molto (in produzione).
I dati della ricerca UX mostrano che il 60% dei problemi critici di usabilità emerge già con 5 utenti testati su un prototipo. Questo significa che con mezza giornata di test (5 sessioni da 45 minuti) si possono identificare la maggior parte dei problemi prima di iniziare lo sviluppo. Il costo di trovare e correggere un problema in fase di prototipo è circa 10 volte inferiore al costo di correggerlo in produzione. È il calcolo che giustifica l'investimento in questa fase anche per progetti non grandi.
In quale ordine si usano
- 1. Wireframe → valida struttura e flusso con stakeholder
- 2. Mockup → valida estetica e design system con il cliente
- 3. Prototipo → valida UX e flussi critici con utenti reali o stakeholder tecnici
- Solo dopo: sviluppo — con mockup Figma consegnato al dev team
Strumenti specifici per ogni fase
- Wireframe lo-fi: FigJam (collaborativo), Whimsical, carta e penna (velocissimo)
- Wireframe hi-fi: Figma con wireframe kit o componenti grigi custom
- Mockup: Figma con design system e token — standard del settore nel 2026
- Prototipo semplice: Figma Prototype con transizioni e overlay
- Prototipo avanzato: Framer (componenti React reali), ProtoPie (logica condizionale), Principle (animazioni timeline)
- Test utente remoto: Maze, Useberry, o Lookback integrati con prototipi Figma
Come comunicare queste fasi al cliente
La sfida con i clienti che non hanno esperienza di design è gestire le aspettative in ogni fase. Il wireframe grezzo può disorientare chi si aspetta di vedere subito il sito. La comunicazione corretta: "Questo wireframe mostra dove vanno le informazioni, non come appaiono. Lo stile sarà nella fase successiva. Se approviamo questa struttura, possiamo andare avanti con il design visivo." Rendere esplicite queste fasi nel contratto e nel piano di progetto evita incomprensioni e revisioni fuori perimetro.
Nel nostro processo di realizzazione siti web ogni fase ha un'approvazione formale scritta (via commento su Figma o email) prima di procedere alla successiva. Questo protegge sia il cliente — che ha voce in ogni fase — sia l'agenzia — che non riceve revisioni retroattive su fasi già approvate. Se stai valutando un nuovo sito o restyling, visita la nostra pagina contatti per discutere quale livello di fedeltà è necessario per il tuo progetto specifico.
Risparmia tempo e budget con il giusto livello di fedeltà
Non tutti i progetti richiedono tutti e tre gli step. Un sito istituzionale di 6 pagine può saltare il prototipo se wireframe e mockup sono stati validati con cura. Un e-commerce o una web app con flussi complessi richiede obbligatoriamente il prototipo per ridurre il rischio di sviluppo. La regola pratica che applichiamo: se un flusso ha più di 3 schermate collegate con logica condizionale, va prototipato. Il costo del prototipo si ripaga sempre nella riduzione delle iterazioni di sviluppo.
