MarkupGenMarkupGen
DocsRisorseBlogCasi d'usoConfronta
AccediConverti gratis
  1. MarkupGen
  2. /Blog
  3. /Design responsive in Figma: layout Mobile e Desktop spiegati
Torna al blog

Pubblicato il 2026-08-15 · Di Il team MarkupGen

Design responsive in Figma: layout Mobile e Desktop spiegati

Design responsive in Figma: layout Mobile e Desktop spiegati

Un frame Figma che sembra corretto sia su un desktop da 1440px sia su uno smartphone da 375px non significa che il comportamento responsive nel mezzo sia già deciso — Figma ti mostra due istantanee fisse, mentre un browser ha bisogno di regole esplicite per gestire tutte le dimensioni di schermo reali che un visitatore può avere. Passare da "questi due frame sembrano corretti" a un layout che regge davvero significa leggere Auto Layout e le Constraints come segnali responsive, non solo come impostazioni visive, e sapere dove finisce il lavoro di Figma e dove deve subentrare il CSS. Ecco il modello mentale pratico, cosa verificare prima di iniziare a costruire, e dove si inserisce l'output responsive automatico di MarkupGen.

Un frame Figma è una specifica visiva, non CSS responsive

Figma renderizza un frame a una larghezza fissa. Niente, nel file, si "muove" al variare della dimensione dello schermo come farebbe un browser — quello che sembra design responsive in Figma è in realtà un insieme di regole (la direzione, il gap e le modalità di dimensionamento dell'Auto Layout; le Constraints di un layer) che descrivono un'intenzione, non una simulazione funzionante di un evento di ridimensionamento. Il CSS è il punto in cui quell'intenzione diventa reale: flex-direction, gap, le percentuali, clamp() e le regole @media sono ciò che risponde davvero alla larghezza del viewport. Considera il file Figma come la fonte di verità per l'intenzione, non come qualcosa che contiene già codice responsive finito.

I frame mobile e desktop descrivono un solo design, non due

È comune trovare, nello stesso file, un frame desktop e un frame mobile progettati a settimane di distanza l'uno dall'altro, che nel frattempo si sono discostati in modo silenzioso — livelli di intestazione diversi, varianti di componenti diverse, contenuti presenti in uno e assenti nell'altro senza un motivo chiaro. Conviene invece trattare i due frame come viste dello stesso modello di contenuto: le stesse intestazioni, gli stessi componenti (usando le varianti per gli stati, non duplicati creati ad hoc) e le stesse informazioni nello stesso ordine, a meno che non ci sia un motivo deliberato per riordinarle. Quando entrambi i frame condividono questa struttura di base, il lavoro sul CSS riguarda soprattutto il layout — trasformare una riga in una colonna, modificare il numero di colonne di una griglia, comprimere elementi UI secondari — invece di mantenere due template scollegati tra loro.

Auto Layout e Constraints: cosa si traduce davvero in comportamento responsive

La direzione, il gap, il padding e le modalità di dimensionamento (hug, fill, fixed) dell'Auto Layout corrispondono da vicino a Flexbox — vedi Da Auto Layout di Figma a CSS per la mappatura completa proprietà per proprietà. Per il comportamento responsive in particolare, la modalità di dimensionamento è il segnale più importante: un elemento "fill" ti sta dicendo che dovrebbe crescere o restringersi insieme al suo contenitore (flex: 1, width: 100%), mentre "fixed" ti dice che non dovrebbe farlo.

Le Constraints rispondono a una domanda diversa — come si comporta un elemento quando il suo genitore viene ridimensionato, un aspetto che conta soprattutto per tutto ciò che si trova al di fuori dell'Auto Layout:

  • Left / Right (Sinistra / Destra) — ancorato a un bordo, simile a un offset fisso che resta invariato mentre il genitore viene ridimensionato.
  • Left and Right (Sinistra e Destra) — si estende insieme al genitore, simile a width: 100% con margini laterali fissi.
  • Center (Centro) — resta centrato mentre il genitore viene ridimensionato, simile a margin: 0 auto o a un posizionamento centrato in flex/grid.
  • Scale (Scala) — si ridimensiona in proporzione al genitore; il CSS non ha un unico equivalente diretto, e di solito viene approssimato con unità relative.
  • Top / Bottom (Alto / Basso) (e combinazioni) — stessa logica applicata all'asse verticale.

Molti file reali usano entrambi insieme: l'Auto Layout per il modo in cui i figli di un contenitore si dispongono tra loro, le Constraints per il modo in cui quel contenitore si comporta all'interno di qualcosa di più grande di lui.

Breakpoint: dai frame Figma al CSS reale

Figma non ha una funzione nativa per i breakpoint — non esiste un'impostazione che dica "cambia layout sotto i 768px". Quello che un file offre davvero è o un frame distinto per ogni dimensione di schermo, oppure un unico frame Auto Layout che si ridimensiona in modo fluido senza alcun cambiamento strutturale. Capire con quale dei due si ha a che fare determina se il CSS ha bisogno di regole @media esplicite, e scegliere valori di breakpoint che corrispondano ai punti in cui il layout cambia davvero forma — non a larghezze arbitrarie di dispositivo — è la parte più importante del lavoro. Dai breakpoint di Figma alle media query CSS approfondisce entrambi i pattern e i punti in cui la traduzione manuale va tipicamente storta.

Trasformare le decisioni di Figma in CSS responsive

Una volta chiari i segnali sul lato Figma, il lato CSS si riduce a un insieme piuttosto ristretto di strumenti applicati in modo coerente:

  • Flexbox per la maggior parte dei frame Auto Layout — righe, colonne, barre di navigazione, elenchi di card.
  • Grid per layout davvero bidimensionali, come una dashboard o una galleria che l'Auto Layout sta simulando con righe e colonne annidate.
  • Media query dove la forma del layout cambia — una sidebar che diventa una bottom nav, una griglia che diventa una singola colonna.
  • Dimensionamento fluido (percentuali, minmax(), clamp()) per tutto ciò che sta tra le larghezze effettivamente specificate dal designer, invece di aggiungere breakpoint per colmare i vuoti.
  • max-width per evitare che testo e contenuti si allarghino in modo scomodo sugli schermi grandi, anche se il frame Figma stesso non ne mostra uno.
  • A capo e impilamento (flex-wrap, una riga che diventa una colonna) per i contenuti che dovrebbero riorganizzarsi invece di rimpicciolirsi.
  • Cambi di visibilità per tutto ciò che è genuinamente riservato a mobile o desktop — da gestire con attenzione, perché nascondere un elemento con display: none lo rimuove anche dall'albero di accessibilità. Vedi Da Figma a HTML accessibile se un contenuto nascosto deve restare comunque raggiungibile in un altro modo, come un menu mobile.

Errori comuni nel tradurre Figma in layout responsive

  • Trattare il mobile come un desktop rimpicciolito, invece che come un layout a sé stante con una propria gerarchia e priorità.
  • Fissare dimensioni in pixel ovunque il frame Figma mostri un numero specifico, invece di usare il dimensionamento fill/fixed e le Constraints per decidere cosa deve restare davvero fisso.
  • Ignorare l'andata a capo del testo — un titolo o un'etichetta di pulsante che sta su una riga nella lingua originale può andare su due o tre righe in una traduzione più lunga, e un layout che presuppone testo su una sola riga si rompe.
  • Affidarsi al posizionamento assoluto per riprodurre un design pixel per pixel, il che sembra corretto esattamente alla larghezza del frame ma si rompe a ogni larghezza intermedia.
  • Controllare solo le larghezze a cui sono stati disegnati i frame Figma — diciamo 375px e 1440px — saltando tutto ciò che sta nel mezzo, che è dove avviene la maggior parte delle rotture reali.

Checklist per il developer handoff

Prima di implementare il comportamento responsive a partire da un file Figma, conviene verificare alcune cose direttamente nel design invece di darle per scontate:

  • Quali frame esistono, e se mobile e desktop devono rappresentare lo stesso contenuto semplicemente riorganizzato, oppure esperienze davvero diverse.
  • Le impostazioni di Auto Layout su ogni frame — direzione, gap, padding e modalità di dimensionamento sugli elementi che devono ridimensionarsi.
  • Le Constraints su tutto ciò che si trova fuori dall'Auto Layout, in particolare gli elementi ancorati a un bordo o centrati.
  • Spaziatura e tipografia a ogni larghezza di frame — scalano, o restano fisse?
  • Le varianti dei componenti — un componente ha una variante mobile distinta, oppure è lo stesso componente che dovrebbe adattarsi?
  • Cosa cambia realmente tra i frame mobile e desktop, e se ogni differenza è intenzionale o è solo il risultato di file modificati in momenti diversi.

Come MarkupGen automatizza la base responsive

Ogni export parte dalle impostazioni di Auto Layout e dalle Constraints di ridimensionamento del frame stesso, non da un elenco generico di breakpoint — direzione, gap e padding vengono riportati esattamente, e il dimensionamento fill/hug si traduce in CSS fluido, così il risultato si adatta a diverse dimensioni di schermo senza media query scritte a mano per la maggior parte dei layout.

Per i design in cui il mobile ha davvero bisogno di una struttura diversa — una navigazione impilata invece che orizzontale, un hero riorganizzato, una sidebar nascosta — l'editor integrato può generare, per la pagina corrente, un layout Mobile o Desktop separato e costruito su misura a partire dall'HTML/CSS esistente, con una propria media query; lo rivedi prima di applicarlo, e da quel momento è la dimensione dello schermo del visitatore a decidere quale dei due viene mostrato. In entrambi i casi l'output privilegia l'HTML semantico rispetto a pile di <div> annidati, in Vanilla CSS, Tailwind, Bootstrap, Bulma, Materialize o Pico, con un punteggio di qualità IA automatico su ogni export. Niente di tutto questo sostituisce la checklist qui sopra — è un punto di partenza generato dai segnali reali del design, da rivedere con la stessa attenzione che dedicheresti a qualsiasi altra implementazione responsive prima di pubblicarla.

Se vuoi vedere come risponde il tuo file Figma su entrambe le dimensioni di schermo, prova il convertitore da Figma a HTML — oppure converti direttamente in React se è il tuo stack — gratis, senza carta di credito.

FAQ

Come dovrebbe gestire un design Figma i layout mobile e desktop? Trattali come un unico design espresso a due larghezze diverse — con gli stessi contenuti, le stesse intestazioni e gli stessi componenti — invece che come due file scollegati. Auto Layout e le Constraints descrivono come quella struttura condivisa dovrebbe adattarsi; le differenze strutturali vere e proprie, come una navigazione che collassa o un hero riorganizzato, vengono poi implementate con le media query CSS.

Auto Layout e Constraints di Figma rendono automaticamente responsive un design? No. Descrivono un'intenzione — come un elemento dovrebbe dimensionarsi o comportarsi quando il suo contenitore cambia — ma quell'intenzione va comunque tradotta in Flexbox, Grid, dimensionamento fluido o media query nel CSS effettivo. Né Figma né uno strumento di conversione generano da soli ogni decisione responsive.

Come scelgo i breakpoint CSS a partire da un design Figma? Figma non ha una funzione nativa per i breakpoint, quindi basali sui punti in cui la forma del layout cambia davvero, non su larghezze di dispositivo arbitrarie. Se un design usa frame separati per ogni dimensione di schermo, il layout di ciascun frame diventa in genere un blocco @media; se si basa sul ridimensionamento fluido dell'Auto Layout, spesso non serve alcun breakpoint.

Qual è la differenza tra Auto Layout e Constraints in Figma? L'Auto Layout controlla come sono disposti i figli di un frame — direzione, gap, padding, dimensionamento — ed è l'equivalente più vicino a display: flex. Le Constraints controllano come si comporta un elemento quando il suo genitore viene ridimensionato, ad esempio se resta ancorato a un bordo, centrato o scalato, un aspetto rilevante soprattutto per gli elementi fuori dall'Auto Layout o per come un frame Auto Layout si colloca dentro qualcosa di più grande.

Mobile e desktop dovrebbero essere file Figma separati? Non necessariamente, e tenerli nello stesso file con componenti condivisi rende di solito più facile individuare eventuali disallineamenti. Ciò che conta più della struttura dei file è se i due frame rappresentano lo stesso modello di contenuto — gli stessi componenti e la stessa gerarchia — con il layout, non il contenuto, come elemento che cambia tra i due.

Cosa dovrei verificare prima di implementare un design Figma in modo responsive? I frame esistenti, le impostazioni di Auto Layout e Constraints di ciascuno, come cambiano (o non cambiano) spaziatura e tipografia tra un frame e l'altro, se i componenti hanno varianti mobile distinte, e quali differenze tra i frame mobile e desktop sono intenzionali invece che semplice disallineamento accidentale.

Provalo con Figma to HTML

Letture correlate

Figma to HTML vs React vs Tailwind: quale scegliere?Blog

Figma to HTML vs React vs Tailwind: quale scegliere?

Una guida decisionale per le tre opzioni di output più richieste di MarkupGen — quando esportare Figma in HTML/CSS, quando esportarlo in React, e dove si colloca davvero Tailwind.

Leggi di più
Da Figma a codice: il supporto di MarkupGen per React, Vue e i framework CSSBlog

Da Figma a codice: il supporto di MarkupGen per React, Vue e i framework CSS

MarkupGen converte un design Figma in componenti React o Vue 3 (oltre a Svelte e Angular), oppure in HTML/CSS con Tailwind, Bootstrap e altro.

Leggi di più
Come valutare l'HTML generato dall'IA prima di pubblicarloBlog

Come valutare l'HTML generato dall'IA prima di pubblicarlo

Una checklist ripetibile per valutare l'output IA da Figma a codice oltre al 'sembra corretto' — fedeltà visiva, semantica, responsività, accessibilità e peso.

Leggi di più
L'output da Figma a HTML è pronto per la SEO? Cosa controllareBlog

L'output da Figma a HTML è pronto per la SEO? Cosa controllare

L'HTML convertito può sembrare identico al design e comunque danneggiare la SEO. Una checklist di ciò da verificare prima di pubblicare un export da Figma a codice.

Leggi di più
Da Figma a HTML accessibile: una guida praticaBlog

Da Figma a HTML accessibile: una guida pratica

Cosa richiede davvero l'accessibilità in un flusso di lavoro Figma-to-HTML — markup semantico, intestazioni, ARIA, form, contrasto e navigazione da tastiera.

Leggi di più
Da Figma a CSS: guida pratica alla conversioneBlog

Da Figma a CSS: guida pratica alla conversione

Elimina la dipendenza dai framework. Come i valori di Figma diventano CSS puro e modificabile a mano — e quando conviene rispetto a Tailwind o Bootstrap.

Leggi di più
Confronta

MarkupGen vs. TeleportHQ: convertitore vs. piattaforma low-code

TeleportHQ abbina l'esportazione Figma-to-code a un CMS integrato, moduli e hosting; MarkupGen resta focalizzato su output HTML/CSS/React pulito e autonomo.

Leggi di più
MarkupGen per startup e founderCasi d'uso

MarkupGen per startup e founder

Trasforma il tuo mockup Figma in un sito funzionante prima ancora di aver assunto il tuo primo front-end engineer.

Leggi di più

Trasforma il tuo prossimo design Figma in codice in pochi minuti

Inizia gratis ed esporta HTML, CSS o React puliti da qualsiasi file Figma.

Converti gratis
MarkupGenMarkupGen© 2025 MarkupGen. Tutti i diritti riservati.
BlogCasi d'usoConfrontaRisorse
Chi siamoDocumentazionePrivacyTerminiContatti