Por qué “Mobile First” no basta en contextos humanitarios

Introducción

Un servicio puede estar diseñado con un enfoque mobile-first y aun así fallar en un teléfono.

Imagina que una organización está probando un nuevo servicio digital en un smartphone. El layout se adapta correctamente, la navegación cabe en un viewport más pequeño, los botones tienen un tamaño adecuado para tocarse y la jerarquía del contenido sobrevive al paso de desktop a mobile. Desde la perspectiva del responsive design, el producto funciona como se esperaba.

Ahora cambia las condiciones sin cambiar el tamaño de pantalla. La conexión desaparece después de cargar la primera página. El teléfono tiene varios años y tiene dificultades con un bundle grande de JavaScript. La persona está administrando cuidadosamente sus datos móviles. La batería está baja y quizá no haya un lugar fiable donde cargar el dispositivo más tarde. El teléfono pertenece a una familia y no a una sola persona, y el servicio se está utilizando en un segundo o tercer idioma. A mitad de un formulario largo, una petición falla y toda la información introducida desaparece.

El viewport sigue siendo móvil. Casi todo lo que determina si el servicio es realmente utilizable ha cambiado.

Por eso el diseño mobile-first en contextos humanitarios necesita un marco más amplio que el responsive layout por sí solo. Mobile-first resolvió un problema importante al obligar a los equipos a dejar de tratar las pantallas pequeñas como una consideración secundaria. Sin embargo, en contextos humanitarios, de desarrollo y de interés público, el tamaño de pantalla suele ser solo una de varias restricciones que interactúan entre sí: conectividad, hardware, coste de los datos, acceso a electricidad, idioma, alfabetización, discapacidad, privacidad, condiciones ambientales y si el dispositivo es personal o compartido.

UNHCR describe directamente muchas de estas barreras en su trabajo sobre inclusión digital, entre ellas la energía poco fiable, una cobertura celular deficiente, velocidades de conexión limitadas, el coste y la disponibilidad del hardware y los servicios, la alfabetización digital, el idioma y la disponibilidad de contenido accesible. La implicación para los equipos de producto es importante. Diseñar para un teléfono no significa necesariamente diseñar para las condiciones en las que ese teléfono será utilizado.

Una pregunta más útil no es simplemente si la experiencia cabe en mobile, sino qué sigue siendo utilizable cuando las condiciones alrededor de la pantalla dejan de ser ideales.

Mobile first resolvió un problema importante

Mobile-first surgió como respuesta a un problema real del diseño digital. Durante años, las interfaces de desktop fueron tratadas como el producto principal y las experiencias móviles se creaban después comprimiendo, ocultando o reorganizando aquello que ya se había diseñado para una pantalla más grande.

Empezar por el viewport más pequeño obligó a los equipos a tomar decisiones más difíciles desde el principio. El contenido tuvo que priorizarse. La navegación tuvo que ser más deliberada. Los touch targets pasaron a importar. Los layouts densos tuvieron que justificarse. La experiencia móvil dejó de poder tratarse como una copia reducida de la versión de desktop.

Esas lecciones siguen siendo útiles, especialmente en contextos donde el teléfono puede ser la principal o incluso la única forma práctica de acceder a un servicio digital. El trabajo reciente de UNHCR sobre soluciones móviles y offline-first refleja esta realidad al describir explícitamente el diseño mobile-first para smartphones de gama baja como una combinación de interfaces ligeras, uso mínimo de datos, compatibilidad con dispositivos antiguos e interacción adecuada para pantallas pequeñas y touch.

La limitación aparece cuando la palabra mobile empieza a utilizarse como sustituto de todas las demás condiciones que una persona puede enfrentar.

Un smartphone de gama alta con conexión estable, mucho almacenamiento, datos ilimitados, batería completa y un único propietario es un dispositivo móvil. También lo es un teléfono antiguo con poca memoria disponible, conexión intermitente, datos caros, batería degradada y varias personas dependiendo de él. Ambos pueden tener un viewport parecido. No ofrecen el mismo entorno operativo.

El responsive design puede adaptar una interfaz a sus pantallas. Por sí solo, no puede tener en cuenta todo lo demás que determina si el servicio puede alcanzarse y completarse.

Pero el tamaño de pantalla no es la única restricción

