Mobile Always: guía de diseño para WordPress optimizado para móviles

La mayoría del tráfico web mundial llega desde dispositivos móviles. En sectores como el ecommerce, la formación online o los negocios locales (que son precisamente los que concentran buena parte de los proyectos WordPress) ese porcentaje es todavía más alto.

Y aun así, la gran mayoría de proyectos empiezan diseñándose en escritorio.

A primera vista parece una contradicción. Pero no lo es, o al menos no del todo.

Diseñamos en escritorio porque es más cómodo, porque tenemos más espacio, porque las herramientas están pensadas para ello y porque el propio cliente suele validar en escritorio.

El problema no es ese punto de partida. El problema es lo que viene después: tomar decisiones pensando en escritorio y adaptar «como se pueda» a móvil al final del proceso.

Ahí es donde se rompe todo.

Se rompe la jerarquía, se rompe la legibilidad, se rompe la interacción. Y, sobre todo, se rompe la experiencia real de la mayoría de usuarios.

Mobile Always no propone diseñar solo para móvil ni renunciar al escritorio. Propone algo más pragmático: tomar decisiones teniendo en cuenta el contexto móvil durante todo el proceso, aunque estés trabajando en la versión de escritorio.

Porque no se trata de por dónde empiezas. Se trata de pensar en para quién estás diseñando.

1. Qué es Mobile Always
2. El proceso en la práctica
3. Los 11 pilares para diseñar pensando siempre en móvil
4. Los patrones de transformación más habituales en proyectos WordPress
5. Cómo comprobar que la experiencia móvil funciona de verdad
6. Qué tienes que comprobar en cada proyecto: la checklist Mobile Always
7. Mobile Always es pensar siempre en móvil

Qué es Mobile Always

Mobile Always es una metodología de diseño para WordPress que parte de la premisa de que el móvil no es una fase del proceso, sino un principio que atraviesa todas las decisiones de diseño.

La propuesta es que no tenemos por qué empezar siempre por el móvil ni ignorar la realidad de cómo funcionan las herramientas. Lo que propongo es pensar en móvil desde el primer momento, aún en los proyectos en los que arrancamos el proceso por la versión de escritorio.

WordPress es desktop-first. Esto es así porque cuando se definió la arquitectura de WordPress, el uso de la web era mayoritariamente en escritorio, así que el sistema se diseñó para ese contexto, con el móvil como adaptación posterior mediante media queries.

Cuando inspeccionas el CSS de los temas más utilizados (Kadence, Astra, GeneratePress, Storefront…) encuentras siempre el mismo patrón: los estilos base definen el layout de escritorio, y los breakpoints ajustan hacia abajo con max-width. El móvil es un ajuste, no es el origen.

El editor de bloques tampoco sigue una estrategia mobile-first consistente. Hay bloques del núcleo que usan max-width e incluso !important para adaptar el diseño en pantallas pequeñas.

Los constructores visuales (Elementor, Divi, Bricks, Beaver Builder) no pueden funcionar en un lienzo de 360 px: sus paneles, opciones y herramientas no caben ahí. El estado base del editor es escritorio, porque si no lo fuera, la experiencia de edición sería prácticamente inutilizable.

A esto se suma que muchos clientes quieren ver primero la versión grande. No porque no les importe el móvil, sino porque en escritorio se entiende mejor la propuesta. Ven la composición completa, la jerarquía visual, el branding. En las reuniones de revisión, en las videollamadas de validación, siempre se abre el portátil, no el teléfono.

El resultado es que en la mayoría de proyectos WordPress, el proceso arranca en escritorio, y tiene todo el sentido que así sea.

El problema no es en qué tamaño arranque el proyecto: el problema es tomar decisiones en escritorio que luego son imposibles de trasladar a una pantalla de 360 px. Eso es lo que resuelve mi enfoque: Mobile Always.

La pregunta que tienes que hacerte siempre es la misma: ¿cómo va a funcionar esto en una pantalla de 360 px?

Si esa pregunta está presente desde los wireframes, la versión móvil no será un parche, sino que será la consecuencia natural de decisiones que ya estaban pensadas para ella.

