Diseño de app móvil: muchas descargas, casi nadie la abre dos veces
Caso real · App móvil de una empresa de servicios con instalaciones sostenidas y un uso real que se apagaba tras el primer día
Con una app móvil es fácil confundir descargas con adopción. La ficha en la tienda funciona, la gente instala, y sin embargo el uso real —el que sostiene el negocio— se apaga al segundo o tercer día. La app está; que sirva a alguien, no tanto.
Cuando eso pasa, el reflejo suele ser pedir más funciones o más notificaciones. Casi nunca es eso. En móvil, la adopción se juega en el primer minuto dentro y en si la app respeta cómo se usa un teléfono: gestos, pulgar, sesiones cortas, interrupciones. Una app que se comporta como una web metida en una pantalla pequeña se siente torpe, y lo torpe en el móvil se abandona rápido.
De dónde partíamos
«Tenemos una app, la gente la descarga y no la usa; se instala y no vuelve a abrirse.»
Una empresa de servicios con una app propia, instalaciones sanas y una caída de uso muy fuerte en los primeros días. Dentro, la app pedía crear cuenta y configurar cosas antes de dejar hacer nada útil, escondía la acción principal a dos o tres toques de distancia y usaba patrones de escritorio —menús densos, formularios largos— en una pantalla de teléfono. El que instalaba no llegaba a ver para qué le servía.
La app se había desarrollado con prisa por estar en las tiendas. El encargo fue llevar al teléfono lo que ya hacía la web, con las mismas pantallas y el mismo orden. Y el éxito se midió desde el primer día en descargas, que era lo que reportaban las tiendas y lo que subía con cada campaña.
Lo que costaba una app que se instalaba y no se usaba
La factura de captación. Las campañas de descarga tenían un coste por instalación. Cuando la mayoría no volvía a abrir la app, ese coste se pagaba por usuarios que, en la práctica, no existían.
La factura de atención. Los clientes que no conseguían hacer una gestión en la app acababan llamando o escribiendo para resolverla. La app, pensada para descargar al equipo de atención, le estaba generando trabajo.
La factura de reputación. Las valoraciones en las tiendas hablaban de una app lenta de usar y difícil de entender. Esas reseñas eran lo primero que veía quien se planteaba descargarla, y frenaban las instalaciones que las campañas intentaban conseguir.
Lo que descartamos, y por qué
Más notificaciones push para «recordar» que abran. Perseguir con avisos a quien no ha visto el valor irrita y provoca desinstalaciones. Primero se da una razón para volver, luego —quizá— se recuerda.
Añadir funciones para que «enganche». Más funciones sobre un primer minuto roto es más sitio donde perderse en una pantalla más pequeña. El que no ve el valor básico no vuelve por una avanzada.
Reutilizar la interfaz de la web tal cual. Lo que funciona en escritorio no funciona con un pulgar. Copiar la web al móvil ahorra diseño y cuesta adopción.
Lo que buscábamos era una app que se sintiera hecha para el teléfono y que, en el primer minuto, dejara hacer lo que el cliente había venido a hacer.
La idea que decide el proyecto: en el móvil se diseña para el pulgar y para la interrupción
Una app se adopta cuando respeta cómo se usa un teléfono, no cuando reproduce lo que hace la web.
El uso móvil tiene rasgos propios que condicionan cada decisión de diseño. La app los ignoraba casi todos:
| Cómo se usa un teléfono | Qué exige al diseño | Qué hacía la app |
| Con una mano, a menudo de pie o en movimiento | Acciones principales al alcance del pulgar | Botón principal escondido y menú en la esquina superior |
| En sesiones cortas e interrumpidas | Poder retomar donde se dejó | Formularios largos que se perdían al salir |
| En una pantalla pequeña | Pocas opciones por pantalla, bien jerarquizadas | Menús densos copiados de la web |
| Con gestos ya aprendidos | Patrones del sistema que el usuario reconoce | Controles propios que nadie identificaba |
El método
Fase 1. Encontrar el primer valor y medir cuántos llegan
Se definió el momento en que la persona obtiene por primera vez algo útil dentro de la app y se midió cuánta gente lo alcanzaba en la primera sesión. Muy pocos: la mayoría se caía antes, en el registro y la configuración.
Fase 2. Quitar puertas antes del primer valor
Se rediseñó el arranque para llevar al primer valor cuanto antes: dejar probar antes de pedir cuenta, pedir lo justo, y guiar la primera vez que se hace la acción principal. Menos puertas antes del valor.
Es el mismo principio que aplicamos en el onboarding de cualquier producto digital [enlazar a /casos/onboarding-app-retencion-usuarios], con una diferencia propia del móvil: cada campo que se escribe con el teclado del teléfono pesa el doble. Lo que se podía deducir, como la ubicación o el tipo de cliente, dejó de preguntarse.
Fase 3. Patrones nativos y flujos clave
Se rehízo la navegación con patrones propios de móvil —acciones al alcance del pulgar, gestos, sesiones cortas que se retoman bien— y se priorizaron los dos o tres flujos que de verdad importan, en lugar de replicar todo el escritorio.
El menú lateral se sustituyó por una barra de navegación inferior (tab bar) con cuatro destinos, los que concentraban casi todo el uso. El resto de funciones pasó a un segundo nivel. Diseñar mobile first obligó a decidir qué era imprescindible, algo que la versión de escritorio nunca había tenido que hacer.
Fase 4. Prototipo validado y medición de retención
Se probó el nuevo flujo con usuarios reales en su propio teléfono antes de construirlo, y el éxito pasó a medirse en retención —cuánta gente vuelve y repite— en vez de en descargas.
Fase 5. Notificaciones con permiso y con motivo
El permiso para enviar notificaciones se dejó de pedir nada más abrir la app. Pasó a solicitarse después de que la persona completara su primera gestión, explicando qué tipo de avisos recibiría. Y solo se enviaron los que aportaban algo concreto, como el estado de un servicio contratado o un cambio que requería su atención.
Resultados
| Indicador | Antes → después |
| Usuarios que llegan al primer valor | de una minoría a la mayoría en la 1ª sesión |
| Retención a 7 días | subida marcada frente al punto de partida |
| Sesiones por usuario en la 1ª semana | claramente al alza |
No hizo falta una app más grande, sino una app que respetara el móvil y llevara antes al valor. En el teléfono la adopción no se compra con notificaciones ni con más pantallas: se gana consiguiendo que, el primer minuto, la persona vea para qué la instaló.
El equipo de atención notó el cambio. Las gestiones habituales se completaban en la app y bajaron las llamadas por trámites que antes se atascaban en el teléfono.
Las valoraciones en las tiendas cambiaron de tono. Las nuevas reseñas hablaban de rapidez y de facilidad, y esa mejora empezó a trabajar a favor de las descargas en lugar de en contra.
Datos ilustrativos de un caso real anonimizado. Tu punto de partida y tus cifras variarán según la app y el sector.
Por qué lo hacemos así
Muchas apps de empresa nacen como una copia de la web, con la idea de estar en el teléfono del cliente. Estar no basta: una app que no se usa ocupa espacio hasta que alguien la desinstala.
Por eso trabajamos con tres principios:
- Medir el éxito por uso repetido, no por descargas.
- Diseñar para el pulgar, las sesiones cortas y las interrupciones, con los patrones que el usuario ya conoce de su sistema.
- Pedir permisos y datos solo cuando la persona entiende para qué sirven.
Dónde no aplica: si tus clientes interactúan contigo una o dos veces al año, probablemente no necesiten una app, y una web móvil bien diseñada resolverá mejor sus gestiones. Y si la app depende de procesos internos que fallan, como pedidos que no se actualizan, el diseño no compensará lo que el servicio no cumple.
Preguntas frecuentes
¿Qué hay que tener en cuenta en el diseño de aplicaciones móviles?
Cómo se usa realmente un teléfono: con una mano, en sesiones cortas, con interrupciones y en una pantalla pequeña. Eso obliga a colocar las acciones principales al alcance del pulgar, limitar las opciones por pantalla, usar los patrones de navegación del sistema y permitir retomar una tarea donde se dejó. Y a priorizar los pocos flujos que de verdad importan en lugar de trasladar toda la web.
¿Por qué la gente descarga una app y no la usa?
Porque no llega a ver para qué le sirve en los primeros minutos. Las causas más habituales son pedir registro y configuración antes de dejar hacer nada útil, esconder la acción principal tras varios toques y usar patrones de escritorio que en el móvil resultan torpes. Insistir con notificaciones o añadir funciones no lo arregla: suele acelerar la desinstalación de la app.
¿Qué es el diseño mobile first?
Es un enfoque que diseña primero para la pantalla del teléfono y después adapta a pantallas mayores, en lugar de hacerlo al revés. Obliga a decidir qué contenidos y acciones son imprescindibles, porque en el móvil no cabe todo. El resultado suele ser una experiencia más clara también en escritorio, ya que parte de una jerarquía pensada para lo esencial.
¿Cuándo pedir permiso para enviar notificaciones push?
Después de que la persona haya obtenido algo útil de la app, no nada más abrirla. Pedir el permiso al principio, sin contexto, hace que muchos usuarios lo rechacen y ya no se pueda volver a pedir con facilidad. Funciona mejor solicitarlo en un momento relacionado, explicando qué avisos se enviarán, y limitar las notificaciones push a información que el usuario agradezca recibir.
¿Qué es la zona del pulgar en una app?
Es el área de la pantalla que se alcanza con comodidad usando el pulgar mientras se sujeta el teléfono con una mano, normalmente la parte inferior y central. Por eso las apps colocan ahí la navegación principal, con una barra inferior o tab bar, y los botones de las acciones más frecuentes. Situar lo importante en las esquinas superiores obliga a usar las dos manos.
¿Necesita mi empresa una app nativa o basta con la web?
Depende de con qué frecuencia te usan los clientes. Una app nativa tiene sentido cuando hay un uso recurrente, como consultar un servicio o hacer gestiones habituales, y cuando aprovecha funciones del teléfono como notificaciones o cámara. Si la relación es ocasional, una web bien diseñada para móvil suele ser mejor opción: no exige instalar nada y resuelve igual las gestiones puntuales.
¿Sabes cuántas de las personas que descargaron tu app el mes pasado la han vuelto a abrir esta semana? Si solo miras las descargas, no sabes si tienes una app o un icono.
Cuéntanos qué esperas que hagan tus clientes con la app y qué hacen hoy, y en la primera conversación sabremos dónde se pierden.
Otros casos de uso
Otros proyectos donde resolvimos el mismo tipo de problema.