Una aplicación puede verse perfecta en el ordenador utilizado durante el desarrollo y, aun así, presentar numerosos problemas cuando se abre desde un teléfono móvil, una tablet o una ventana de navegador más estrecha. Botones ocultos, textos cortados, columnas comprimidas o menús imposibles de cerrar son solo algunos de los errores que pueden aparecer.

Por este motivo, el testing responsive debe formar parte del proceso habitual de desarrollo. No debería reducirse a abrir las herramientas del navegador al final del proyecto y comprobar rápidamente dos o tres dispositivos preconfigurados.

Las pruebas responsive sirven para verificar que una interfaz se adapta correctamente a diferentes anchuras, alturas, orientaciones, navegadores y formas de interacción. El objetivo no es que la aplicación se vea exactamente igual en todas las pantallas, sino que mantenga su legibilidad, su jerarquía visual y sus funciones principales.

En este artículo veremos cómo revisar una app en distintos tamaños de pantalla, qué componentes requieren más atención, qué herramientas se pueden utilizar y cómo incorporar el testing responsive a un flujo de trabajo frontend.

Qué es el testing responsive

El testing responsive es el proceso de comprobar que una web o aplicación funciona correctamente en diferentes condiciones de visualización.

Aunque suele asociarse con la adaptación de una página a dispositivos móviles, una estrategia completa debe considerar muchos más factores:

• Anchura y altura del viewport.
• Orientación vertical y horizontal.
• Densidad de píxeles.
• Navegador y sistema operativo.
• Interacción mediante ratón, teclado o pantalla táctil.
• Zoom del navegador.
• Tamaño de fuente configurado por la persona usuaria.
• Aparición del teclado virtual.
• Barras dinámicas de navegación en dispositivos móviles.
• Contenido variable o cargado de forma asíncrona.

Por tanto, reducir manualmente la ventana del navegador puede servir como primera comprobación, pero no reproduce todas las situaciones que pueden darse en un dispositivo real.

Una buena estrategia de pruebas debe confirmar que la aplicación conserva cuatro características esenciales:

1. El contenido continúa siendo legible.
2. Las acciones importantes permanecen disponibles.
3. La estructura mantiene una jerarquía comprensible.
4. Los elementos interactivos pueden utilizarse con comodidad.

Cuando alguna de estas condiciones falla, el problema deja de ser únicamente visual. Un botón oculto detrás de una barra fija, por ejemplo, puede impedir completar una compra, enviar un formulario o guardar una configuración.

Diseño responsive no significa simplemente “versión móvil”

Un diseño responsive no debería entenderse como una versión de escritorio reducida hasta encajar en un teléfono. Cada tamaño de pantalla puede necesitar una distribución diferente.

Una cuadrícula de cuatro columnas puede convertirse en dos columnas en una tablet y en una sola columna en un móvil. Una navegación horizontal puede transformarse en un menú desplegable. Una tabla extensa puede necesitar desplazamiento propio o una representación alternativa mediante tarjetas.

La interfaz cambia, pero la tarea que la persona necesita completar debe seguir siendo posible.

Además, no todas las personas que utilizan un monitor grande navegan con el navegador maximizado. Pueden trabajar con dos ventanas colocadas en paralelo, abrir las herramientas de desarrollo o aumentar el zoom. Las pruebas responsive deben contemplar este rango continuo de situaciones y no únicamente una lista cerrada de dispositivos.

Qué tamaños de pantalla conviene probar

No resulta viable revisar manualmente todos los teléfonos, tablets y ordenadores existentes. Lo más eficaz es combinar tamaños representativos con pruebas específicas alrededor de los puntos de ruptura del diseño.

Crear una matriz básica de viewports

Como punto de partida, la matriz de pruebas puede incluir los siguientes escenarios:

• Móvil estrecho.
• Móvil de tamaño medio.
• Móvil de gran formato.
• Tablet en orientación vertical.
• Tablet en orientación horizontal.
• Portátil.
• Escritorio.
• Pantalla amplia.

No es necesario elegir únicamente las medidas de modelos comerciales concretos. El objetivo consiste en cubrir diferentes tipos de distribución y detectar cuándo el contenido deja de funcionar correctamente.

Una matriz sencilla podría utilizar estas medidas orientativas:

