Cómo diseñar una app móvil: el proceso completo

La mayoría de las guías para diseñar una app móvil se quedan en “haz wireframes y luego hazlo bonito”. Eso se salta justo lo que decide si una app funciona: quién la usa y dónde, qué pasa cuando se cae la red, si alguien con baja visión puede usarla y qué reglas de App Store y Google Play la rechazarán antes de que nadie la vea. Esta guía recorre el proceso completo tal como lo hacemos con nuestros clientes, desde la primera pregunta hasta el primer lanzamiento, con los estándares concretos de cada paso. Está escrita para fundadores y responsables de producto que están por encargar una app, y para diseñadores que quieren una lista de verificación que aguante una revisión.

Qué significa “bien diseñada” en una app móvil

El diseño no es la capa visual. Una app bien diseñada es aquella en la que la persona correcta termina la tarea para la que la abrió, rápido, sin ayuda y en las condiciones en las que realmente está. El acabado visual importa, pero llega al final y no puede rescatar un flujo que pide lo equivocado en el momento equivocado. Tres pruebas cubren casi todo:

• Útil: resuelve un problema que la gente ya tiene, lo bastante bien como para que vuelva.
• Usable: alguien que la abre por primera vez completa la tarea principal sin instrucciones.
• Adecuada a su contexto: funciona con una sola mano, bajo el sol, con una red lenta, con el texto grande activado y en el teléfono más pequeño que soportes.

Paso 1: Define el problema, las personas y el contexto de uso

Antes de que exista una sola pantalla, escribe la respuesta a estas preguntas. Si no puedes responder alguna, esa es la primera investigación que hay que hacer.

• ¿Qué tarea resuelve la app? Una frase. “El expositor escanea la credencial de un visitante y guarda el contacto” es una tarea; “una plataforma de eventos” no lo es.
• ¿Quién la usa y con qué frecuencia? Una herramienta que se usa cincuenta veces por turno se diseña distinto a una app que se abre una vez al mes.
• ¿Dónde y cómo? De pie o sentado, con una mano o con dos, con guantes, con ruido, con reflejos, con o sin conexión.
• ¿Qué usan hoy? Papel, una hoja de cálculo, un competidor. Tu app tiene que superar eso, no un ideal.
• ¿Cómo se ve el éxito en números? Tiempo para completar la tarea, errores, retención, ingresos. Elige los pocos que de verdad vas a medir.

El contexto cambia el diseño más que cualquier decisión de estilo. Cuando construimos Leak Survey Sidekick, los usuarios eran cuadrillas de mantenimiento que registraban fugas de aire comprimido mientras recorrían una planta ruidosa y llena de movimiento. Eso descartó formularios largos y controles pequeños, y pidió un registro rápido y visual, con captura que siguiera funcionando sin conexión. Para GTR Event Technology, las apps se usaban en pisos de ferias comerciales: miles de dispositivos en un mismo salón, Wi-Fi compartido, concreto y acero. Un diseño que diera por sentada una red confiable habría perdido los contactos de los expositores.

Métodos que funcionan en esta etapa: entrevistas cortas con cinco a diez usuarios reales, observar a alguien hacer la tarea hoy, leer las reseñas de la competencia en las tiendas buscando quejas que se repiten, y listar las restricciones que ya conoces (presupuesto, fecha de lanzamiento, regulaciones como las de datos de salud o financieros). El resultado es un brief de producto de una o dos páginas que todos aprueban.

Paso 2: Mapea los flujos antes de dibujar pantallas

Una pantalla es solo una parada en un recorrido, así que primero se diseñan los recorridos. Escribe la tarea principal como una secuencia de pasos (abrir la app, encontrar un proveedor, elegir un horario, confirmar, recibir un recordatorio) y pregunta, en cada paso, qué necesita ver el usuario y qué necesita decidir. De aquí salen dos cosas:

• Flujos de usuario para las tres a cinco tareas que más importan, incluidas las ramas: sin sesión iniciada, sin resultados, pago rechazado.
• Arquitectura de información: cuáles son las secciones principales y cómo se pasa de una a otra.

