Diseño responsive en Figma: Mobile y Desktop explicados

Que un frame de Figma se vea bien tanto en un desktop de 1440px como en un móvil de 375px no significa que el comportamiento responsive entre ambos ya esté decidido — Figma te muestra dos capturas fijas, y un navegador necesita reglas explícitas para cubrir todo lo que el tamaño de pantalla de un visitante real puede llegar a ser. Pasar de "estos dos frames se ven bien" a un layout que realmente se sostiene implica leer Auto Layout y las constraints como señal responsive, no solo como ajustes visuales, y saber dónde termina el trabajo de Figma y dónde tiene que entrar el CSS. Aquí va el modelo mental práctico, qué revisar antes de construir, y en qué punto encaja la salida responsive automática de MarkupGen.

Un frame de Figma es una especificación visual, no CSS responsive

Figma renderiza un frame a un ancho fijo. Nada en el archivo "se reproduce" a través de distintos tamaños de pantalla como sí lo hace un navegador — lo que parece diseño responsive en Figma es en realidad un conjunto de reglas (la dirección, el gap y los modos de tamaño de Auto Layout; las constraints de una capa) que describen una intención, no una simulación funcional de un evento de redimensionado. El CSS es donde esa intención se hace real: flex-direction, gap, porcentajes, clamp() y las reglas @media son lo que realmente responde al ancho del viewport. Trata el archivo de Figma como la fuente de verdad de la intención, no como algo que ya contiene CSS responsive terminado.

Los frames Mobile y Desktop describen un solo diseño, no dos

Es habitual encontrar un frame de desktop y un frame de mobile en el mismo archivo que se diseñaron con semanas de diferencia y fueron divergiendo poco a poco — distintos niveles de encabezado, distintas variantes de componente, contenido que existe en uno y no en el otro sin ninguna razón clara. En vez de eso, trata los dos frames como vistas del mismo modelo de contenido: los mismos encabezados, los mismos componentes (usando variantes para los estados, no duplicados sueltos) y la misma información en el mismo orden, salvo que haya una razón deliberada para reordenarla. Cuando ambos frames comparten esa estructura subyacente, la continuación en CSS es sobre todo cuestión de layout — convertir una fila en columna, ajustar el número de columnas de una grid, colapsar UI secundaria — en lugar de mantener dos plantillas desconectadas entre sí.

Auto Layout y constraints: qué se traslada realmente al comportamiento responsive

La dirección, el gap, el padding y los modos de tamaño (hug, fill, fixed) de Auto Layout se corresponden estrechamente con Flexbox — consulta Auto Layout de Figma a CSS para ver el mapeo completo propiedad por propiedad. Para el comportamiento responsive en concreto, el modo de tamaño es la señal más importante: un elemento "fill" te está diciendo que debería crecer o encogerse junto con su contenedor (flex: 1, width: 100%), mientras que "fixed" te dice que no debería hacerlo.

Las constraints responden a una pregunta distinta — cómo se comporta un elemento cuando su padre cambia de tamaño, algo que importa sobre todo para lo que está fuera de Auto Layout:

• Left / Right — anclado a un borde, cerca de un offset fijo que se mantiene en su sitio mientras el padre se redimensiona.
• Left and Right — se estira junto con el padre, cerca de width: 100% con márgenes laterales fijos.
• Center — se mantiene centrado mientras el padre se redimensiona, similar a margin: 0 auto o a una posición flex/grid centrada.
• Scale — se redimensiona de forma proporcional junto con el padre; el CSS no tiene un único equivalente directo, y esto suele aproximarse con unidades relativas.
• Top / Bottom (y sus combinaciones) — la misma lógica aplicada al eje vertical.

Muchos archivos reales usan ambos a la vez: Auto Layout para cómo se organizan los hijos de un contenedor, constraints para cómo se comporta ese contenedor dentro de algo más grande que él mismo.

Breakpoints: de los frames de Figma al CSS real