Escenario	Anchura	Altura
Móvil estrecho	320 px	568 px
Móvil estándar	375 px	667 px
Móvil ancho	430 px	932 px
Tablet vertical	768 px	1024 px
Tablet horizontal	1024 px	768 px
Portátil	1366 px	768 px
Escritorio	1440 px	900 px
Pantalla amplia	1920 px	1080 px

Estas medidas no representan una lista definitiva. Funcionan como puntos de referencia para empezar a revisar la interfaz.

Probar antes y después de cada breakpoint

Los errores responsive suelen aparecer en los tamaños intermedios, especialmente alrededor de las media queries.

Si la interfaz cambia su distribución a los 768 píxeles, conviene probar al menos:

• 767 píxeles.
• 768 píxeles.
• 769 píxeles.

Esta comprobación permite detectar reglas que se pisan, elementos que desaparecen durante un píxel, saltos inesperados o componentes que conservan estilos de la distribución anterior.

También resulta útil arrastrar lentamente el lateral de la ventana. Esta prueba sencilla muestra cómo responde la interfaz de forma continua y ayuda a localizar el punto exacto en el que un bloque empieza a comprimirse o desbordarse.

Elegir breakpoints según el contenido

Los breakpoints no deberían establecerse únicamente porque coinciden con las anchuras habituales de determinados dispositivos.

Una estrategia más resistente consiste en observar el contenido. Cuando una navegación deja de caber, una cuadrícula comprime demasiado sus tarjetas o un formulario pierde legibilidad, se ha encontrado un punto en el que la composición necesita cambiar.

Este criterio evita diseñar para una lista de dispositivos que puede quedar desactualizada y permite construir interfaces más flexibles.

Qué revisar durante las pruebas responsive

Una revisión sin criterios definidos puede centrarse demasiado en el aspecto general y dejar pasar problemas funcionales. Conviene probar la aplicación por componentes y estados.

Estructura y distribución del contenido

El primer paso consiste en comprobar cómo se reorganizan los bloques principales.

Se debe revisar si:

• Las columnas se apilan en un orden lógico.
• Las tarjetas mantienen una anchura legible.
• Los elementos no se superponen.
• Las barras laterales cambian de posición correctamente.
• Las cuadrículas reducen sus columnas sin comprimir el contenido.
• Los márgenes y espacios siguen siendo coherentes.
• No aparecen zonas vacías excesivas.
• El contenido principal no se extiende demasiado en pantallas grandes.

Una cuadrícula con un número fijo de columnas puede funcionar correctamente en escritorio y romperse en una tablet. En muchos casos, CSS Grid permite crear una solución más flexible:

.cards-grid {
  display: grid;
  grid-template-columns: repeat(
    auto-fit,
    minmax(min(100%, 18rem), 1fr)
  );
  gap: 1.5rem;
}

Esta configuración permite que el navegador determine cuántas columnas caben sin reducir cada tarjeta por debajo de un tamaño razonable.

Textos y contenido de longitud variable

Los diseños suelen probarse inicialmente con textos de una longitud muy controlada. Sin embargo, el contenido real puede incluir títulos extensos, nombres largos, mensajes de validación o traducciones que ocupen más espacio.

Durante las pruebas responsive conviene utilizar:

• Títulos de una sola palabra.
• Títulos de varias líneas.
• Nombres y apellidos largos.
• Direcciones de correo electrónico.
• URLs.
• Cifras grandes.
• Párrafos extensos.
• Mensajes de error.
• Estados vacíos.
• Contenido traducido.

La finalidad es descubrir si el diseño depende de una cantidad concreta de caracteres.

Cuando una palabra extensa supera el ancho del contenedor, puede aplicarse una regla controlada:

.content {
  overflow-wrap: anywhere;
}

No obstante, el texto no debería recortarse por defecto. Propiedades como text-overflow: ellipsis o line-clamp pueden ser adecuadas en una tarjeta secundaria, pero no cuando ocultan información necesaria para completar una tarea.

Imágenes, vídeos y otros recursos multimedia

Las imágenes son una de las causas más frecuentes de desbordamiento horizontal.

Una regla básica puede evitar que superen la anchura de su contenedor:

img,
video {
  max-width: 100%;
  height: auto;
}

Aun así, durante las pruebas también debe comprobarse:

• La relación de aspecto.
• El recorte mediante object-fit.
• Las imágenes de fondo.
• Las miniaturas de las tarjetas.
• Los vídeos incrustados.
• Los mapas.
• Los gráficos.
• Los carruseles.
• Las ilustraciones SVG.

