Optimizar la web móvil para negocios cuyos clientes llegan desde el teléfono

Ha reventado una tubería, el cliente está en el sótano buscando un negocio con una mano mientras con la otra sujeta un cubo. Escribe una búsqueda, abre el primer resultado útil y quiere saber una sola cosa: ¿viene alguien y cómo lo localizo? No lee la historia de una empresa ni se desplaza por tres pantallas. Busca el botón de llamada.

Esta imagen es el punto de partida de este estudio, y es un escenario, no un informe sobre un proyecto concreto. Representa a negocios cuyas solicitudes llegan sobre todo desde el smartphone: servicio de urgencias, reparaciones, peticiones de cita en la pausa del mediodía, consultas desde la obra del cliente. Para ellos, el móvil no es el hermano pequeño del escritorio, sino el caso normal.

Aun así, muchos sitios web se crearon en una pantalla grande. Los diseños se aprobaron en el monitor y en el móvil se «comprobó rápidamente que encajara». El resultado encaja en el sentido de que «nada se sale del borde», pero no está pensado para la situación en la que se necesita.

Quien asesora a negocios de este tipo oye la misma frase con variaciones: en mi ordenador todo se ve bien. Es cierto, y es el núcleo del problema. Al comprobarlo, el propietario está sentado en la oficina, con buena cobertura y dos manos. Sus clientes rara vez. El cambio de perspectiva es la primera tarea, incluso antes de diseñar nada.

Los patrones de error rara vez son espectaculares, son cotidianos. El número de teléfono aparece como texto en la cabecera y no se puede pulsar. La navegación tiene botones que solo se aciertan al segundo intento. El formulario de contacto exige doce campos, entre ellos dos que a nadie le gusta rellenar en el móvil. Al pulsar un campo, el teclado en pantalla empuja el botón de enviar fuera de la vista.

A ello se suma la tecnología de fondo. Una imagen principal de varios megabytes, tres variantes tipográficas, un vídeo incrustado y un widget de chat se cargan incluso cuando la cobertura es débil. Quien busca en una escalera o en el campo, espera. La cobertura móvil no es un valor constante, sino que varía según el lugar y la saturación de la red.

Lo traicionero es que la empresa no ve la pérdida. Quien se marcha no deja ningún mensaje. Las consultas que llegan proceden de quienes aguantaron, y eso crea la falsa impresión de que todo va bien. Si se pierde algo y cuánto, solo puede deducirse del comportamiento, no de la bandeja de entrada.

Antes de diseñar nada, aclaramos tres cosas. Primero: ¿qué situaciones llevan a la página? Un servicio de urgencias, una petición de cita, la comparación de precios y la búsqueda nocturna requieren recorridos distintos. Segundo: ¿qué vía de contacto prefiere realmente la empresa? Un botón de llamada solo sirve si alguien contesta. Tercero: ¿qué muestran los datos, por ejemplo en Search Console y en la analítica web, sobre la proporción de accesos desde móvil?

La zona del pulgar es una regla práctica de ergonomía. Con una sola mano, el pulgar alcanza cómodamente la parte inferior y central de la pantalla, pero apenas la esquina superior opuesta a la mano que sujeta. No es una ley de la naturaleza, pues la gente sostiene el teléfono de formas distintas y los dispositivos son cada vez mayores. Aun así sirve como principio de diseño: las acciones importantes y frecuentes van en la parte inferior; las poco habituales, en la superior.

De ello se deduce un orden de la información. En el móvil, lo que decide si el visitante se queda o se va debe aparecer sin desplazarse: quién es usted, dónde trabaja, cuándo se le puede localizar, cómo llegar. Lo demás sigue más abajo, en el orden en que surgen las dudas. Un visitante que no llama suele querer, antes, que se le resuelva una pregunta.

Ayuda una idea sencilla: cada página tiene una tarea principal. La página de inicio de un servicio de urgencias debe generar confianza y llevar a la llamada; la página de servicio de un mantenimiento debe responder preguntas y permitir pedir cita. Si una página intenta hacer ambas cosas a la vez, pierde en la pantalla pequeña, donde simplemente no hay sitio para caminos secundarios. Definimos la tarea principal antes del primer borrador.