Para la navegación, ambas plataformas dan una guía clara. La barra de pestañas de Apple y la barra de navegación de Material Design de Google están pensadas para pocos destinos principales, normalmente de tres a cinco. Si necesitas más de cinco, casi siempre es señal de que hay que repensar la estructura, no de que falta una sexta pestaña. Mantén la acción más frecuente al alcance del pulgar: en los teléfonos grandes, las esquinas superiores quedan lejos cuando se usa con una mano, y por eso las acciones principales suelen vivir en la parte baja de la pantalla.

Paso 3: Wireframes, rápidos y feos a propósito

Los wireframes son cajas grises que muestran qué va dónde: contenido, jerarquía y acciones, sin color ni marca. Su valor es la velocidad. Puedes dibujar tres alternativas de un proceso de pago en una hora y descartar dos, algo imposible cuando una pantalla ya está pulida o programada. Papel y lápiz sirven; la mayoría de los equipos trabaja directamente en Figma, que también sirve para el prototipo del paso siguiente.

Un buen wireframe responde, para cada pantalla:

• ¿Para qué sirve esta pantalla, en una sola cosa?
• ¿Cuál es la acción principal, y es el elemento más visible?
• ¿Cómo se ve vacía, cargando, con un error y con mucho más contenido del esperado?
• ¿Cómo vuelve atrás el usuario?

Paso 4: Un prototipo navegable, probado con usuarios reales

Enlaza los wireframes (o los primeros diseños visuales) en un prototipo que la gente pueda recorrer tocando la pantalla de un teléfono. Luego pruébalo con personas que se parezcan a tus usuarios, no con tu propio equipo. Tu equipo sabe cómo debería funcionar la app y no puede olvidarlo.

No necesitas un laboratorio. La regla práctica de Jakob Nielsen, vigente desde hace años, es que unos cinco participantes por ronda revelan la mayoría de los problemas de usabilidad, y que varias rondas pequeñas con correcciones entre ellas rinden más que un solo estudio grande. Una sesión útil se ve así:

1. Da una tarea realista (“reserva una sesión para el martes que viene en la noche”), no un recorrido guiado.
2. Pide que piensen en voz alta y no los ayudes. Donde dudan, ahí está el hallazgo.
3. Anota si terminaron, cuánto tardaron y dónde se equivocaron.
4. Corrige los peores problemas y vuelve a probar con personas nuevas.

Este es el momento más barato del proyecto para equivocarse. Cambiar una pantalla en un prototipo cuesta minutos; cambiarla cuando ya está programada cuesta días, y después del lanzamiento cuesta un ciclo de revisión en las tiendas y los usuarios que se rindieron. Por eso ponemos el descubrimiento, los wireframes y un prototipo probado antes de cualquier código de producción en cada proyecto de app móvil.

Los errores de diseño más caros no son las pantallas feas. Son pantallas que se ven correctas para la tarea equivocada, descubiertas después del lanzamiento.

Paso 5: Diseño visual y un sistema de diseño

Solo ahora la interfaz recibe su apariencia: color, tipografía, iconos, imágenes y movimiento. Hazlo como un pequeño sistema de diseño y no pantalla por pantalla, para que la app se mantenga coherente a medida que crece y los ingenieros puedan construirla de forma predecible:

• Tokens de diseño: valores con nombre para colores, tamaños de texto, espaciado, radios de esquina y elevación, definidos una vez y usados en todas partes, incluidas las variantes del modo oscuro.
• Componentes: botones, campos, tarjetas, filas de lista, hojas y diálogos, cada uno con todos sus estados dibujados (normal, presionado, deshabilitado, con foco, con error, cargando).
• Reglas: cuándo usar cada componente, para que la décima pantalla no invente un cuarto tipo de botón.

Respeta la plataforma y después agrega tu marca

Los usuarios de iOS y de Android tienen expectativas distintas sobre la navegación, el botón de volver, la tipografía y los controles del sistema. Apple las publica en sus Human Interface Guidelines y Google en Material Design. Ambos sistemas cambiaron en 2025: Apple presentó su lenguaje de diseño Liquid Glass con iOS 26, y Google lanzó la actualización Material 3 Expressive. No tienes que copiar ninguno de los dos, pero donde tu app se aparte del comportamiento de la plataforma debe ser por una razón que el usuario sienta como una ventaja. Un código multiplataforma compartido, como Flutter, facilita un único diseño de marca; no elimina la necesidad de manejar la navegación hacia atrás, los diálogos del sistema y el escalado de texto de cada plataforma.