Figma no tiene ninguna función nativa de breakpoints — no existe un ajuste que diga "cambia el layout por debajo de 768px." Lo que un archivo realmente te da es, o bien frames distintos por tamaño de pantalla, o un único frame con Auto Layout que se redimensiona de forma fluida sin ningún cambio estructural. Cuál de los dos tengas delante decide si el CSS necesita reglas @media explícitas, y elegir valores de breakpoint que coincidan con los anchos donde el layout realmente cambia de forma —no anchos de dispositivo arbitrarios— es la mayor parte del trabajo. Breakpoints de Figma a media queries de CSS cubre ambos patrones en detalle y dónde suele fallar la traducción manual.

Cómo convertir las decisiones de Figma en CSS responsive

Una vez que las señales del lado de Figma están claras, el lado del CSS es un conjunto bastante pequeño de herramientas aplicadas de forma consistente:

• Flexbox para la mayoría de los frames con Auto Layout — filas, columnas, barras de navegación, listas de tarjetas.
• Grid para layouts genuinamente bidimensionales, como un dashboard o una galería que Auto Layout está simulando con filas y columnas anidadas.
• Media queries donde la forma del layout cambia — una barra lateral que se convierte en una navegación inferior, una grid que se convierte en una sola columna.
• Tamaño fluido (porcentajes, minmax(), clamp()) para todo lo que hay entre los anchos que el diseñador realmente especificó, en vez de añadir breakpoints para rellenar los huecos.
• max-width para evitar que el texto y el contenido se estiren de forma incómoda en pantallas grandes, incluso si el propio frame de Figma no muestra ese límite.
• Wrapping y apilado (flex-wrap, una fila que se convierte en columna) para contenido que debería reflowarse en vez de encogerse.
• Cambios de visibilidad para todo lo que sea genuinamente exclusivo de mobile o de desktop — conviene hacerlo con cuidado, ya que ocultar un elemento con display: none también lo elimina del árbol de accesibilidad. Consulta Figma a HTML accesible si el contenido oculto necesita seguir siendo alcanzable de otra forma, como un menú mobile.

Errores comunes al traducir Figma a layouts responsive

• Tratar mobile como un desktop reducido a escala, en vez de como su propio layout con su propia jerarquía y prioridades.
• Fijar dimensiones en píxeles a mano en cada valor concreto que muestra el frame de Figma, en lugar de usar el tamaño fill/fixed y las constraints para decidir qué debería quedarse realmente fijo.
• Ignorar el ajuste de texto — un encabezado o una etiqueta de botón que cabe en una línea en el idioma original puede ocupar dos o tres en una traducción más larga, y un layout que asume texto de una sola línea se rompe.
• Apoyarse en posicionamiento absoluto para igualar un diseño píxel a píxel, lo que se ve bien exactamente en el ancho del frame y se rompe en cualquier ancho intermedio.
• Comprobar solo los anchos en los que se dibujaron los frames de Figma —digamos, 375px y 1440px— y saltarse todo lo que hay en medio, que es donde ocurre la mayoría de las roturas reales.

Checklist de entrega para developers

Antes de implementar el comportamiento responsive a partir de un archivo de Figma, vale la pena comprobar algunas cosas directamente en el diseño en lugar de darlas por sentadas:

• Qué frames existen, y si mobile y desktop están pensados como el mismo contenido reestructurado, o como experiencias genuinamente distintas.
• Los ajustes de Auto Layout en cada frame — dirección, gap, padding y modo de tamaño en los elementos que necesitan redimensionarse.
• Las constraints en todo lo que esté fuera de Auto Layout, sobre todo elementos anclados a un borde o centrados.
• El espaciado y la tipografía en cada ancho de frame — ¿escalan, o se mantienen fijos?
• Las variantes de componente — ¿tiene el componente una variante mobile distinta, o se espera que el mismo componente se adapte?
• Qué es lo que realmente cambia entre los frames de mobile y desktop, y si cada diferencia es intencional o simple deriva entre archivos editados en momentos distintos.

Cómo MarkupGen automatiza la base responsive