El proceso en la práctica

La secuencia estándar de Mobile Always refleja cómo se trabaja en la mayoría de proyectos WordPress, pero con un marco definido para entender cómo se toman las decisiones en cada paso.

En la fase de wireframes, la estructura del sitio ya se define pensando en cómo va a funcionar el diseño en una pantalla pequeña: jerarquía de contenido, prioridad de acciones, flujos simplificados para 360 px, bloques que puedan expandirse sin romperse. Nos fijamos más en qué tiene que pasar, no en cómo se va a ver.

Con esa arquitectura ya definida, se diseña la primera versión visual en escritorio. El escritorio es el estado base en WordPress, facilita la validación del branding y permite explicar el concepto global al cliente con claridad. Lo importante es que en este punto ya tienes una estructura pensada para móvil, así que cada decisión visual que tomas ya tiene en cuenta cómo se va a adaptar.

Después, con el escritorio aprobado por el cliente, se diseña la versión móvil de forma consciente: se reorganizan módulos para pantallas verticales, se aplican patrones de interacción táctiles, se ajustan tipografías, espaciados y densidades. La versión móvil no se improvisa: se apoya en una arquitectura que ya fue pensada con el móvil en mente.

Hay muchos proyectos en los que este orden se invierte. Un e-commerce que capta clientes exclusivamente a través de Instagram. Una landing page de campaña donde el 95 % del tráfico llega desde el móvil. En esos casos, tiene todo el sentido presentar primero la versión para 360 px.

Pero incluso ahí, la maquetación va a arrancar en la versión de escritorio porque la arquitectura de WordPress así lo determina. Lo que cambia es la secuencia de validación con el cliente, no el funcionamiento de la herramienta.

Los 11 pilares para diseñar pensando siempre en móvil

Aquí está el núcleo práctico del método Mobile Always. Estos once pilares son las decisiones que marcan la diferencia entre una versión móvil que tiene una buena experiencia y una versión móvil que es en realidad un parche de la versión escritorio.

Jerarquía definida desde los wireframes

Antes de diseñar cualquier vista, hay que establecer qué es crítico, qué es importante y qué es secundario. En móvil esta jerarquía se vuelve decisiva porque el espacio obliga a compactar.

Los elementos críticos (navegación, título principal, CTA primaria) se mantienen en todas las vistas, sin excepción.

Los elementos importantes (subtítulos, CTA secundarias, características clave) pueden reducirse o reorganizarse.

Los elementos secundarios (microcontenidos, recursos visuales complementarios) en la vista para móviles podemos integrarlos en patrones de lectura progresiva o podemos directamente no incluirlos en móvil.

Esta definición ocurre en los wireframes. Cuando llega el momento de crear el diseño visual de la versión móvil, ya está decidido qué se oculta y qué se simplifica.

Densidad de información

Un diseño que depende del espacio horizontal o de grandes cantidades de aire suele generar una versión móvil muy pobre visualmente.

Un diseño que nace con una jerarquía clara se adapta sin problemas.

En la práctica, una sección amplia en la versión de escritorio, como puede ser, por ejemplo, una sección principal con varias líneas de texto, dos CTA, una imagen compleja y elementos decorativos, necesitará una versión simplificada para móvil: títulos más breves, sin subtítulos y con imágenes más contenidas o con fondos sólidos en lugar de fotografías con muchas capas.

Cuándo usar un solo bloque y cuándo usar dos

La mayoría de las veces, la decisión correcta es un único bloque cuyo CSS adapta la presentación según el tamaño de pantalla. Una tarjeta que pasa de horizontal a vertical, una cuadrícula que pasa de tres columnas a una, un menú que cambia de formato: todo esto lo podemos resolver con un solo bloque, con los estilos adecuados.

La otra opción es usar un bloque para la versión móvil y otro diferente para la versión de escritorio, y alternar la visibilidad por dispositivo. Esta opción tiene una desventaja porque, a veces, WordPress oculta el bloque con CSS, pero lo sigue renderizando en el HTML: el contenido sigue cargándose aunque el usuario no lo vea (y aunque los lectores de pantalla no lo lean).