Planifica el modo oscuro desde el principio (ambas plataformas ofrecen un tema oscuro del sistema desde iOS 13 y Android 10) y prueba los colores en los dos temas. Agregar el modo oscuro a una paleta pensada solo para fondos blancos es un retrabajo común y evitable.

Paso 6: Diseña cada estado, no solo el camino feliz

Los mockups suelen mostrar el caso perfecto: sesión iniciada, red rápida, contenido ideal. El uso real está hecho sobre todo de los otros casos, y ahí es donde el usuario decide que una app está rota. Dibuja cada uno a propósito:

• Primer uso y estados vacíos: lo que alguien ve antes de tener datos, con un siguiente paso claro en vez de una pantalla en blanco.
• Carga: esqueletos o progreso que muestren la forma de lo que viene, y ningún indicador que bloquee toda la app por una actualización parcial.
• Errores: lenguaje claro que diga qué pasó y qué hacer, nunca un código de error crudo; conserva lo que el usuario escribió.
• Sin conexión y redes lentas: decide qué acciones funcionan sin conexión, ponlas en cola y muestra con claridad lo que todavía no se ha sincronizado.
• Permisos denegados: la app sigue funcionando de forma limitada y explica cómo activar el permiso más tarde.
• Extremos: nombres muy largos, textos traducidos mucho más largos que el inglés, números enormes, un elemento y mil elementos.

El comportamiento sin conexión es una decisión de diseño, no solo de ingeniería. En las apps de GTR, las pruebas revelaron un caso en que los datos capturados sin conexión se podían perder. Entregamos una caché sin conexión en menos de 72 horas: la app guarda primero en el dispositivo y sincroniza cuando vuelve la red, así que un escaneo cuenta aunque el Wi-Fi del lugar no coopere. El trabajo de diseño está en decidir qué ve el usuario mientras existe esa cola, para que confíe en que no se perdió nada.

La accesibilidad es un requisito, con números

Una app accesible es más fácil para todos: áreas táctiles más grandes, contraste legible y etiquetas claras ayudan tanto a quien está bajo el sol o con prisa como a una persona con discapacidad. Además, es cada vez más un requisito legal. La referencia más usada son las Pautas de Accesibilidad para el Contenido Web (WCAG) del W3C, que los reguladores aplican a las apps móviles igual que a los sitios web. La versión actual, WCAG 2.2, se publicó en octubre de 2023.

En lo legal: la Ley Europea de Accesibilidad se aplica desde el 28 de junio de 2025 a una serie de servicios para consumidores vendidos en la UE, entre ellos el comercio electrónico, los servicios bancarios y el transporte de pasajeros, y a sus apps (las empresas más pequeñas que prestan servicios están exentas). En Estados Unidos, el Departamento de Justicia adoptó en abril de 2024 el nivel WCAG 2.1 AA como estándar para los sitios web y las apps móviles de los gobiernos estatales y locales. Para las empresas privadas todavía no hay un único estándar técnico codificado, pero WCAG AA es la referencia a la que suelen apuntar los reclamos y acuerdos de accesibilidad. Diseñar con ella desde el inicio cuesta mucho menos que corregir después.

Reglas de las tiendas y privacidad que dan forma al diseño

Algunas decisiones de diseño las toman Apple y Google por ti, y pasarlas por alto hace que rechacen la app en la revisión. Las que más suelen afectar pantallas y flujos:

• Eliminación de la cuenta: desde junio de 2022, una app de iOS que permite crear una cuenta también debe permitir iniciar su eliminación desde dentro de la app. Google Play tiene un requisito similar y además pide un enlace web donde se pueda solicitar la eliminación sin reinstalar la app.
• Inicio de sesión con terceros: si ofreces entrar con un servicio como Google, la pauta 4.8 de Apple exige también una opción equivalente centrada en la privacidad, que en la práctica suele ser Iniciar sesión con Apple. Hay excepciones puntuales, como las apps empresariales que exigen una cuenta existente de la compañía.
• Permisos en contexto: pide la cámara, la ubicación o las notificaciones en el momento en que la función las necesita, con un texto que explique claramente para qué. Una cascada de solicitudes de permisos al abrir la app por primera vez suele terminar en rechazos, y un permiso rechazado es difícil de recuperar: en iOS la app no puede volver a mostrar la solicitud del sistema, y en Android solo puede pedirlo una vez más, así que después la persona tiene que buscar el permiso en Ajustes.
• Rastreo: en iOS, rastrear a los usuarios a través de apps y sitios web de otras empresas requiere la solicitud de Transparencia en el Rastreo de Apps de Apple.
• Declaraciones de privacidad: las etiquetas de privacidad de App Store y la sección de Seguridad de los datos de Google Play deben coincidir con lo que la app realmente recopila, así que diseño e ingeniería necesitan una sola lista acordada de datos.

Las categorías sensibles suben aún más la exigencia. En Zant, una app de salud mental, la privacidad fue un requisito de diseño desde la primera pantalla: qué se muestra en una notificación con el teléfono bloqueado, qué se pide al registrarse y qué no se recopila nunca.

Entrega a desarrollo y control de calidad del diseño

Un diseño está terminado cuando se construye correctamente, no cuando se aprueban los mockups. Una buena entrega le da a los ingenieros:

• El sistema de diseño (tokens y componentes) como fuente de verdad, idealmente reflejado uno a uno en el código.
• Cada pantalla con todos sus estados, más los flujos que las conectan.
• Especificaciones del comportamiento que un cuadro estático no muestra: animaciones, gestos, qué pasa al girar el teléfono, el comportamiento del teclado en los formularios.
• Los textos, finales o marcados claramente como provisionales, en cada idioma que vas a lanzar.

Después revisa la app construida en dispositivos reales, incluidos los teléfonos más pequeños y antiguos que soportas, con texto grande, en modo oscuro y con una conexión limitada. El control de calidad del diseño encuentra la distancia entre lo dibujado y lo construido mientras todavía es barato cerrarla.

Después del lanzamiento: mide y luego itera

El lanzamiento es la primera prueba real con todos los usuarios a la vez. Instrumenta los flujos principales para ver dónde abandona la gente, lee las reseñas de las tiendas y las solicitudes de soporte buscando temas que se repiten, y vigila los reportes de fallos. Luego vuelve al Paso 4 con la evidencia: prototipa la solución, pruébala con unos pocos usuarios y lánzala. Las apps que siguen mejorando después del lanzamiento lo hacen porque ese ciclo está planificado y presupuestado, no improvisado.

Errores comunes que vemos cuando tomamos una app

• Diseñar pantallas antes de acordar qué tarea resuelve la app y quién la hace.
• Probar solo con el equipo, o no probar hasta después del lanzamiento.
• Diseñar solo el camino feliz, de modo que los estados vacíos, de error y sin conexión los inventa quien programa.
• Áreas táctiles y textos que no cumplen los mínimos de la plataforma, descubiertos cuando el primer usuario activa el texto grande.
• Solicitudes de permisos y muros de registro antes de que el usuario haya visto algún valor.
• Sin sistema de diseño, así que cada función nueva se aleja más de la anterior.
• Requisitos de las tiendas (eliminación de cuenta, opciones de inicio de sesión, etiquetas de privacidad) descubiertos en la revisión.

Una lista de verificación antes de construir

1. Un brief aprobado: la tarea, los usuarios, el contexto y los números de éxito.
2. Flujos para las tareas principales, incluidas las ramas que salen mal.
3. Wireframes de cada pantalla y de cada estado.
4. Un prototipo navegable probado con al menos una ronda de usuarios reales, y corregido.
5. Un sistema de diseño con tokens, componentes y temas claro y oscuro.
6. Accesibilidad revisada contra los números de arriba.
7. Requisitos de las tiendas y de privacidad reflejados en los flujos.
8. Un paquete de entrega y un plan de control de calidad del diseño en dispositivos reales.

Si estás planificando una app y quieres que llevemos este proceso por ti, desde el descubrimiento y un prototipo probado hasta un producto publicado, cuéntanos qué estás construyendo. También puedes ver las apps que hemos diseñado y lanzado, o leer Flutter vs React Native si estás eligiendo con qué construirla.