Una imagen puede caber correctamente y, sin embargo, ocupar demasiada altura en móvil o perder parte de la información importante al recortarse.

Si la interfaz todavía se encuentra en fase de diseño, también puede resultar útil validar estos comportamientos antes de comenzar el desarrollo mediante prototipos interactivos en Figma. Probar diferentes distribuciones con antelación ayuda a detectar decisiones que podrían resultar difíciles de mantener posteriormente.

Navegación y menús

La navegación suele experimentar uno de los cambios más importantes entre escritorio y móvil.

Una barra horizontal puede convertirse en un botón que abre un menú desplegable, un panel lateral o una capa que ocupa toda la pantalla. Durante las pruebas se debe comprobar que:

• El botón de apertura es visible.
• El menú puede abrirse y cerrarse.
• Las opciones mantienen un orden comprensible.
• El contenido no queda oculto detrás del panel.
• El desplazamiento de fondo se bloquea únicamente cuando corresponde.
• El menú se cierra después de seleccionar una opción, si el flujo lo requiere.
• El foco del teclado se gestiona adecuadamente.
• La tecla Escape permite cerrar el panel cuando resulta apropiado.

También conviene cambiar el tamaño del viewport con el menú abierto. Puede ocurrir que la versión móvil bloquee el scroll del documento y que ese bloqueo se conserve al pasar a la distribución de escritorio.

Este tipo de incidencia demuestra por qué no basta con revisar cada tamaño de forma aislada. También deben probarse las transiciones entre ellos.

Formularios y teclado virtual

Los formularios requieren una revisión específica porque combinan contenido, interacción, validaciones y entrada de datos.

Al tocar un campo desde un dispositivo móvil, el teclado virtual reduce el área visible. En ese momento pueden aparecer problemas que no se observan en la emulación de escritorio:

• El campo enfocado queda oculto.
• El botón de envío desaparece detrás del teclado.
• La página no permite desplazarse lo suficiente.
• Una barra inferior fija cubre parte del formulario.
• Los mensajes de error aparecen fuera del área visible.
• El navegador aplica zoom automático.
• Se muestra un tipo de teclado inadecuado.

Es importante comprobar que cada campo utiliza el tipo de entrada apropiado, como email, tel, number o date, y que los mensajes de validación no alteran de forma inesperada la composición.

Para profundizar en este punto, puede consultarse la guía sobre formularios accesibles, etiquetas, validaciones y feedback, donde se explican criterios que también deberían formar parte de las pruebas en móvil.

Probar el formulario con errores activos

No basta con completar el formulario correctamente. También debe enviarse vacío o con datos incorrectos.

La aparición de varios errores puede aumentar la altura de los campos, desplazar botones o modificar el scroll. La interfaz debe continuar siendo comprensible y permitir llegar fácilmente al primer dato que necesita corregirse.

Tablas y bloques de gran anchura

Las tablas son difíciles de adaptar porque pueden contener muchas columnas y datos que no deberían reducirse hasta resultar ilegibles.

Existen varias soluciones posibles:

• Permitir desplazamiento horizontal dentro de un contenedor.
• Mantener fija la primera columna.
• Ocultar datos secundarios.
• Mostrar un resumen y abrir el detalle bajo demanda.
• Convertir cada fila en una tarjeta.
• Crear una vista específica para móvil.

No hay una única estrategia válida. La elección depende de la importancia de los datos y de la tarea que deba realizar la persona usuaria.

Lo que sí debería evitarse es que la tabla provoque el desplazamiento horizontal de toda la página.

Modales, banners y elementos fijos

Los modales diseñados para escritorio pueden superar fácilmente la altura de una pantalla móvil. Si su contenido interno no permite desplazamiento, los botones de confirmación o cierre pueden quedar inaccesibles.

También deben probarse:

• Paneles laterales.
• Avisos de cookies.
• Cabeceras fijas.
• Navegaciones inferiores.
• Botones flotantes.
• Notificaciones.
• Chats integrados.
• Mensajes promocionales.
• Barras de progreso.

El principal riesgo aparece cuando varios elementos ocupan simultáneamente la misma zona. Una barra de cookies, una navegación inferior y un botón flotante pueden funcionar correctamente por separado, pero superponerse cuando se muestran juntos.

