App Ibercaja
Proyecto conceptual de rediseño UI/UX para la aplicación móvil de Ibercaja, centrado en modernizar la experiencia visual y mejorar la organización de la información financiera dentro de la app.
La propuesta replantea la interfaz actual mediante una navegación más clara, una jerarquía visual más sólida y una experiencia más adaptada a hábitos digitales modernos, manteniendo accesibilidad y facilidad de uso como pilares principales.
UX/UI Designer — análisis heurístico, arquitectura de información, UI y sistema de diseño
3 semanas
Proyecto individual, conceptual y no comisionado
Análisis heurístico · Arquitectura de información · Flujos · Wireframes · Sistema de diseño · Prototipo de alta fidelidad
El problema
Desde el usuario
Una app bancaria no se usa por gusto: se usa para resolver algo concreto y salir. La gran mayoría de las sesiones se reducen a dos tareas —consultar el saldo y revisar los últimos movimientos— y todo lo demás compite por un espacio que esas dos necesitan.
El problema aparece cuando la app se organiza según la estructura de productos del banco (cuentas, tarjetas, préstamos, inversión, seguros) en lugar de según lo que el usuario viene a hacer. Entonces la tarea más frecuente queda a varios toques de distancia, escondida detrás de una jerarquía que tiene sentido interno pero no de uso.
Y hay un segundo perfil que se suele diseñar como excepción cuando en realidad es central: la persona mayor o con poca soltura digital, que en muchos municipios ya no tiene oficina cerca y para la que la app dejó de ser una comodidad para convertirse en el único canal. Para ese usuario, un texto pequeño o un flujo con un paso ambiguo no es una molestia: es quedarse fuera.
Desde el negocio
Para un banco con fuerte implantación territorial, la app no es un canal más: a medida que se reduce la red de oficinas, se convierte en el punto de contacto principal con el cliente. Eso cambia lo que se le exige.
Una app que resuelve mal la consulta cotidiana genera dos costes directos: llamadas al servicio de atención por cosas que la interfaz debería resolver sola, y desgaste de confianza en el canal justo en el momento en que el banco necesita que los clientes lo adopten.
El objetivo del rediseño era reducir el coste de la tarea frecuente sin sacrificar la sensación de control y seguridad que hace que alguien confíe su dinero a una pantalla, y hacerlo sin dejar fuera al perfil menos digitalizado.
Restricciones del proyecto
- Proyecto conceptual: sin acceso a analítica, a usuarios reales del banco ni al contexto interno del producto
- Autenticación reforzada obligatoria por normativa: puede hacerse más fluida, nunca eliminarse
- Operaciones irreversibles: el diseño debe prevenir el error, no corregirlo
- Sector regulado: los cambios no pueden comprometer requisitos legales ni de seguridad
- Base de usuarios muy heterogénea en edad y soltura digital, sin posibilidad de segmentar la app
Necesidades del cliente
Mejorar jerarquía y claridad visual
La aplicación actual presenta una gran cantidad de información distribuida de forma poco visual, dificultando identificar rápidamente acciones, movimientos y datos importantes.
Modernizar experiencia y navegación
Era necesario actualizar la interfaz hacia un sistema más limpio, intuitivo y adaptado a estándares actuales de diseño mobile.
Priorizar acciones frecuentes
Reorganizar funciones como transferencias, Bizum, movimientos y gestión de cuentas para reducir fricción y mejorar rapidez de uso en tareas cotidianas.
La decisión difícil
La decisión más difícil fue especializar la pantalla de inicio en una sola tarea.
Un banco tiene interés legítimo en dar visibilidad a productos que generan negocio —inversión, seguros, financiación— y el inicio es el espacio más valioso para hacerlo. Quitarles protagonismo va en contra de ese interés.
Prioricé la tarea mayoritaria. Un inicio que sirve a todos los productos por igual no sirve bien a ninguno, y obliga al usuario a pagar un coste de navegación en cada sesión para que el banco gane visibilidad en unas pocas. La contrapartida es real y no la escondo: los productos secundarios pierden exposición directa.
Es el tipo de decisión que en un proyecto real habría que defender con datos de uso, y no los tengo. Lo que sí puedo defender es el criterio: optimizar para la frecuencia y no para el catálogo.
Sistema visual
Estados contemplados
Muestra el último saldo conocido con marca de hora explícita, en lugar de una pantalla vacía o un dato que pueda parecer actual
Permite ocultar el importe de un toque, para consultar la app en público sin exponerlo
Indica exactamente qué campo falla y conserva el resto de datos introducidos
Aviso explícito en la confirmación antes de completar la operación
Estructura del contenido con placeholders, manteniendo estable la posición de los elementos
Devuelve al punto donde estaba tras autenticarse, sin perder lo introducido
Accesibilidad
- Contraste verificado contra WCAG AA en toda la interfaz, incluidos estados de error y elementos sobre color.
- Modo simplificado con escala tipográfica ampliada y áreas táctiles mayores, activable sin etiquetas asociadas a la edad.
- Áreas táctiles de 44px mínimo en toda la app, pensadas para uso con una mano y con menos precisión.
- Los estados nunca dependen solo del color: error y confirmación llevan icono y texto.
- Etiquetas descriptivas en todos los elementos interactivos para lectores de pantalla.
- Soporte del tamaño de texto configurado en el sistema operativo, sin romper el layout.
- Jerarquía de encabezados coherente para permitir navegación por secciones.
Resultado
Es un proyecto conceptual y no comisionado: no hay datos de producción, ni acceso a la analítica real de la aplicación, ni al contexto interno que explica por qué la app actual toma las decisiones que toma. Conviene decirlo antes que después.
Lo que el rediseño sí resuelve, y puede contrastarse sobre el prototipo:
- La consulta de saldo y movimientos pasa de requerir navegación intermedia a estar disponible al abrir.
- La confirmación de transferencia jerarquiza el dato crítico y avisa ante destinatarios nuevos, actuando sobre el error antes de que ocurra.
- El modo simplificado hace la app utilizable para un perfil que, en zonas sin oficina, no tiene canal alternativo.
- Toda la interfaz cumple contraste AA y áreas táctiles accesibles.
Si esto se llevara a producción, las métricas a vigilar serían el tiempo hasta completar la consulta de saldo, la tasa de abandono en el flujo de transferencia y el volumen de llamadas a atención al cliente por operaciones que la interfaz debería resolver sola.
Del diseño al desarrollo
Definí un sistema con tokens de color, tipografía y espaciado, y componentes con todos sus estados (normal, pulsado, foco, deshabilitado, error, carga). El modo simplificado no es un diseño paralelo: se resuelve con los mismos componentes y una escala tipográfica y de espaciado alternativa, de modo que mantenerlo no duplica el trabajo del equipo.
El contraste se verificó contra WCAG AA en todas las combinaciones, incluidos los estados de error y los elementos sobre fondos de color. Las especificaciones incluyen comportamiento responsive, orden de foco y mensajes de error, porque en un flujo de pago esos detalles no son acabado: son parte de la función.
Qué aprendí
El mayor aprendizaje fue sobre los límites del propio ejercicio. Rediseñar un producto real sin acceso a sus datos ni a su contexto interno significa que muchas de las decisiones que parecen mejorables desde fuera responden a restricciones que no ves: normativa, sistemas heredados, acuerdos comerciales. Empecé el proyecto asumiendo que lo que no entendía estaba mal diseñado, y terminé con una idea bastante más humilde de lo que se puede afirmar desde fuera.
Eso cambió el enfoque a mitad de camino: dejé de intentar «arreglar la app» y pasé a defender decisiones concretas con el criterio que sí podía sostener —frecuencia de uso, prevención del error, accesibilidad— reconociendo lo que quedaba fuera de mi alcance.
Si lo repitiera, dedicaría el tiempo inicial a acotar el alcance a dos flujos concretos en lugar de abordar la app entera. Habría profundizado más y habría evitado la tentación de opinar sobre partes del producto que no estaba en condiciones de juzgar.
Love is not control