La solución habitual se llama diseño adaptable (responsive): una cuadrícula que se reduce, columnas que se apilan. Es necesario, pero no suficiente. Quien solo apila conserva las prioridades del escritorio, simplemente una debajo de otra. De una cabecera ancha con logotipo, menú y número de teléfono resulta un bloque alto que llena la primera pantalla y empuja lo más importante hacia abajo.

Mobile-first invierte la dirección del trabajo. Primero se crea la versión para móvil con lo que allí importa y luego la ampliamos para pantallas mayores. Esto obliga a decidir: ¿qué es realmente importante, qué puede suprimirse, qué va al final? El escritorio también se beneficia, porque no es un original sobrecargado del que haya que ir quitando cosas con esfuerzo.

Una alternativa serían páginas móviles propias o una aplicación independiente. Descartamos ambas para las pequeñas empresas. Dos versiones duplican el mantenimiento, y una aplicación exigiría una instalación cuando alguien en apuros simplemente toca la pantalla. La tercera opción, una Progressive Web App, compensa para usuarios recurrentes, rara vez para consultas puntuales. Para nuestro caso, un sitio web ligero y rápido sigue siendo el camino más adecuado.

Unas palabras sobre los plugins móviles automáticos que “adaptan una página a los móviles”. Tratan los síntomas, por ejemplo con scripts adicionales, y dejan las prioridades intactas. A veces son una solución provisional, pero no sustituyen la pregunta de qué debe aparecer primero en la pantalla pequeña. Cuando un creador de sitios web o un CMS impone plantillas, comprobamos hasta qué punto pueden adaptarse antes de comprometernos a nada.

También la cantidad de recursos aconseja mantenerlos reducidos. Cuantos menos scripts y widgets, menos puede fallar en un dispositivo de gama baja. Por eso sustituimos funciones, siempre que es posible, por elementos estándar del navegador: enlaces en lugar de scripts, campos de formulario en lugar de desarrollos propios.

El núcleo del planteamiento es una vía de contacto que funciona sin pensar. El número de teléfono se convierte en un enlace que, al tocarlo, abre la marcación. Junto a él puede haber un botón de WhatsApp, si la empresa realmente responde allí a los mensajes. Quien lo ofrece debe también atenderlo; de lo contrario genera una expectativa que nadie cumple. Eso incluye indicar claramente los horarios.

El tamaño de las áreas táctiles es una palanca a menudo subestimada. Como valor orientativo se aplican unos 44 por 44 píxeles; las directrices de diseño de Apple indican 44 puntos y el Material Design de Google, 48. Las pautas de accesibilidad WCAG 2.2 exigen en el nivel AA un mínimo de 24 píxeles, con separación respecto a los elementos contiguos. Planificamos con los valores mayores porque los pulgares son más gruesos que los punteros del ratón y los visitantes en movimiento suelen tocar con una mano.

La barra de contacto fija (sticky) en el borde inferior mantiene la llamada siempre al alcance. Tiene sus trampas, que despejamos de antemano: no debe tapar el contenido ni el pie de página, por lo que la página recibe un margen interior inferior acorde. Debe colocarse delante del teclado en pantalla u ocultarse cuando un campo de formulario está activo. Y no debe ser más alta de lo necesario, pues en dispositivos pequeños apenas quedaría superficie de lectura.

En el formulario, cada campo cuesta. Para una petición de cita suelen bastar el nombre, el teléfono o el correo electrónico, una breve descripción y el consentimiento para el tratamiento de datos. Todo lo demás puede aclararse en la llamada de respuesta. Cuando los datos adicionales son útiles, por ejemplo el código postal para la zona de actuación, figuran como campos opcionales, no obligatorios.