Cómo utilizar las herramientas del navegador

Las herramientas de desarrollo permiten cambiar el tamaño del viewport, simular dispositivos, alternar la orientación y analizar las reglas CSS activas.

Son un buen punto de partida para cualquier proceso de testing responsive.

Comprobaciones básicas con DevTools

Desde el modo de dispositivo se pueden realizar acciones como:

• Seleccionar resoluciones preconfiguradas.
• Introducir una anchura y altura personalizadas.
• Alternar entre orientación vertical y horizontal.
• Simular eventos táctiles.
• Modificar la densidad de píxeles.
• Limitar la velocidad de red.
• Inspeccionar media queries.
• Revisar estilos calculados.
• Capturar la página completa.

Los presets resultan útiles, pero no deberían sustituir las medidas personalizadas ni la revisión manual alrededor de los breakpoints.

Para localizar cajas problemáticas puede añadirse temporalmente una regla de diagnóstico:

* {
  outline: 1px solid rgb(255 0 0 / 15%);
}

Esta técnica permite identificar elementos con una anchura inesperada, márgenes negativos o contenedores que superan los límites de la página.

Revisar dispositivos reales

La emulación del navegador no reproduce todos los comportamientos de un teléfono físico.

Por esta razón, los flujos más importantes deberían comprobarse al menos en una selección reducida de dispositivos reales. Estas pruebas permiten evaluar:

• Respuesta táctil.
• Teclado virtual.
• Gestos.
• Barras dinámicas del navegador.
• Áreas seguras.
• Orientación.
• Rendimiento percibido.
• Legibilidad real.
• Comportamiento durante el scroll.

No es necesario disponer de una colección completa de dispositivos. Puede combinarse una selección local con plataformas de prueba remota para ampliar la cobertura.

Cómo automatizar las pruebas responsive

Las pruebas manuales son esenciales, pero repetir todos los recorridos en cada tamaño consume tiempo. Una parte del proceso puede automatizarse mediante pruebas end-to-end y comparaciones visuales.

Ejecutar un flujo en varios viewports

Una prueba automatizada puede repetir una misma tarea en distintos tamaños de pantalla:

const viewports = [
  { width: 375, height: 667 },
  { width: 768, height: 1024 },
  { width: 1440, height: 900 }
];

for (const viewport of viewports) {
  test(`flujo de compra a ${viewport.width}px`, async ({ page }) => {
    await page.setViewportSize(viewport);
    await page.goto('/productos');

    await page
      .getByRole('button', { name: 'Añadir al carrito' })
      .click();

    await page
      .getByRole('link', { name: 'Ver carrito' })
      .click();

    await expect(
      page.getByRole('heading', { name: 'Tu carrito' })
    ).toBeVisible();
  });
}

Este tipo de prueba confirma que una acción importante continúa disponible en diferentes distribuciones.

Cuando la aplicación está desarrollada con React, puede combinarse el testing end-to-end con pruebas de componentes mediante React Testing Library. Las pruebas de componentes no sustituyen la validación visual, pero ayudan a asegurar que los controles mantienen su comportamiento cuando la interfaz cambia.

Qué recorridos conviene automatizar

Es recomendable empezar por los flujos con mayor impacto:

• Inicio de sesión.
• Registro.
• Búsqueda.
• Navegación principal.
• Compra o reserva.
• Envío de formularios.
• Aplicación de filtros.
• Apertura y cierre de menús.
• Confirmaciones.
• Gestión de errores.

La automatización aporta más valor cuando reproduce tareas reales que cuando se limita a verificar que determinados elementos existen en el DOM.

Detectar desbordamiento horizontal

También puede automatizarse una comprobación básica para detectar si el documento es más ancho que el viewport:

const hasHorizontalOverflow = await page.evaluate(() => {
  const documentElement = document.documentElement;

  return (
    documentElement.scrollWidth >
    documentElement.clientWidth
  );
});

expect(hasHorizontalOverflow).toBe(false);

Esta prueba permite detectar un problema general, aunque no identifica directamente qué elemento lo provoca. También debe interpretarse con cuidado si la interfaz incluye carruseles o tablas con desplazamiento horizontal intencionado.

Incorporar las pruebas a integración continua

Las pruebas responsive automatizadas pueden ejecutarse cada vez que se abre una solicitud de cambios o se actualiza una rama principal.

Una herramienta de integración continua puede:

1. Instalar las dependencias.
2. Construir la aplicación.
3. Levantar un entorno de prueba.
4. Ejecutar los tests en varios viewports.
5. Guardar capturas o vídeos cuando se produce un error.
6. Impedir el despliegue si falla un recorrido crítico.

En el artículo sobre automatización e integración continua con GitHub Actions se explica cómo incorporar tareas automáticas al ciclo de desarrollo.

Testing visual y pruebas exploratorias

La automatización no detecta todos los problemas. Una prueba puede confirmar que un botón existe y puede pulsarse, pero no advertir que está demasiado cerca de otro control o que un texto resulta difícil de leer.

Por ello, las pruebas responsive deben combinar varios enfoques.

Comparaciones visuales

Las pruebas visuales capturan la interfaz en diferentes viewports y comparan las imágenes con una versión de referencia.

Este método ayuda a detectar:

• Cambios inesperados de espaciado.
• Componentes desplazados.
• Elementos desaparecidos.
• Variaciones tipográficas.
• Modificaciones en los breakpoints.
• Regresiones provocadas por estilos globales.

No todas las diferencias representan un error. El contenido dinámico, las fechas o las imágenes variables pueden generar cambios legítimos. Las capturas deben revisarse antes de aceptar o rechazar el nuevo resultado.

Testing exploratorio

El testing exploratorio permite utilizar la aplicación con mayor libertad, cambiar el tamaño de la ventana en mitad de una tarea y probar combinaciones que no estaban contempladas en un guion.

Por ejemplo, se puede:

• Abrir un modal y cambiar la orientación.
• Aplicar filtros antes de reducir la ventana.
• Ampliar el zoom con un menú desplegado.
• Enviar un formulario mientras aparece una notificación.
• Cambiar de escritorio a móvil con una sesión iniciada.
• Probar contenido especialmente largo.

Esta forma de trabajar complementa las comprobaciones automatizadas y ayuda a localizar errores difíciles de anticipar. La guía de testing exploratorio desarrolla con más detalle este enfoque.

Errores frecuentes en el diseño responsive

Utilizar demasiadas anchuras fijas

Las anchuras rígidas pueden provocar desbordamientos cuando el espacio disponible es menor de lo previsto.

En muchos componentes resulta preferible combinar:

• width: 100%.
• max-width.
• Unidades relativas.
• Flexbox.
• CSS Grid.
• Funciones como min(), max() y clamp().

Esto no significa que deban eliminarse todos los valores en píxeles. Siguen siendo útiles para determinados límites, iconos o separaciones. El problema aparece cuando toda la estructura depende de dimensiones invariables.

Ocultar contenido sin valorar su importancia

Adaptar una interfaz a móvil no debería consistir en eliminar todo lo que no cabe.

Antes de ocultar un elemento conviene preguntarse:

• ¿La información continúa disponible en otro lugar?
• ¿La acción sigue pudiendo realizarse?
• ¿El contenido es realmente secundario?
• ¿Puede mostrarse bajo demanda?
• ¿Su ausencia cambia el significado de la pantalla?

En muchos casos, reorganizar o resumir es mejor que ocultar.

Probar únicamente la página de inicio

La portada suele recibir más atención, pero muchos errores aparecen en páginas interiores:

• Resultados de búsqueda.
• Fichas de producto.
• Formularios.
• Áreas privadas.
• Tablas.
• Historiales.
• Ajustes.
• Páginas de error.
• Estados vacíos.

La estrategia de testing debe cubrir las principales plantillas y no limitarse a la pantalla más visible del proyecto.

Ignorar el zoom y el tamaño del texto

Una persona puede ampliar el navegador o configurar un tamaño de fuente mayor. La interfaz debería soportar estos cambios sin perder información ni funcionalidad.

Conviene probar el zoom al 200 %, prestar atención a los contenedores con alturas fijas y comprobar que el texto no queda cortado.

Proceso recomendado para revisar una app

Un proceso organizado facilita repetir las pruebas y reduce la posibilidad de olvidar escenarios importantes.

1. Identificar los recorridos críticos

Seleccione las tareas cuyo fallo tendría mayor impacto, como iniciar sesión, buscar, comprar, reservar o enviar un formulario.

2. Preparar una matriz de tamaños

Incluya móviles, tablets, escritorio y medidas cercanas a cada breakpoint.