Hay estrategias para no renderizar el bloque en HTML, pero es importante que lo tengamos en cuenta. Además, dos bloques distintos también tienen el inconveniente de que si hace falta cambiar el texto, hay que cambiarlo dos veces, así que tiene mayor coste de implementación y de gestión.

Por lo tanto, antes de duplicar, merece la pena preguntarse si realmente el contenido tiene que ser distinto o si basta con que la presentación sea distinta.

Tipografía fluida y escala modular diferenciada

La tipografía es una de las decisiones que más afecta a la experiencia móvil y una de las que más se descuidan cuando el proceso empieza en versión de escritorio.

El tamaño de la fuente en escritorio tiene que ser mayor que en móviles. Para conseguir esto, el enfoque clásico era declarar un tamaño de fuente en móvil y otro en escritorio con media queries. Funcionaba, pero producía saltos bruscos en los valores cercanos a los puntos de ruptura.

Con clamp() ese problema desaparece: la tipografía escala de forma continua entre un valor mínimo y un máximo, en función del ancho del viewport.

font-size: clamp(1rem, 0.5rem + 1.5vw, 1.25rem);

Documentar estos valores como rangos en el archivo de diseño (mínimo y máximo, con el tamaño de los frames de Figma como referencia) da al desarrollador todo lo que necesita para construir la fórmula con clamp() con cualquiera de las calculadoras online disponibles.

Además, para optimizar la experiencia en todos los dispositivos, elegimos una ratio diferente de escala modular. En la versión de escritorio, con una ratio de 1.25 (Major Third), un h1 llega a 3 rem. En móvil, esa misma escala resultaría desproporcionada y el h1 ocuparía demasiado espacio del área visible. La solución es usar una ratio más moderada en móvil, por ejemplo 1.125 (Major Second). Con clamp() se interpola entre ambas escalas para cada nivel de encabezado, sin saltos ni media queries adicionales:

h1 { font-size: clamp(1.802rem, 1.2rem + 2.5vw, 3.052rem); }
h2 { font-size: clamp(1.602rem, 1.1rem + 2vw,   2.441rem); }
h3 { font-size: clamp(1.424rem, 1rem + 1.5vw,   1.953rem); }

Siempre declaramos los valores en rem, nunca en px. Porque los píxeles no respetan el tamaño de fuente que el usuario haya configurado en su navegador y el rem sí es proporcional a la configuración del usuario.

Espaciado fluido

El mismo principio que aplicamos a la tipografía se aplica al espaciado. Los márgenes, rellenos y separaciones entre secciones también deben escalar de forma fluida. Sin saltos y sin media queries adicionales.

/* Separación entre secciones */
.section { padding-block: clamp(2rem, 1rem + 4vw, 6rem); }

/* Espacio interno de un componente */
.card { padding: clamp(1rem, 0.5rem + 2vw, 2rem); }

Interacción táctil: medidas y ergonomía del pulgar

En dispositivos móviles, la mayoría de personas navegan con el pulgar sujetando el teléfono con una sola mano. Esto condiciona el diseño en dos aspectos.

El primero es el tamaño táctil. Las guías de accesibilidad recomiendan un mínimo de 44-48 px para elementos interactivos. En la práctica, cuando piensas en cómo se usa el teléfono en el día a día (caminando, en el transporte, con la atención repartida), ese mínimo se queda justo. Conviene ir algo más allá:

• Botones secundarios y acciones habituales: 48×48 px
• CTA principales: 56×56 px
• Acciones críticas (comprar, enviar, reservar): 60-64 px

El segundo aspecto es la posición en pantalla. No todas las zonas son igual de accesibles para el pulgar. Para un usuario diestro, la zona de alcance cómodo se concentra en la parte central e inferior derecha. La esquina superior izquierda es la zona más difícil de alcanzar.