Técnicamente, muchas cosas son más sencillas de lo que parece si se usan elementos estándar. Una llamada es un enlace con tel: y el número en formato internacional. Un mensaje de WhatsApp se envía mediante un enlace wa.me con un texto sugerido opcional. Ambos funcionan sin script, sin plugin y sin tiempo de carga. En el escritorio, donde no hay teléfono a mano, el mismo enlace puede mostrarse como número de texto con ayuda para copiarlo.

En el formulario, unos pocos atributos determinan la comodidad. El tipo de campo tel abre el teclado numérico, email el teclado con la arroba, y autocomplete permite que el dispositivo sugiera nombre y dirección. El tamaño de fuente en los campos de entrada debería ser de al menos 16 píxeles; de lo contrario, Safari en el iPhone amplía la vista al tocar y estropea el diseño. Los mensajes de error aparecen junto al campo, no agrupados arriba, donde quedan fuera de la vista.

Para la barra fija usamos position: fixed en el borde inferior, el margen de seguridad env(safe-area-inset-bottom) para dispositivos con barra de gestos y un padding-bottom correspondiente al final de la página. Indicamos las alturas en dvh en lugar de vh, porque en los navegadores móviles la barra de direcciones aparece y desaparece y vh hace que el contenido quede detrás de la barra. Los saltos a anclas reciben scroll-margin para que los títulos no queden bajo la barra.

En cuanto al tiempo de carga, apuntamos a los umbrales de las Core Web Vitals: LCP hasta 2,5 segundos, INP hasta 200 milisegundos, CLS hasta 0,1. El elemento visible más grande, normalmente la imagen principal, lo cargamos pronto y con un tamaño adecuado, con srcset para distintos anchos y formatos modernos como WebP o AVIF. Las imágenes situadas por debajo de la primera pantalla se cargan de forma diferida; la principal, no. Limitamos las fuentes a lo necesario y las servimos nosotros mismos.

Los casos especiales solo aparecen en dispositivos reales. El más frecuente: el formulario funciona bien en el escritorio, pero en el móvil el teclado empuja el botón de envío fuera de la pantalla y el visitante lo busca hasta que desiste. La solución es una maquetación que, al enfocar un campo, desplace el campo activo a la zona visible, y una barra fija que se oculta mientras se escribe.

En segundo lugar, la cobertura débil. Si la conexión se corta al enviar, se pierde el texto que alguien acaba de teclear con esfuerzo. Por eso conservamos los datos del formulario hasta que el envío queda confirmado e informamos de forma comprensible si el envío falla. El aviso “También puede llamarnos directamente” debe ir junto al mensaje de error, no en el pie de página.

En tercer lugar, los avisos de cookies y las ventanas emergentes. Un banner que cubre media pantalla tapa también el botón de llamada. Diseñamos la solicitud de consentimiento de forma discreta y hacemos que aparezca de modo que las vías de contacto sigan accesibles, en la medida en que lo permita la solución elegida. La valoración jurídica sigue siendo cuestión de la revisión de protección de datos, pero una mención de esta tensión debe figurar en el planteamiento.

En cuarto lugar, la interacción con la búsqueda local. Quien llega a la web desde el perfil de empresa de Google ya ha visto con frecuencia el horario y el número. La página debe mantener estos datos de forma coherente y no alargar el camino hacia la ruta o la llamada. Los horarios contradictorios entre el perfil y la web restan confianza y provocan llamadas en momentos poco oportunos.

Y, por último, la variedad de dispositivos. Un Android antiguo con poca memoria, un iPhone con letra grande en los ajustes del sistema, un dispositivo en modo oscuro: cada uno puede someter el diseño a una carga distinta. Por eso probamos con la fuente del sistema ampliada y con una conexión limitada, no solo con el dispositivo más nuevo en wifi.

Una mejor experiencia móvil no puede cuantificarse de forma general, y por eso no indicamos porcentajes. Lo realista es esperar que menos visitantes tropiecen con obstáculos: más toques en el botón de llamada, más formularios completados, menos abandonos en los campos de entrada. La magnitud del efecto depende de la situación de partida, de la oferta y de la demanda.

