Una app se juzga en los primeros segundos. Si el botón que buscás está donde no llega el pulgar, si un error te borra lo que escribiste o si cada pantalla parece hecha por una persona distinta, la cerrás y te olvidás de ella. Nadie necesita un curso para darse cuenta. Lo hacemos todos, todos los días, con apps que alguien diseñó con mucho cariño y poca paciencia para probarlas.
En esta nota junto lo que hay que tener en cuenta para diseñar la interfaz de una app. Empiezo por qué es y qué principios la ordenan, sigo con el proceso paso a paso y termino con varios detalles que muchas guías ni mencionan, como el alcance del pulgar o qué ve el usuario cuando todavía no hay datos. Al final cuento cómo se aplicó todo eso en dos proyectos reales.
Qué es la interfaz de una app
La interfaz (UI, por user interface) es lo que la persona ve y toca en la pantalla. Son los botones, los íconos, los textos, los menús, los formularios y la forma en que todo eso se acomoda.
La experiencia de usuario (UX) es más amplia. Incluye si la app resuelve lo que la persona necesita, cuántos pasos le lleva hacerlo y cómo se siente al terminar. Una forma simple de separarlas es pensar en un pago. La UX decide que alcanza con dos pasos y la UI decide cómo se ven esos dos pasos. Una interfaz preciosa sobre una experiencia mal pensada sigue siendo una app que no sirve, con mejor ropa.
Cinco principios que ordenan una interfaz
Hay muchas listas de principios de diseño. Estas cinco son las que más uso para revisar una pantalla antes de darla por buena.
1. Estructura
Lo que se relaciona va junto y lo que no, separado. Si en la pantalla de un pedido el total, el método de pago y el botón de pagar están en tres lugares distintos, el usuario tiene que armar el rompecabezas solo. Agrupar con espacio, con tarjetas o con títulos ayuda a entender la pantalla de un vistazo, antes de leer nada.
2. Simplicidad
Cada pantalla debería tener una tarea principal y un botón que se note más que el resto. Las palabras, las de todos los días. “Guardar” se entiende mejor que “Persistir cambios”, aunque el desarrollador sienta que pierde precisión. Simplificar se trata de decidir qué funciones se ven primero y cuáles pueden esperar en un segundo nivel, sin necesidad de sacar ninguna.
3. Visibilidad
Mostrá lo que la persona necesita en ese momento y nada más. Un registro que pide CUIT, fecha de nacimiento y color favorito antes de dejarte ver la app tiene muchas chances de perder gente en el camino. Lo que no hace falta ahora se puede pedir después, cuando ya hay confianza.
4. Consistencia
Si un botón azul confirma en una pantalla, no puede borrar en la siguiente. Los mismos componentes, colores, íconos y textos tienen que comportarse igual en toda la app, para que el usuario aprenda una vez y después navegue sin pensar.
Acá entra también la jerarquía visual, que usa tamaño, color, contraste y espacio en blanco para marcar qué es lo más importante de cada pantalla. Con dos o tres colores principales bien usados alcanza para casi cualquier app.
5. Tolerancia al error
La gente se equivoca, y la app tiene que estar preparada. Eso incluye poder deshacer después de borrar, pedir confirmación antes de una acción que no tiene vuelta, no perder lo escrito si se corta la conexión y aceptar un teléfono con o sin espacios. Un buen mensaje de error dice qué pasó y cómo arreglarlo, en lugar de un “Error 500” que solo entiende el servidor.
Cómo diseñar la interfaz de una app, paso a paso
El orden importa porque cada paso usa lo que salió del anterior. Saltearse los primeros para llegar rápido a los colores es la forma más segura de rediseñar todo dos veces.
1. Definir para qué sirve y para quién es
Antes de dibujar nada, escribí en dos o tres frases qué problema resuelve la app y quién la va a usar. Si la usa una entrenadora entre clase y clase o un contador sentado en su escritorio, cambia todo. Sumale qué apps parecidas existen, qué hacen bien y qué te molesta de ellas, y en qué plataformas va a funcionar (iOS, Android o una web app que se instala desde el navegador).
Algunos equipos arman fichas de “usuario tipo” con nombre, edad y hábitos. Sirven si salen de hablar con usuarios reales. Si salen de la imaginación del equipo, son literatura.
2. Dibujar los recorridos
Un recorrido es la secuencia de pantallas que sigue alguien para hacer una tarea, como registrarse, buscar algo o pagar. Conviene anotar las tareas principales y, para cada una, desde dónde entra la persona, qué pantallas atraviesa y dónde termina. En ese mapa aparecen los pasos que sobran y los callejones sin salida, que cuestan muy poco de corregir en papel y bastante más en código.
3. Hacer los wireframes
El wireframe es el plano de cada pantalla, en grises, sin colores ni fotos. Muestra dónde va cada cosa y qué peso tiene. Como todavía no hay diseño que defender, es el momento de probar dos o tres distribuciones distintas sin que nadie se enamore de un tono de verde. La diferencia con el mockup y el prototipo la expliqué en esta nota sobre wireframe, mockup y prototipo.
4. Armar el sistema de diseño
Acá se define la parte visual que se va a repetir en todas las pantallas. Los colores con su uso (cuál es para las acciones principales, cuál para las alertas), las tipografías con sus tamaños para títulos, texto y botones, los espaciados, los íconos de un mismo estilo y los componentes reutilizables, como botones, campos, tarjetas y barras de navegación.
En Figma esto se arma como una biblioteca de componentes y variables. Si mañana cambia el color de la marca, se cambia en un lugar y se actualiza en todas las pantallas. También le ahorra trabajo a quien programa, que puede pasar esos mismos valores al código.
5. Pasar a mockups y prototipo
Con los wireframes aprobados y el sistema de diseño listo, se aplica el diseño final a cada pantalla, que es el mockup. Después se conectan las pantallas entre sí para que se pueda tocar, avanzar y volver como en la app real, que es el prototipo. Hoy las dos cosas se hacen en la misma herramienta y muchas veces en paralelo.
Hay que diseñar pensando en varios tamaños de pantalla desde el principio. Un celular chico de 360 píxeles de ancho y uno grande de 430 no muestran lo mismo, y una tablet menos todavía.
6. Probar con gente real
Buscá cinco personas parecidas a quienes van a usar la app, dales el prototipo y pediles tareas concretas (registrarse, encontrar un producto, pagar). Después mirá sin ayudar, que es lo más difícil. Donde dudan, donde tocan algo que no es un botón o donde preguntan “¿y ahora?”, hay algo para corregir. Según una investigación clásica de Nielsen Norman Group, con cinco usuarios ya aparece la mayoría de los problemas de uso.
Revisá también lo básico. Si los botones se tocan sin errar, si el texto se lee al sol y si alguien se pierde en la navegación. Corregís y volvés a probar lo que cambiaste.
7. Ajustar y pasar a desarrollo
Con lo que salió de las pruebas se ajusta el diseño y se prepara la entrega, con pantallas finales, componentes, estados de cada elemento, medidas y textos definitivos. En Figma, el modo para desarrolladores deja ver medidas, colores y estilos sin tener que adivinar. Lo que no está especificado, el desarrollador lo inventa, y después nadie sabe por qué ese botón quedó distinto.
Detalles que muchas guías dejan afuera
Lo anterior es el proceso que encontrás en casi cualquier artículo. Estos puntos son los que después deciden cómo se usa la app todos los días.
El pulgar manda
Mucha gente usa el celular con una sola mano, y el pulgar llega cómodo a la parte de abajo y al centro de la pantalla. Arriba, y en especial en la esquina contraria, cuesta. Por eso las apps grandes ponen la navegación principal en una barra inferior y los botones importantes abajo. En esta nota sobre menús móviles hay varios ejemplos de sitios que lo resuelven así.
Zonas táctiles de tamaño real
Apple recomienda que cualquier elemento que se toque mida al menos 44 × 44 puntos, y Google pide 48 × 48 dp en Material Design. En la práctica es cerca de un centímetro. Un ícono puede verse más chico, pero el área que responde al toque tiene que tener ese tamaño, y los botones necesitan separación para no tocar el de al lado.
Contraste y texto que se agranda
El texto común necesita un contraste de al menos 4,5 a 1 con el fondo, según las pautas de accesibilidad WCAG (3 a 1 para textos grandes). El gris clarito sobre blanco queda elegante en la presentación y no se lee en la calle. Además, iOS y Android dejan que cada persona agrande la letra desde los ajustes. Si la app usa tamaños fijos, a esa persona se le rompe el diseño o directamente no puede leer.
Pantallas vacías, de carga y de error
Se diseña la pantalla llena de datos lindos y se olvida cómo se ve el primer día, cuando el usuario todavía no tiene nada. Una lista vacía debería explicar qué va a aparecer ahí y cómo empezar. Lo mismo pasa con la carga, donde un esqueleto de la pantalla tranquiliza más que una ruedita girando, y con los errores, que siempre necesitan una salida.
Modo oscuro
Muchas personas usan el celular en modo oscuro todo el día. Si la app no lo contempla, a las once de la noche se convierte en una linterna. Lo más práctico es definir los colores de los dos modos en el sistema de diseño desde el principio y revisar que el contraste funcione en ambos.
iOS y Android tienen costumbres distintas
Apple tiene sus Human Interface Guidelines y Google tiene Material Design. Coinciden en mucho, pero hay diferencias que el usuario nota en la forma de volver atrás (en Android existe el gesto o el botón del sistema), la ubicación de algunos controles y el estilo de los íconos. Una app puede tener identidad propia y respetar igual lo que la gente ya tiene en los dedos.
La velocidad también se diseña
Una animación de dos segundos entre pantallas se ve muy bien en el prototipo y desespera a la quinta vez. Las imágenes tienen que estar optimizadas y las transiciones ser cortas. Una app rápida perdona bastantes errores de diseño, y una lenta no perdona ninguno.
Dos ejemplos reales
La app de CuatroBé
Hace poco armamos para CuatroBé, una web de clases de fuerza online, una web app que cada alumna instala en el celular desde el navegador. Varias de las ideas de esta nota están ahí.
- Tiene pocas pantallas principales (Hoy, Clases y Perfil), y Hoy muestra lo que la persona necesita al abrir la app, como su racha, las clases hechas y la clase que dejó por la mitad.
- El video de cada clase retoma donde quedó y, al terminar, una cuenta regresiva de seis segundos lleva a la siguiente, así nadie tiene que buscar qué sigue.
- En Clases hay un buscador por clase, ejercicio o músculo, y una sección Mi rutina con favoritos para no recorrer las 21 clases cada vez.
- Las instrucciones para instalar la app están en Perfil, donde las encuentra quien ya entró.
La plataforma de cursos de Campus & Science
Campus & Science es una academia online de odontología neuromuscular. Se entra desde el navegador, como a cualquier web, pero una vez adentro funciona como una aplicación de cursos, con cuenta propia, avance guardado y certificados. Esa parte se diseñó con las mismas reglas que una app.
- Mi cuenta tiene tres secciones propias (Mis cursos, Ateneos y Membresía) y cada profesional ve solo el contenido que le corresponde, según sea del equipo, haya comprado el curso o tenga un plan Básico o Premium.
- Cada clase se marca como completada y la plataforma propone seguir por la primera que falta, así nadie tiene que acordarse dónde dejó.
- Las preguntas se hacen dentro de la misma clase y, cuando el docente responde, al alumno le llega un aviso por mail.
- En Mis cursos, cada curso es una tarjeta con su avance, y al completarlo aparece el certificado con código propio para verlo y descargarlo.
- Si el alumno todavía no tiene un plan pago, ve un aviso para sumarse en el mismo lugar donde están sus cursos, sin tener que buscar la página de precios.
Herramientas para diseñar la interfaz
Figma es hoy la herramienta estándar para todo el proceso, desde el wireframe hasta el prototipo y la entrega a desarrollo, y suma funciones con IA para armar primeros borradores de pantallas. Sketch sigue vigente entre quienes trabajan en Mac, y ProtoPie sirve para prototipos con interacciones más complejas.
Con IA también se puede pasar de una descripción a un prototipo navegable en minutos. Sirve para discutir una idea con el cliente, siempre que después alguien revise lo que salió con todo lo que cuenta esta nota.
Muchas guías todavía recomiendan Adobe XD e InVision. Adobe dejó de invertir en XD y lo mantiene sin novedades, e InVision cerró sus servicios a fines de 2024. Esta nota se revisó en octubre de 2026.
Preguntas frecuentes
¿Cuál es la diferencia entre UI y UX?
La UI es lo que se ve y se toca en la pantalla. La UX es la experiencia completa, que incluye si la app resuelve el problema y cuánto esfuerzo le pide a la persona.
¿Por dónde conviene empezar?
Por definir para qué sirve la app y quién la va a usar, y después por los recorridos. Los colores y las tipografías vienen bastante más tarde.
¿Qué tamaño tienen que tener los botones en el celular?
Al menos 44 × 44 puntos en iOS y 48 × 48 dp en Android, cerca de un centímetro. El área que responde al toque puede ser más grande que el ícono que se ve.
¿Hay que diseñar distinto para iOS y Android?
Alcanza con una sola app que respete algunas costumbres de cada plataforma, por ejemplo la forma de volver atrás y la ubicación de ciertos controles.
¿Con cuántas personas hay que probar el diseño?
Con cinco usuarios parecidos al público real ya aparece la mayoría de los problemas de uso. Después se corrige y se vuelve a probar con otras cinco.
Si tenés una app en mente, o una que ya existe y nadie termina de entender, en Aplicaciones y plataformas a medida cuento cómo la trabajo.