En productos humanitarios, las restricciones rara vez aparecen de una en una. Una conectividad deficiente puede combinarse con hardware limitado. Una descarga larga se vuelve más relevante cuando los datos son caros. Un proceso que asume atención continua se vuelve más difícil cuando el teléfono es compartido o la persona solo dispone de él durante un periodo corto. Las barreras de accesibilidad pueden agravar todas estas condiciones en lugar de existir de forma aislada.

Por eso el contexto de uso debe tratarse como parte del problema de diseño, no como una colección de edge cases que se resuelven más tarde.

Conectividad

“Internet lento” suele ser una descripción demasiado simple del problema. Una conexión puede estar disponible, desaparecer durante varios minutos, regresar con alta latencia, perder paquetes o cambiar repetidamente entre redes. Una persona puede comenzar una tarea online y terminarla en un estado de conectividad completamente distinto.

Esa diferencia importa porque un producto que simplemente es lento se comporta de manera distinta a uno que genera incertidumbre. Cuando una petición tarda veinte segundos y luego falla, la persona puede no saber si la información fue enviada. Cuando la interfaz parece congelarse durante un cambio de red, repetir una acción puede crear un duplicado. Si el contenido esencial solo existe después de una nueva petición, una conexión que desaparece en el momento equivocado puede hacer que el servicio sea, en la práctica, inaccesible.

UNHCR ha tratado cada vez más mobile-first y offline-first como principios complementarios y no como alternativas. En la orientación de su Digital Innovation Fund, mobile-first aborda dispositivos de gama baja, interfaces ligeras y uso mínimo de datos, mientras que offline-first plantea que el contenido y la funcionalidad esenciales permanezcan disponibles sin una conexión constante y se sincronicen cuando la conectividad regrese.

No todos los servicios necesitan funcionar completamente offline. El principio es más útil que eso: los equipos deberían identificar qué partes de la experiencia requieren realmente una conexión activa y cuáles no.

El mismo tamaño de pantalla puede ocultar condiciones de uso muy distintas. Diseñar para mobile no significa automáticamente diseñar para las restricciones de red, dispositivo, energía, privacidad o acceso que existen alrededor.

Capacidad del dispositivo

El ancho del viewport nos dice sorprendentemente poco sobre el dispositivo que está renderizando la página.

Dos teléfonos con dimensiones parecidas pueden diferir sustancialmente en velocidad de procesador, memoria disponible, almacenamiento, soporte del navegador, estado de la batería y antigüedad del sistema operativo. Un responsive layout puede encajar perfectamente en ambas pantallas mientras la aplicación se comporta de forma muy distinta en cada dispositivo.

Esto es especialmente relevante cuando los equipos confunden simplicidad visual con ligereza técnica. Una interfaz limpia puede seguir dependiendo de un bundle grande de JavaScript, varias web fonts, media de alta resolución, renderizado costoso en cliente y peticiones en segundo plano que la persona nunca ve. El responsive design no elimina esas dependencias.

Para servicios destinados a poblaciones amplias, probar solo en hardware flagship actual crea una imagen distorsionada del rendimiento. La pregunta útil no es simplemente si una página puede ejecutarse en un dispositivo de gama baja, sino si las tareas esenciales siguen siendo lo suficientemente responsivas como para completarse sin esperas excesivas, crashes o consumo desproporcionado de recursos.

Coste de los datos

Las conversaciones sobre performance suelen presentar el peso de una página como una cuestión de comodidad: menos bytes significan una experiencia más rápida. Sin embargo, en algunos contextos esos bytes también forman parte del coste de acceder al servicio.

Eso cambia la importancia de decisiones de implementación aparentemente pequeñas. Un vídeo con autoplay, varios archivos de fuentes, imágenes sobredimensionadas, peticiones analíticas repetidas o un bundle de JavaScript innecesariamente grande pueden consumir datos que la persona está pagando directamente. Un servicio puede estar técnicamente disponible y aun así resultar lo suficientemente caro como para que las personas limiten la frecuencia con la que lo utilizan.

Internet of Good Things de UNICEF ilustra otro enfoque. La plataforma fue diseñada para hacer información disponible tanto en teléfonos básicos como en smartphones y se ha ofrecido sin coste en muchos países mediante acuerdos con operadores móviles. La lección importante va más allá del zero-rating: el coste de llegar a la información forma parte del acceso.

