Saltar al contenido
dumaloor.dev
~/academia
Fundamentos

Por qué se ve bien en el ordenador del diseñador y mal en el móvil de tu cliente

El diseño se aprueba en una pantalla grande y se consume en uno de gama media con el dedo. Ahí es donde se cae casi todo.

7 min de lecturaresponsivemovildisenoaccesibilidad

Quien aprueba el diseño trabaja delante de un monitor de oficina, con un ratón que apunta con precisión a cualquier punto, mientras quien acaba usándolo sostiene un teléfono con una mano y toca la pantalla con un dedo que apunta mucho peor que un cursor. Los fallos que más se repiten son texto que se desborda del ancho de pantalla, botones demasiado pequeños para tocar, formularios que fuerzan un zoom automático que descoloca el resto de la página, y barras o botones fijos que terminan tapando justo lo que el usuario intentaba alcanzar. Corregir los cuatro es trabajo de horas, siempre que alguien los haya visto antes de dar la web por terminada, probando en varios anchos de pantalla concretos y no solo en el dispositivo de quien aprueba el proyecto. Esa comprobación se pide fijando anchos concretos —desde 320 píxeles hasta una pantalla de escritorio—, exigiendo ver el resultado en cada uno, y cualquiera puede pedirla sin saber nada de diseño.

Hay una discusión que se repite en casi cualquier negocio con web propia y que nunca llega a resolverse, porque los dos que la sostienen tienen razón. De un lado, quien avisa de que en el móvil la web se ve fatal. Del otro, quien la construyó y responde, desconcertado, que a él le funciona perfectamente. Ninguno de los dos exagera ni miente: están mirando dos pantallas distintas sin saberlo.

#El origen: se aprueba en una pantalla y se usa en otra

Un diseño de web casi siempre se enseña, se revisa y se aprueba en una pantalla de ordenador grande —muchas veces de 24 o 27 pulgadas, con mucho espacio de sobra y un ratón para apuntar con precisión a cualquier punto de la imagen—. Ese mismo diseño lo va a usar, en la inmensa mayoría de los casos, alguien con una pantalla de seis pulgadas, sujetando el teléfono con una mano y tocando con un dedo que no tiene la puntería de un cursor.

De esa diferencia de tamaño, que parece un matiz estético, sale casi todo lo que falla en una web que «en el ordenador se ve perfecta» y en el móvil resulta incómoda de usar: nadie miró, durante la aprobación, la pantalla en la que de verdad se iba a consumir.

Buscar un culpable no lleva a ninguna parte. El proceso habitual de revisión —una reunión, una pantalla compartida, un archivo de diseño abierto en un ordenador— ocurre casi siempre en el formato más cómodo para enseñar y discutir, que es también el que peor representa cómo se va a consumir el resultado. Nadie decide, a propósito, aprobar algo que luego falla en móvil. Simplemente nadie mira, en ese momento, la pantalla donde de verdad va a fallar.

#Los cuatro fallos que más se repiten

Cuando una web falla en móvil, casi siempre es por alguna combinación de estos cuatro problemas, y los cuatro son fáciles de reconocer una vez que sabes qué buscar:

  • Texto que se sale de la pantalla. Un titular pensado para una línea larga en pantalla grande, al reducirse a un móvil estrecho, puede desbordar el ancho disponible y obligar a desplazar la página hacia los lados para leerlo entero. Es uno de los fallos más visibles y, a la vez, de los que menos se detecta si nadie prueba en un móvil real durante la revisión.
  • Botones demasiado pequeños para el dedo. Un botón que se pulsa con precisión de ratón puede resultar minúsculo al intentar tocarlo con un dedo, sobre todo si hay otro elemento pulsable justo al lado. El resultado es tocar el botón equivocado, o tener que ampliar la pantalla con los dedos para acertar, dos veces, en cada intento.
  • Formularios que obligan a hacer zoom. Un campo de texto pequeño, con una letra diminuta, hace que muchos teléfonos amplíen automáticamente la pantalla al tocarlo para que el usuario pueda ver lo que escribe. Ese zoom automático descoloca el resto del formulario, y es una de las razones más frecuentes por las que alguien abandona a mitad de rellenar un formulario de contacto o de compra.
  • Elementos fijos que tapan el contenido. Una barra de menú o un botón de contacto que se queda fijo en la parte superior o inferior de la pantalla mientras el usuario se desplaza puede terminar tapando justo la información o el botón que esa persona estaba intentando alcanzar, sobre todo en pantallas pequeñas donde el espacio libre ya es escaso de por sí.

Ninguno de los cuatro exige rehacer la web desde cero. Los cuatro exigen haberlos visto antes de dar la web por terminada.

#Por qué esto importa más de lo que parece