Para los elementos más críticos tiene sentido recurrir a los sticky CTAs: botones anclados en la parte inferior del área visible en el navegador que permanecen mientras el usuario se desplaza. En un e-commerce, mantener el botón «Añadir al carrito» visible mientras el usuario lee la descripción del producto puede tener un impacto real en la conversión.

5 técnicas de gestión del scroll

La página en móvil es inevitablemente más larga que en escritorio, así que hay que intentar que sea lo más corta posible. No quiero decir que el scroll sea un problema: sabemos que al usuario no le cuesta nada hacer scroll. El problema es que el usuario llegue a la pantalla, no encuentre lo que busca y abandone antes de llegar al contenido relevante.

Hay cinco técnicas que permiten reducir la longitud vertical sin tener que ocultar contenido:

• Los carruseles horizontales transforman cuadrículas de varias columnas en módulos desplazables con un gesto lateral completamente natural en móvil.
• Las pestañas permiten alternar entre bloques de contenido sin generar scroll adicional. Por ejemplo, «Ver listado o Ver mapa».
• Los acordeones muestran inicialmente solo el título y se expanden al tocar.
• El contenido progresivo (un extracto con «Leer más») es una opción intermedia muy útil para descripciones o testimonios largos.
• Y la reducción de imágenes superfluas o redundantes: elimina todo lo que no ayude al usuario a entender, decidir o confiar.

Cada una de estas técnicas tiene ventajas y desventajas concretas. El carrusel, por ejemplo, falla cuando esconde contenido decisivo que el usuario necesita ver para tomar una decisión.

También tienes que tener en cuenta que si conviertes en carrusel una lista de ventajas de un producto, el usuario puede asumir que los elementos ocultos son menos importantes, o directamente no llegar a verlos.

Interacciones hover y sus alternativas táctiles

El hover no existe en móvil. Cualquier componente que dependa de pasar el ratón por encima necesita una alternativa táctil definida antes de que lo demos por válido.

Algunos ejemplos concretos:

• Un tooltip que aparece al hacer hover en escritorio, en móvil es un panel que se activa con un toque.
• Un menú desplegable que se abre al hover en escritorio, en móvil es un menú que se abre con un toque, y está explícito con un icono de flecha que indica la acción disponible.
• Una galería que muestra información al pasar por encima de una imagen en escritorio, en móvil se abre un panel con esa información al tocar la imagen.

Recorte y comportamiento de imágenes

• object-fit: cover rellena el contenedor recortando la imagen si es necesario.
• object-fit: contain muestra la imagen completa, con posible espacio sobrante.
• object-position indica desde qué punto se hace el recorte, especialmente útil si aparece una persona en la fotografía y no está centrada.

Conviene que decidas y documentes para cada imagen: si debe encajar con cover o con contain, cuál es el punto de anclaje del recorte, y si la relación de aspecto cambia entre la versión de escritorio y la versión móvil. Sin estas indicaciones, lo normal es que se apliquen los valores por defecto, que pueden no coincidir con lo que diseñaste.

Formularios en móvil

Los formularios son uno de los patrones más comunes en WordPress y también uno de los que más problemas dan en móvil.

Los campos deben tener una altura mínima de 48 px y separación suficiente para evitar toques accidentales.

También hay que tener en cuenta cuestiones de usabilidad, como que los mensajes de error sean visibles sin tener que hacer scroll para encontrarlos.

Navegación más allá del menú hamburguesa

El menú hamburguesa funciona bien en muchos contextos, pero no es la única opción ni siempre la mejor.

Cuando el sitio tiene entre tres y cinco secciones y la navegación es frecuente, una barra de navegación fija en la parte inferior del área visible puede ser más eficiente.

Está en la zona de alcance cómodo del pulgar, siempre visible y no requiere abrir ningún panel. Es el patrón que usan prácticamente todas las aplicaciones nativas y que funciona muy bien en e-commerce o plataformas de contenido donde el usuario salta constantemente entre secciones.

Para estructuras intermedias, la priority+ navigation muestra los elementos más importantes directamente y agrupa el resto bajo un botón «Más».

Los patrones de transformación más habituales en proyectos WordPress