Esto no significa reducir todas las interfaces a texto. Significa tratar el peso de red como una decisión de producto, especialmente cuando media o código no esenciales compiten con el contenido que las personas realmente vinieron a buscar.

Disponibilidad de energía

El diseño digital suele asumir que la electricidad es una infraestructura invisible. El dispositivo estará cargado antes de usarse, habrá otro enchufe disponible más tarde y el nivel de batería es una preocupación de la persona, no del producto.

Esa suposición no es universal. UNHCR identifica la falta de energía fiable y la dificultad para acceder a infraestructura digital entre las barreras que pueden impedir que personas desplazadas por la fuerza y apátridas participen plenamente en servicios digitales.

Cuando cargar un dispositivo deja de estar garantizado, el tiempo y la batería también se convierten en restricciones de diseño. Procesos largos que exigen mantener la pantalla activa, descargas repetidas después de sesiones fallidas, acceso constante a ubicación, animaciones pesadas o tareas que no pueden pausarse exigen más al dispositivo de lo que la interfaz por sí sola deja ver.

Un equipo de producto no necesita calcular el coste de batería de cada interacción para tomarse esto en serio. Puede empezar preguntándose si la tarea esencial exige tiempo innecesario, trabajo repetido o actividad continua que podría evitarse.

Idioma y alfabetización

Hacer que un servicio esté disponible en varios idiomas es importante, pero traducir no garantiza por sí solo comprensión.

Las personas pueden utilizar un servicio en un idioma que hablan pero no leen con fluidez. La terminología administrativa puede resultar desconocida incluso cuando cada palabra sea técnicamente correcta. Instrucciones escritas para profesionales pueden volverse difíciles de seguir cuando se trasladan sin cambios a una interfaz pública. La alfabetización digital también varía: interacciones que resultan obvias para un equipo de producto pueden depender de convenciones que una persona apenas ha tenido motivos para aprender.

La orientación de UNICEF sobre diseño para distintas realidades digitales recomienda tener en cuenta diferentes niveles de alfabetización digital y, cuando sea apropiado, utilizar audio o apoyo visual para personas con menor alfabetización. La precisión importante es cuando sea apropiado. El audio no es automáticamente más inclusivo, los pictogramas no se entienden universalmente y el vídeo puede introducir nuevos problemas de ancho de banda y accesibilidad. Estas decisiones necesitan validarse con las personas que realmente utilizarán el servicio.

El principio más profundo es reducir interpretación innecesaria. Lenguaje claro, acciones explícitas, mensajes de error útiles, conceptos familiares y una jerarquía que haga comprensible el siguiente paso pueden hacer que un servicio sea más resiliente incluso antes de considerar formatos adicionales.

Accesibilidad

La discapacidad no existe fuera de estas otras condiciones. Se cruza con ellas.

Una persona que utiliza tecnología de asistencia también puede estar usando un dispositivo antiguo. Alguien con baja visión puede estar enfrentándose a una pantalla poco luminosa al aire libre. Una persona que navega con teclado o switch input puede perder una tarea cuando la conexión falla. Alguien que depende de text-to-speech puede encontrar contenido en un idioma que no está bien soportado por el dispositivo disponible.

UNHCR incluye la disponibilidad limitada de contenido accesible para personas con discapacidad entre las barreras a la inclusión digital, mientras que el trabajo de UNICEF sobre soluciones digitales accesibles enfatiza diseñar con personas con discapacidad en lugar de tratar la accesibilidad como un ajuste técnico final.

Muchas de las prácticas que apoyan accesibilidad también mejoran la resiliencia de forma más amplia: HTML semántico, jerarquía clara, controles nativos, lenguaje comprensible, interacciones predecibles, estados visibles y menos dependencias innecesarias. Accesibilidad y resiliencia no son lo mismo, pero a menudo se refuerzan porque ambas cuestionan las suposiciones sobre un usuario ideal operando en condiciones ideales.

Privacidad y dispositivos compartidos

Una de las suposiciones más persistentes del diseño de producto digital se esconde dentro de una frase sencilla: tu teléfono.

Un dispositivo móvil no siempre es personal. Puede ser prestado, compartido dentro de un hogar, utilizado a través de un punto de acceso asistido o estar disponible para una persona solo durante periodos limitados. La orientación de UNICEF sobre inclusión digital llama explícitamente la atención sobre los dispositivos compartidos y los riesgos de privacidad que pueden generar.