Cada exportación parte de los propios ajustes de Auto Layout del frame y de sus constraints de redimensionado, no de una lista de breakpoints genérica — la dirección, el gap y el padding se trasladan de forma exacta, y el tamaño fill/hug se traduce en CSS fluido, de modo que el resultado se adapta a distintos tamaños de pantalla sin media queries escritas a mano para la mayoría de los layouts.

Para diseños donde mobile realmente necesita una estructura distinta —una navegación apilada en vez de horizontal, un hero reordenado, una barra lateral oculta—, el editor integrado puede generar un layout Mobile o Desktop independiente y específico para la página actual a partir del HTML/CSS existente, con su propia media query; lo revisas antes de aplicarlo, y a partir de ahí el tamaño de pantalla del visitante decide cuál se renderiza. En ambos casos, la salida prioriza HTML semántico frente a <div> anidados, en Vanilla CSS, Tailwind, Bootstrap, Bulma, Materialize o Pico, con una puntuación de calidad de IA automática en cada exportación. Nada de esto sustituye el checklist anterior — es un punto de partida generado a partir de las señales reales del diseño, que vale la pena revisar igual que revisarías cualquier otra implementación responsive antes de publicar.

Si quieres ver cómo responde tu propio archivo de Figma en ambos tamaños de pantalla, prueba el conversor de Figma a HTML — o convierte directo a React si ese es tu stack — gratis, sin tarjeta de crédito.

Preguntas frecuentes

¿Cómo debería un diseño de Figma manejar los layouts mobile y desktop? Trátalos como un solo diseño expresado en dos anchos —el mismo contenido, los mismos encabezados y componentes— en lugar de como dos archivos sin relación. Auto Layout y las constraints describen cómo debería adaptarse esa estructura compartida; las diferencias estructurales genuinas, como una navegación colapsada o un hero reordenado, se implementan luego con media queries de CSS.

¿Auto Layout y las constraints de Figma hacen que un diseño sea responsive automáticamente? No. Describen una intención —cómo debería dimensionarse o comportarse un elemento cuando cambia su contenedor— pero esa intención igual tiene que traducirse en Flexbox, Grid, tamaño fluido o media queries dentro del CSS real. Ni Figma ni una herramienta de conversión generan por sí solas cada decisión responsive.

¿Cómo elijo los breakpoints de CSS a partir de un diseño de Figma? Figma no tiene ninguna función nativa de breakpoints, así que basa los breakpoints en los anchos donde la forma del layout realmente cambia, no en anchos de dispositivo arbitrarios. Si un diseño usa frames separados por tamaño de pantalla, el layout de cada frame suele convertirse en un bloque @media; si se apoya en el redimensionado fluido de Auto Layout, muchas veces no necesita ningún breakpoint.

¿Cuál es la diferencia entre Auto Layout y las constraints en Figma? Auto Layout controla cómo se organizan los hijos de un frame —dirección, gap, padding, tamaño— y es lo más parecido a display: flex. Las constraints controlan cómo se comporta un elemento cuando su padre cambia de tamaño, como estar anclado a un borde, centrado o escalado, algo que importa sobre todo en elementos fuera de Auto Layout o en cómo se ubica un frame con Auto Layout dentro de algo más grande.

¿Deberían mobile y desktop estar en archivos de Figma separados? No necesariamente, y mantenerlos en el mismo archivo con componentes compartidos suele facilitar detectar la deriva entre ambos. Lo que importa más que la estructura de archivos es si los dos frames representan el mismo modelo de contenido —los mismos componentes y la misma jerarquía— siendo el layout, y no el contenido, lo que cambia entre ellos.

¿Qué debería comprobar antes de implementar un diseño de Figma de forma responsive? Qué frames existen, los ajustes de Auto Layout y constraints de cada uno, cómo cambian (o no) el espaciado y la tipografía entre ellos, si los componentes tienen variantes mobile distintas, y cuáles de las diferencias entre los frames de mobile y desktop son intencionales y cuáles son simple deriva accidental.