La medición se hace con eventos. Un clic en el enlace tel:, en el botón de WhatsApp y en el envío del formulario se registran como objetivos, separados por tipo de dispositivo. Quien utilice analítica web debería aclarar antes si para ello se necesita consentimiento y valorar soluciones respetuosas con los datos. Además, el informe de experiencia de Search Console muestra si las páginas alcanzan los umbrales de las Core Web Vitals.

Un clic en llamar no es lo mismo que una llamada. Quien toca el botón y cuelga lo ha pulsado, pero no ha conseguido nada. Por eso conviene contrastar con la empresa: ¿cuántas llamadas llegan realmente, cuántas se pierden y en qué horarios? A veces la mayor palanca no está en la web, sino en que por la noche nadie contesta.

Prevea varias semanas para la evaluación y, en oficios estacionales, también la comparación con el año anterior. Los días sueltos dicen poco, porque el tiempo, las vacaciones y las promociones desplazan el volumen. Lo que no puede prometerse: un número determinado de consultas o una mejor posición en la búsqueda. Mejorar la facilidad de uso crea condiciones, pero no controla la demanda en sí.

Primero: pruebe en dispositivos reales, no solo en el emulador del navegador. La vista de dispositivo de las herramientas de desarrollo muestra tamaños, pero no la sensación de las áreas táctiles, ni el comportamiento del teclado, ni la barra de gestos. De dos a tres dispositivos reales de distinta antigüedad y sistema operativo revelan la mayor parte de los fallos. Eso incluye una prueba en movimiento, con datos móviles en lugar de wifi.

Segundo: limite la conexión al probar. Lighthouse y PageSpeed Insights simulan una red móvil lenta y un dispositivo más débil. Los valores de laboratorio son solo una referencia; los datos de campo del informe de Search Console muestran la realidad. Si ambos difieren mucho, conviene revisar los scripts de terceros que no se cargan en el laboratorio pero cuestan tiempo a los visitantes reales.

Tercero: menos elementos, pero más grandes. Un menú con cuatro entradas claras supera a uno con nueve. Un botón rotulado “Llamar ahora” supera a un icono sin texto. Los contrastes deben poder leerse incluso a la luz del sol, porque un móvil al aire libre suele usarse en malas condiciones. Estas decisiones apenas cuestan dinero, pero hay que tomarlas.

Cuarto: mantenga la página pensando en el móvil. Las imágenes nuevas que suba un empleado deberían ajustarse automáticamente a un tamaño adecuado; de lo contrario, el tiempo de carga crece con cada actualización. Esto forma parte del flujo editorial, no solo de la creación. Basta una lista de comprobación sencilla tras cada cambio importante.

Si sus clientes llegan desde el móvil, la web móvil es su escaparate, no un añadido. Eso no significa que tenga que ser compleja. Una primera pantalla clara, un botón de llamada al alcance del pulgar, áreas táctiles suficientemente grandes, un formulario corto y una entrega ligera logran más que una profusión de animaciones y widgets que se atascan en el dispositivo.

Las mejoras son medibles, pero no pueden prometerse. Eliminan obstáculos en el camino hacia la consulta, pero no generan demanda. Quien lo sabe puede planificar con sobriedad: primero las vías de contacto, luego la velocidad, luego el pulido. Y quien tiene en cuenta el negocio reconoce que ni la mejor página sirve de nada si nadie contesta al teléfono.

Para situar el esfuerzo: en un sitio pequeño con pocas páginas, una revisión según este patrón es factible en un plazo razonable, porque se trata de prioridades y vías de contacto, no de contenidos nuevos. La cosa crece con muchas plantillas, software propio o conexiones con sistemas de citas. Indicamos el alcance tras una primera revisión, no antes.

El siguiente paso es pequeño. Coja su móvil, vaya a una sala con poca cobertura e intente contactar con su propia empresa. Cuente cuántos toques y cuántos segundos pasan hasta que suena el teléfono. Si va a trancas y barrancas, merece la pena echar un vistazo a la web. Con gusto lo revisamos juntos y le decimos con franqueza qué compensa.