Cómo probar un diseño responsive: un método que encuentra fallos reales

Para probar bien un diseño responsive, haz tres pasadas: recorre despacio el ancho del viewport desde unos 320 px hasta 1920 px para encontrar dónde se rompe el diseño, revisa dispositivos concretos con su user agent y densidad de píxeles reales, y fuerza el diseño con contenido largo y zoom al 200 %. La mayoría de los fallos responsive viven entre los breakpoints y en contenidos para los que no se diseñó, por eso revisar tres tamaños fijos (“móvil, tablet, escritorio”) no los detecta.

Por qué no basta con revisar tres tamaños

Un diseño se crea para unos pocos anchos, pero se usa en todos. Un título que cabe en 375 px puede partirse mal en 344 px (algunos móviles plegables cerrados). Una barra de navegación que cabe en 1024 px puede desbordarse en 1100 px en cuanto un elemento del menú se alarga. Los fallos se concentran:

• justo por debajo y por encima de cada breakpoint;
• en anchos para los que nadie diseñó, como 600–700 px (tablets pequeñas, ventanas en pantalla dividida);
• con contenido real más largo que el del mockup.

Pasada 1: el barrido de anchos

1. Abre Chrome DevTools, activa la barra de dispositivos (Ctrl + Shift + M, o Cmd + Shift + M en Mac) y elige Responsive.
2. Pon el ancho en 320 px y arrastra despacio el borde derecho hasta el tamaño más ancho que soportes.
3. Fíjate en: barras de desplazamiento horizontal, textos que se solapan, botones que pasan a dos líneas, imágenes estiradas, grids con una tarjeta huérfana y elementos que saltan al cambiar de breakpoint.
4. Cuando algo se rompa, apunta el ancho exacto que muestra la barra.

Activa Show media queries en el menú de la barra de dispositivos para ver tus breakpoints como barras de colores sobre el viewport. Al hacer clic en una barra saltas a ese ancho. Tienes ayuda paso a paso del modo dispositivo en la guía del emulador móvil de Chrome.

Un buen hábito: prueba cada breakpoint en su valor exacto y un píxel por debajo. Los errores de un píxel entre max-width: 768px y min-width: 768px son muy habituales.

Pasada 2: perfiles de dispositivos reales

El ancho es solo una parte de lo que informa un teléfono. Los dispositivos también envían un user agent móvil, tienen una densidad de píxeles de 2 o 3 y pueden activar un comportamiento distinto en el servidor o en JavaScript. Revisa tus páginas clave con perfiles concretos:

• un móvil pequeño (unos 360–375 px de ancho);
• un iPhone actual (393–402 px) y un iPhone grande (430–440 px); los valores están en la tabla de tamaños de pantalla del iPhone;
• un móvil Android (360–412 px);
• una tablet en ambas orientaciones (guía de iPad y tablets).

Los preajustes de dispositivos de DevTools sirven para esto. Una extensión para probar responsive como Mobile View Extension es más rápida cuando tienes que recorrer muchas páginas: recarga la pestaña con el user agent, el tamaño de pantalla y la densidad de píxeles del dispositivo, mantiene ese dispositivo mientras navegas y te deja comparar vistas de la misma página una al lado de otra.

Pasada 3: fuerza el contenido

Los mockups usan contenido perfecto. Las webs reales, no. Prueba:

• Palabras y cadenas largas: un nombre de producto larguísimo, una traducción al alemán, un email o una URL en una columna estrecha. Añade overflow-wrap: anywhere donde haga falta.
• Más o menos elementos: un menú con ocho elementos en lugar de cinco, un grid con siete tarjetas en lugar de seis.
• Imágenes que faltan: ¿cómo se ve la tarjeta cuando la imagen falla o aún está cargando?
• Texto grande: pon el tamaño de fuente predeterminado del navegador en 20 px o más. Los diseños hechos con rem deberían escalar; las cajas de altura fija cortarán el texto.
• Zoom al 200 % y 400 % en escritorio: el zoom estrecha el viewport CSS, así que al 400 % una ventana de 1280 px se comporta como una pantalla de 320 px. WCAG 2.2 exige que a ese tamaño el contenido se reorganice sin desplazamiento en dos direcciones, salvo contenidos como mapas y tablas de datos.

Pasada 4: automatiza las capturas

Las pasadas manuales encuentran un fallo una vez, y una captura de pantalla móvil adjunta a un ticket muestra el ancho exacto en el que algo se rompió. Las capturas automáticas lo detectan cuando vuelve. Con una herramienta como Playwright, un script corto puede abrir tus páginas clave a, por ejemplo, 360, 768, 1024 y 1440 px en Chromium, Firefox y WebKit, y comparar las capturas con la versión anterior en cada pull request. Este tipo de prueba de regresión visual encaja bien con sistemas de diseño y páginas de marketing que cambian a menudo.

Comprobadores responsive online

Las webs que muestran tu URL en varios marcos a la vez son útiles para un vistazo rápido. Tienen límites: cargan tu página desde sus servidores o en iframes, así que no llegan a localhost ni a páginas tras un login; muchos sitios bloquean que los metan en un marco; y los marcos normalmente solo cambian el ancho, no el user agent. Úsalos para echar un vistazo, no para dar el visto bueno.

Checklist de pruebas de diseño responsive

Para las revisiones previas al lanzamiento más allá del diseño (formularios, velocidad, SEO), usa el checklist de pruebas de una web móvil.

Preguntas frecuentes

¿Cómo compruebo rápido si una web es responsive?

Abre Chrome DevTools, elige el modo Responsive en la barra de dispositivos y arrastra el ancho desde 320 px hacia arriba. Todo lo que se desborde o se solape es un fallo responsive.

¿Qué tamaños de pantalla debo probar en un diseño responsive?

Recorre todos los anchos desde 320 px y después revisa 360, 375, 390–402, 412 y 430–440 px para móviles, unos 768–834 px y 1024 px para tablets, y 1280–1920 px para escritorio.

¿Redimensionar la ventana del navegador es una prueba responsive válida?

Es una prueba válida de los breakpoints de CSS, pero los navegadores de escritorio dejan de estrecharse en torno a 500 px y no envían un user agent móvil. Para anchos de teléfono, usa el modo dispositivo o una extensión de vista móvil.