Eso cambia la manera en que deberían evaluarse funciones aparentemente convenientes. Sesiones persistentes, notificaciones visibles, historial de formularios guardado, autofill, información sensible almacenada en caché o métodos de recuperación de cuenta pueden exponer información a la siguiente persona que utilice el dispositivo. Cerrar sesión puede necesitar ser mucho más evidente que en un producto diseñado alrededor de la propiedad privada del teléfono.

El acceso compartido también puede afectar el diseño de las tareas. Una persona puede necesitar detener un proceso a mitad porque otra necesita el teléfono, lo que convierte el guardado seguro y la posibilidad de reanudar en algo más que una comodidad.

La lección más amplia es que mobile-first no debería convertirse silenciosamente en personal-smartphone-first. La propiedad del dispositivo es otra condición que debe entenderse, no asumirse.

Diseñar para condiciones imperfectas

El flujo habitual de un producto se diseña alrededor del éxito. La página carga, la persona introduce información, la petición se completa y aparece la siguiente pantalla. Los estados de error suelen añadirse después como excepciones alrededor de ese camino ideal.

Los servicios resilientes tratan las condiciones degradadas como parte del espacio normal de diseño.

Eso no significa asumir que todo va a fallar. Significa decidir por adelantado qué debería ocurrir cuando algo falle. Si una petición se interrumpe, ¿puede conservarse la información introducida? Si la persona vuelve más tarde, ¿puede continuar donde lo dejó? Si no es posible obtener datos actuales, ¿puede la interfaz distinguir información previamente disponible de información en vivo? Si una imagen no esencial nunca carga, ¿la página sigue comunicando lo que importa?

La diferencia es importante porque un fallo en un flujo humanitario o de servicio público puede tener un coste mayor que una simple molestia. Volver a introducir una solicitud larga puede consumir más datos, más batería y más tiempo. Un estado de envío ambiguo puede hacer que una persona repita una petición o asuma incorrectamente que fue recibida. Un flujo que obliga a empezar de nuevo tras una interrupción puede ser especialmente difícil en un dispositivo compartido.

Por eso un producto resiliente intenta proteger la tarea antes que conservar cada enhancement. A medida que las condiciones empeoran, las funciones secundarias pueden desaparecer antes que la información esencial, la navegación, los datos introducidos y la acción principal.

Las experiencias resilientes no necesitan que cada enhancement sobreviva a todas las condiciones. Protegen la información y las acciones que las personas más necesitan.

Progressive enhancement vuelve a importar

Progressive enhancement se describe a veces como una filosofía antigua del desarrollo web, pero su idea central sigue siendo muy relevante para servicios modernos: comenzar con una base funcional y fiable, y añadir capacidades más ricas cuando el entorno pueda soportarlas.

En una página de contenido, esa base podría ser HTML semántico, enlaces significativos, texto legible y formularios que puedan enviarse mediante comportamiento convencional del navegador. JavaScript puede después mejorar transiciones, validación, gestión de estado o interacción sin convertirse en la única vía hacia la tarea subyacente.

En un servicio más parecido a una aplicación, el límite será distinto. Algunos flujos realmente necesitan funcionalidad en cliente. El objetivo no es obligar a todos los productos a usar una arquitectura sin JavaScript; es identificar qué se ha vuelto dependiente de JavaScript simplemente porque la implementación lo hizo conveniente.

Progressive enhancement crea una disciplina útil porque obliga al equipo de producto a distinguir entre capacidad esencial y enhancement. Cuando esas dos categorías se confunden, un fallo pequeño en la capa de enhancement puede hacer desaparecer todo el servicio.

Reduce la dependencia de JavaScript cuando sea posible

JavaScript no es el problema. La dependencia no cuestionada sí.

Los frameworks modernos permiten crear experiencias sofisticadas, rápidas y altamente interactivas, incluidas experiencias que pueden funcionar bien en entornos difíciles. Pero cada tarea crítica que depende completamente de que la ejecución del lado cliente funcione correctamente añade otra condición que debe cumplirse: el script debe descargarse, parsearse, ejecutarse, hidratar correctamente y seguir funcionando dentro de los recursos disponibles en el dispositivo.