Los once pilares anteriores son el marco de trabajo. Ahora vamos a ver cómo aplicar transformaciones concretas a algunos de los patrones más habituales: cómo pasa una cuadrícula de tres columnas a móvil, qué hacer con una barra lateral o cómo funciona una sección hero compleja en 360 px.

Rejillas

Si es importante que se vean todos elementos (una comparativa de precios, una lista de ventajas), en móviles se apilan verticalmente, cuidando que cada elemento sea suficientemente compacto para que el usuario vea varios a la vez y se puedan entender como un conjunto. En un listado de productos, por ejemplo, es preferible una rejilla de dos columnas que de una.

Si los elementos son de exploración (productos relacionados, logos de clientes, casos de éxito), el carrusel horizontal puede ser más eficiente.

Secciones hero

Un hero complejo, que tenga una imagen de fondo, texto superpuesto, subtítulo, dos CTA y elementos decorativos puede convertirse en un bloque ilegible en 360 px.

La transformación correcta a móvil pasa por separar lo que en la versión de escritorio está superpuesto: texto sobre fondo sólido o degradado de color, y después la imagen. Esto garantiza el contraste y hace que la CTA sea perfectamente accesible.

Barras laterales

Si la barra lateral contiene contenido secundario (artículos relacionados, widgets de redes sociales), lo más limpio es moverlo al final de la página, después del contenido principal. El usuario que ha leído el artículo es el más propenso a interactuar con ese contenido.

Si contiene filtros de búsqueda, la solución más usable es convertirlos en un panel deslizante que se abre desde un botón «Filtrar» visible en la parte superior de los resultados.

Si se trata de contenido relevante o CTA importantes, lo mejor es incorporarlos a lo largo del contenido, en la columna principal.

Tablas

Con las tablas hay tres aproximaciones posibles:

• Scroll horizontal controlado (con indicador visual de que es posible desplazarse).
• Tarjetas individuales, cuando la tabla compara opciones entre sí.
• Lista con acordeón, cuando hay muchas filas pero pocas columnas clave.

Pies de página

En los pies de página extensos, los enlaces de navegación secundaria se reorganizan como listas verticales agrupadas. Si hay muchos grupos, los acordeones mantienen el footer compacto sin tener que eliminar ningún enlace.

Recuerda que la dirección, el teléfono y el correo electrónico deben tener hipervínculos activos: tocar un número de teléfono tiene que abrir la app de llamadas.

Cómo comprobar que la experiencia móvil funciona de verdad

Diseñar bien no es suficiente si no verificamos que lo que hemos diseñado se comporta como esperamos.

Arrastrar el borde de la ventana del navegador da una idea rápida de los puntos de ruptura problemáticos, pero no siempre es fiable. El inspector de elementos tampoco reproduce con total fidelidad el comportamiento real. Lo que ves en una ventana redimensionada no es exactamente lo que verá el usuario en su dispositivo.

Hay propiedades CSS que funcionan en escritorio pero no en determinados sistemas operativos móviles. Hay comportamientos (como el teclado virtual que encoge el área visible al aparecer o las barras de navegación del sistema que se superponen al contenido) que solo se manifiestan en un dispositivo real.

La comprobación más fiable se hace con dispositivos reales una vez la web está publicada. La práctica habitual es visitar la web con los dispositivos que tienes a mano y detectar los ajustes pendientes. En proyectos con un público diverso, conviene cubrir al menos iOS y Android, y al menos dos tamaños de pantalla distintos.

Para una revisión más sistemática existen herramientas como BrowserStack y TestMu AI (antes conocido como LambdaTest), que dan acceso en la nube a miles de combinaciones reales de dispositivo, navegador y sistema operativo. Son herramientas de pago, y para un proyecto pequeño puede no tener sentido la inversión. Pero si el diseño es complejo, el cliente tiene usuarios en dispositivos variados, o la conversión depende de que la experiencia móvil funcione bien, la inversión se justifica rápidamente. Un error en el flujo de compra en iOS que no detectas hasta que un cliente se queja puede salir mucho más caro que un mes de una herramienta de testeo.