Para un negocio local —una tienda con web y local físico, un restaurante, una sala que vende entradas para sus eventos—, la mayoría de las visitas a su web llega desde el móvil, no desde un ordenador — el mismo canal donde, como se explica en el artículo sobre la velocidad de carga, cada segundo de espera de más también se traduce en gente que se va. Es la forma en la que la gente busca un horario, un teléfono o un producto mientras está en la calle, en el coche o en el sofá con el teléfono en la mano. Una web que falla en móvil no está fallando en un canal secundario: está fallando donde ocurre la mayor parte del contacto real con sus clientes.

Piensa en un restaurante con dos locales que recibe la reserva de una mesa desde el móvil de alguien que acaba de salir del trabajo y busca sitio para cenar esa misma noche. Si el formulario de reserva obliga a hacer zoom para rellenar el número de comensales, o el botón de confirmar queda tapado por la barra de navegación del teléfono, esa persona no va a luchar contra la web: va a cerrar la pestaña y va a reservar en el sitio de al lado, que tardó lo mismo en aparecer en la búsqueda y no le puso ninguna dificultad de por medio.

#Probar en el móvil del jefe no es probar en móvil

Hay una comprobación que parece suficiente y no lo es: abrir la web en el teléfono de quien manda, ver que se lee bien, y dar el visto bueno. El problema es que ese teléfono concreto —normalmente uno de gama alta, con una pantalla grande para lo que es un móvil y comprado hace poco— no representa al conjunto de dispositivos que usan los clientes reales de ese negocio, que incluye teléfonos más pequeños, más antiguos, con pantallas de proporciones distintas y con el dedo de cada persona pulsando de forma distinta a la de otra.

Una web puede verse perfecta en ese único teléfono de referencia y fallar en la franja de tamaños más pequeños, que es precisamente la que con más frecuencia queda sin revisar porque nadie tiene, a mano, uno de esos modelos para probar.

Esto se comprueba, no se opina

«Se ve bien en mi móvil» es una opinión sobre un único dispositivo. Comprobar el responsive de verdad no consiste en mirarlo con buena fe en el teléfono que cada uno tiene encima de la mesa: consiste en abrir la web ajustando el navegador a varios anchos concretos, uno por uno, y revisar en cada uno de ellos si el texto cabe, si los botones son fáciles de tocar y si nada queda tapado. Es un proceso de minutos, y es la única forma de saber si una web funciona en móvil en lugar de suponerlo.

#Cuatro anchos concretos, revisados uno por uno

Exigir esta comprobación no requiere entender de diseño. Requiere pedirla con anchuras concretas y reclamar que te enseñen el resultado en cada una, en vez de conformarte con un «sí, es responsive».

Pide que se compruebe, como mínimo, en estos cuatro anchos, que cubren desde el móvil más estrecho habitual hasta una pantalla de escritorio normal:

  1. 320 píxeles — el ancho de los móviles más compactos. Si el texto cabe y nada se desborda aquí, casi con seguridad cabe en cualquier móvil más grande.
  2. 375-390 píxeles — el ancho más habitual entre los móviles de gama media que usa la mayoría de tus clientes.
  3. 768 píxeles — el ancho típico de una tableta, o de un móvil grande en horizontal.
  4. 1024-1440 píxeles — el rango habitual de un ordenador portátil o de sobremesa normal, para confirmar que nada se ha roto por el camino en la dirección contraria.

Con esos cuatro anchos revisados, uno por uno, dejas de depender de si el teléfono de alguien concreto pasó la prueba por casualidad. Pasas a tener una comprobación real de que la web funciona para el rango completo de pantallas con las que tus clientes de verdad la van a abrir.

Preguntas frecuentes

¿Con qué frecuencia hay que repetir esta comprobación después del lanzamiento?

Cada vez que se publique un cambio visual relevante, no solo en el lanzamiento inicial: un rediseño de una sección, un formulario nuevo o un cambio de plantilla pueden introducir el mismo problema aunque el resto de la web siga funcionando bien en móvil. No hace falta repetir la revisión completa por cada cambio menor de texto.

Yo he probado la web en mi móvil y se ve perfectamente, ¿no es esa la prueba que necesito?

Es una prueba parcial, no la prueba completa: tu teléfono es un único modelo, probablemente de gama alta y comprado hace poco, y no representa el rango de pantallas que usan tus clientes reales. Pide que se compruebe en varios anchos concretos, no en un único dispositivo, por bien que se vea ahí.

¿Y si mi negocio recibe casi todas sus visitas desde ordenador y muy pocas desde móvil?

Aun así merece la pena revisar los distintos anchos de pantalla, aunque cambie la prioridad: si el grueso de tus visitas llega desde ordenador, un fallo en móvil pierde a la minoría de clientes que sí llega por ahí, en vez de perder a la mayoría. La comprobación es la misma; lo que cambia es cuánta urgencia le pones al resultado.

Seguir leyendo

¿Te ha sido útil?

¿Necesitas algo similar para tu negocio?

Construyo dashboards, pipelines y análisis a medida. Si quieres hablar, escríbeme.

Hablamos