3. Utilizar contenido realista

Pruebe textos largos, mensajes de error, estados vacíos, imágenes con distintas proporciones y datos cargados dinámicamente.

4. Revisar los estados interactivos

Abra menús, modales, desplegables, tooltips y campos. Modifique la orientación o el tamaño con los componentes abiertos.

5. Probar dispositivos reales

Repita los recorridos esenciales en una selección de teléfonos y tablets físicos.

6. Automatizar las regresiones importantes

Añada pruebas funcionales y visuales para los componentes y flujos con mayor riesgo.

7. Documentar cada incidencia

Un error responsive debería incluir:

• Página afectada.
• Anchura y altura del viewport.
• Dispositivo o emulación utilizada.
• Navegador y sistema operativo.
• Pasos para reproducirlo.
• Resultado esperado.
• Resultado obtenido.
• Captura o vídeo.
• Prioridad.

Una descripción como “se ve mal en móvil” no contiene información suficiente para reproducir ni resolver el problema.

Checklist de testing responsive antes de publicar

Antes de lanzar una versión, conviene comprobar lo siguiente:

• No existe desplazamiento horizontal accidental.
• Los títulos largos mantienen la estructura.
• Los textos no quedan cortados.
• Las imágenes respetan sus contenedores.
• Los menús pueden abrirse y cerrarse.
• Los botones son cómodos de utilizar en pantallas táctiles.
• Los formularios funcionan con el teclado virtual.
• Los errores son visibles y comprensibles.
• Los modales permiten acceder a todo su contenido.
• Las tablas tienen una estrategia específica para móvil.
• Los elementos fijos no se superponen.
• El zoom no impide utilizar la interfaz.
• Los cambios de orientación no rompen la distribución.
• Los breakpoints funcionan antes, durante y después de su valor.
• Los recorridos principales pueden completarse en móvil, tablet y escritorio.
• Las pruebas automatizadas no muestran nuevas regresiones.

Preguntas frecuentes sobre testing responsive

¿Cuántos tamaños de pantalla es necesario probar?

No existe una cantidad universal. Como punto de partida, conviene probar un móvil estrecho, un móvil estándar, una tablet, un portátil y un escritorio.

También es importante revisar los píxeles inmediatamente anteriores y posteriores a cada breakpoint. Más que acumular dispositivos preconfigurados, interesa comprobar cómo se comporta el contenido durante todo el cambio de anchura.

¿Es suficiente utilizar las herramientas de desarrollo del navegador?

No. Las herramientas del navegador son muy útiles para detectar problemas de distribución y probar numerosos viewports, pero no reproducen completamente el teclado virtual, los gestos, las barras dinámicas o determinadas diferencias entre navegadores móviles.

Los recorridos más importantes deberían probarse también en algunos dispositivos reales.

¿Se puede automatizar por completo el testing responsive?

No completamente. Es posible automatizar flujos, capturas de pantalla, comprobaciones de desbordamiento y comparaciones visuales.

Sin embargo, todavía se necesita una revisión humana para valorar la legibilidad, la jerarquía, la comodidad táctil y la calidad general de la experiencia. La estrategia más eficaz combina automatización, pruebas manuales y testing exploratorio.

Una interfaz flexible necesita pruebas flexibles

El testing responsive no es una tarea decorativa ni una comprobación que deba dejarse para los últimos minutos antes de publicar. Es una forma de garantizar que la aplicación continúa siendo útil cuando cambian las condiciones de acceso.

Una interfaz no debería depender de que la persona utilice el mismo dispositivo, orientación o tamaño de ventana imaginado durante el diseño. Debe responder con flexibilidad, conservar sus funciones principales y mantener el contenido comprensible.

Las mejores pruebas responsive no se limitan a preguntar si la página cabe en una pantalla. También comprueban si puede utilizarse con comodidad, si los controles permanecen disponibles, si los mensajes se entienden y si las transiciones entre tamaños se producen sin errores.

Integrar estas comprobaciones durante el desarrollo permite detectar los problemas cuando todavía son fáciles de corregir. También reduce regresiones, mejora la mantenibilidad del CSS y evita que sean las personas usuarias quienes descubran los fallos después del lanzamiento.

En definitiva, un buen diseño responsive no se demuestra con una única captura perfecta. Se demuestra mediante una experiencia sólida en diferentes tamaños, contenidos y formas de interacción.