Conviene asumir desde el principio que normalmente va a haber ajustes después de publicar. No es un fallo del proceso: es la naturaleza del entorno. El objetivo no es eliminar esos ajustes, sino detectarlos cuanto antes y reducirlos al mínimo gracias a un buen diseño.

Qué tienes que comprobar en cada proyecto: la checklist Mobile Always

Estos son los puntos de revisión que conviene aplicar antes de dar por cerrado el diseño de una página, patrón o bloque:

Jerarquía y contenido

• ¿El bloque puede reorganizarse de forma coherente cuando se apila verticalmente?
• ¿El contenido esencial es identificable y legible en una pantalla de 360 px?
• ¿La jerarquía de acciones se mantiene clara al cambiar de posición?
• ¿El contenido crítico sigue siendo accesible sin exigir scroll excesivo?

Elementos visuales

• ¿Las imágenes conservan su sentido al cambiar de proporción? ¿Está documentado el comportamiento de recorte (cover/contain, object-position)?
• ¿El texto superpuesto a imágenes mantiene suficiente contraste en móvil?
• ¿Las imágenes decorativas se han eliminado o reducido para no penalizar la carga?

Interacción

• ¿Los elementos interactivos tienen un área táctil mínima de 48 px?
• ¿Los CTA críticos tienen 56-64 px?
• ¿Hay suficiente separación entre elementos interactivos para evitar toques accidentales?
• ¿Cada interacción que depende de hover tiene una alternativa táctil definida?
• ¿Los CTA importantes están posicionados en la zona de alcance cómodo del pulgar?

Tipografía y espaciado

• ¿Los tamaños tipográficos usan rem y escalan con clamp() entre la escala de móvil (ratio 1.125) y la de escritorio (ratio 1.25)?
• ¿El cuerpo de texto tiene un mínimo de 1 rem?
• ¿El espaciado entre secciones y componentes también usa clamp()?

Formularios

• ¿Los campos tienen altura mínima de 48 px?
• ¿Los mensajes de error son visibles sin necesidad de scroll para encontrarlos?

Patrones de scroll

• ¿Los grids de varias columnas tienen una transformación definida (apilado o carrusel)?
• ¿Los carruseles solo se usan para contenido de exploración, no para contenido que el usuario necesita ver completo?
• ¿Los acordeones solo se usan para contenido secundario, no para contenido de conversión?

Navegación

• ¿La estructura de navegación es adecuada para el número de elementos y la frecuencia de uso?
• ¿Los submenús tienen una alternativa táctil clara (navegación en cascada, acordeones)?
• ¿El pie de página tiene los datos de contacto con hipervínculos activos (tel:, mailto:)?

Comprobación final

• ¿El diseño se ha revisado en dispositivo físico real, no solo en el inspector de elementos?

Mobile Always es pensar siempre en móvil

Mobile Always no es un método que te diga exactamente qué hacer en cada situación. Es una forma de pensar que te obliga a hacerte siempre la misma pregunta: ¿cómo va a funcionar esto en una pantalla de 360 px?

No se trata tanto de si empezamos a diseñar por la versión móvil o por la de escritorio. Eso dependerá de las necesidades del proyecto.

Lo importante es entender bien cómo se va a usar nuestro diseño en dispositivos móviles y cómo podemos adaptar el diseño para que esa experiencia sea lo más fluida posible.

A partir de ahí, las decisiones cambian.

Si tienes clara la ergonomía del pulgar, no diseñarás CTA en la esquina superior izquierda.

Si entiendes la escala modular, no aplicarás la misma ratio en móvil que en escritorio.

Si entiendes cómo funciona clamp(), documentarás rangos fluidos en lugar de valores fijos para cada punto de ruptura.

Ninguna de estas decisiones requiere más tiempo. Requieren entender lo que estás haciendo y cómo funcionan las cosas.

Diseñar bien para móviles no es empezar por el móvil. Es no dejar de tenerlo en cuenta en ningún momento.

Eso es Mobile Always.