Cuando esa cadena está justificada por la experiencia, puede ser un trade-off correcto. Cuando contenido esencial necesita un bundle grande únicamente para hacerse visible, o un formulario básico deja de funcionar porque falla la hydration, el producto ha hecho depender su función principal de condiciones que quizá no siempre existan.

La pregunta útil, por tanto, no es si un servicio humanitario debería usar JavaScript. Es qué debería dejar de funcionar cuando JavaScript deja de hacerlo.

Para muchos productos, la respuesta no debería ser “todo”.

Server rendering, enlaces convencionales, comportamiento nativo del navegador, code splitting cuidadoso, scripts de terceros limitados y menos dependencias del lado cliente pueden ampliar el número de condiciones bajo las cuales la experiencia esencial sigue estando disponible. Las decisiones técnicas concretas variarán, pero el principio de diseño se mantiene: la complejidad debería justificar la dependencia que introduce.

Haz que el fallo sea comprensible

La resiliencia técnica es solo la mitad del problema. Las personas también necesitan entender en qué estado se encuentra el servicio.

Una conexión intermitente crea incertidumbre que una simple página de error no resuelve. ¿La petición falló antes de enviar algo o después de que el servidor la recibiera? ¿La información que aparece en pantalla está actualizada o viene de caché? ¿La aplicación guardó el formulario localmente? ¿Es seguro pulsar el botón de nuevo? ¿Hacerlo creará un duplicado?

“Something went wrong” no responde ninguna de esas preguntas.

Un estado de fallo útil explica qué ocurrió en términos sobre los que la persona pueda actuar, deja claro qué información se conservó y ofrece un siguiente paso realista. Si el sistema guardó las respuestas localmente, puede decirlo. Si no puede garantizar que un envío fue recibido, no debería dar a entender lo contrario. Si reintentar es seguro, la interfaz puede ofrecer esa vía de forma explícita. Si no puede hacerse nada hasta que vuelva la conectividad, esa limitación debería ser comprensible en lugar de esconderse detrás de un spinner indefinido.

Aquí también importa la honestidad del diseño de interfaz. Un mensaje tranquilizador que afirma más de lo que el sistema realmente sabe puede ser más perjudicial que una explicación precisa de la incertidumbre.

El fallo forma parte de la interfaz. Un servicio resiliente deja claro qué ocurrió, qué se conservó y qué puede hacer la persona a continuación.

Más allá de mobile-first: resilience-first

Mobile-first sigue siendo útil porque obliga a los equipos a diseñar deliberadamente para una superficie limitada en lugar de tratarla como una versión reducida de desktop. Lo que revelan los contextos humanitarios es que esa superficie es solo una parte de la restricción.

Un enfoque resilience-first pregunta qué ocurre con la experiencia esencial cuando las condiciones reales empeoran y diseña alrededor de la protección de esa tarea central. No asume que todos los productos deban funcionar completamente offline, eliminar imágenes, evitar JavaScript o reducirse a una interfaz básica. Tampoco es un eufemismo para ofrecer una experiencia de menor calidad a personas en contextos con menos recursos.

Es una forma de hacer visibles las dependencias.

Para un servicio, resiliencia puede significar hacer que información crítica esté disponible offline. Para otro, puede significar conservar un formulario parcialmente completado a través de una petición fallida. En otro contexto podría significar ofrecer una versión ligera, reducir descargas innecesarias, soportar un navegador antiguo, hacer que cerrar sesión sea inconfundible en un dispositivo compartido o reescribir instrucciones para que la tarea pueda entenderse sin vocabulario especializado.

El objetivo no es predecir todas las condiciones difíciles posibles. Es dejar de diseñar el entorno ideal como si fuera neutral.

Mobile-first ayudó a los equipos digitales a dejar de tratar desktop como el valor por defecto. Los servicios humanitarios y de interés público requieren otro cambio: conectividad estable, hardware moderno, datos baratos, electricidad fiable, propiedad privada del dispositivo, alfabetización fluida e interacción sin fricciones tampoco pueden tratarse como valores por defecto.

Diseñar para una pantalla más pequeña es útil. Diseñar para las condiciones en las que las personas realmente necesitan el servicio es más importante.

Esa es la diferencia entre mobile-first y resilience-first.