Imaginbank: System-Level Redesign of a Mobile Banking Product
Rediseño de sistema de banca móvil centrado en un principio: el usuario nunca debe preguntarse "¿se ha movido mi dinero?". Máquina de estados, prevención de errores y trust design para operaciones financieras irreversibles.
Sobre el proyecto
Imaginbank es la app de banca móvil de CaixaBank para usuarios de 18-30 años. Este caso documenta un rediseño de sistema — no visual — de sus flujos financieros críticos. En banca móvil, un estado ambiguo no es un inconveniente de usabilidad: es pánico. Una transferencia sin confirmación no es mala UX: es riesgo financiero real.
El punto de partida: ¿por qué los usuarios cometen errores evitables y pierden confianza al operar con su dinero? Revolut y N26 habían redefinido el estándar de claridad financiera. Imaginbank necesitaba cerrar esa brecha con decisiones de producto — sistema de estados explícito, prevención estructural de errores, y feedback proporcional al riesgo de cada operación.
Tres fallos estructurales con coste financiero directo: (1) operaciones sin feedback — el usuario ejecutaba una transferencia y no sabía si estaba en proceso, completada o fallida; (2) nomenclatura inconsistente — "Transferir", "Enviar" y "Bizum" para la misma acción, multiplicando la carga cognitiva en flujos donde un error mueve dinero real; (3) errores sin recuperación — mensajes genéricos ("Ha ocurrido un error") sin causa, explicación ni ruta de resolución. Estos no son deuda de diseño — son vectores de pérdida de dinero, confianza y usuarios.
- El usuario ejecuta una transferencia y no sabe si se ha procesado, está pendiente o ha fallado — riesgo financiero directo
- Tres términos distintos para "enviar dinero" generan confusión cognitiva en flujos donde un error mueve dinero real
- Mensajes de error genéricos sin causa ni recuperación: en fintech, "Ha ocurrido un error" equivale a pánico del usuario
Solución propuesta
Rediseño desde la arquitectura de comportamiento, no desde la capa visual. Tres ejes: (1) máquina de 5 estados explícita para cada operación — idle, loading, pending, success, failure — sin estados silenciosos; (2) prevención estructural — validación en tiempo real, confirmación pre-ejecución obligatoria, bloqueo de doble acción; (3) jerarquía de datos orientada a la decisión — saldo disponible primero, pendientes segundo, contexto tercero. Criterio único de evaluación: ¿reduce el riesgo de que el usuario pierda dinero o confianza?
01. Overview
Un producto financiero donde cada fallo de diseño cuesta dinero
Imaginbank es la app de banca móvil de CaixaBank para usuarios de 18-30 años. Banco 100% móvil, sin sucursales. Su propuesta era competitiva en 2016. En 2021, Revolut, N26 y Bnext habían redefinido qué significa claridad financiera en una app — e Imaginbank se había quedado atrás. Este rediseño no es un proyecto visual. Es un análisis de sistema: dónde falla el producto cuando hay dinero real en juego, qué comportamientos generan riesgo para el usuario, y qué decisiones de diseño reducen ese riesgo de forma medible. El objetivo de producto es concreto: (1) los usuarios completan transferencias sin errores evitables, (2) el sistema nunca deja al usuario sin saber qué ha pasado con su dinero, (3) la confianza percibida aumenta — el usuario siente que controla su dinero, no que el banco lo controla por él. En fintech, cada fallo de claridad tiene un coste directo: dinero enviado al destinatario equivocado, llamadas a soporte, y usuarios que migran a competidores donde se sienten más seguros.
Insight Clave: En banca móvil, "mejorar la experiencia" no es un objetivo válido. El objetivo es: reducir el riesgo de error del usuario cuando opera con dinero real.
02. Problem Space
Tres categorías de fallo con impacto financiero directo
Antes de proponer soluciones, se mapearon los modos de fallo del sistema actual. En fintech, un fallo de diseño no es un inconveniente — es un riesgo financiero.
Errores del usuario: IBAN introducido incorrectamente sin validación en tiempo real. Confusión entre "Transferir", "Enviar" y "Bizum" — tres términos para la misma acción en diferentes pantallas. Imposibilidad de distinguir saldo disponible de saldo contable, que lleva a intentos de transferencia con fondos insuficientes.
Roturas de confianza: El usuario ejecuta una transferencia y no recibe confirmación — no sabe si se ha procesado, está pendiente o ha fallado. Los estados de carga muestran un spinner genérico sin contexto. Los mensajes de error dicen "Ha ocurrido un error" sin especificar qué, por qué, ni cómo resolverlo.
Fallos de sistema: Timeouts de red sin feedback — el usuario no sabe si la operación se ejecutó antes del corte de conexión. Inconsistencia entre el balance mostrado y las operaciones pendientes. Doble ejecución: el usuario toca "Enviar" dos veces porque no hubo feedback en el primer tap.
Estos problemas son críticos porque la ambigüedad en fintech es inaceptable. Si un usuario no sabe si su transferencia de 500€ se ha ejecutado, el coste no es frustración — es pánico.
Insight Clave: En fintech, cada estado ambiguo es un fallo de producto. El usuario nunca debería preguntarse: "¿se ha movido mi dinero?"
Nomenclatura inconsistente como vector de error financiero
Un modo de fallo merece análisis propio: la inconsistencia terminológica. La auditoría reveló que "enviar dinero" aparece con tres nombres según la sección: "Transferir", "Enviar" y "Bizum". Esto no es un problema de estilo — es un problema de seguridad cognitiva.
Cuando un usuario opera con dinero real, necesita certeza absoluta sobre qué acción está ejecutando. Si la misma operación cambia de nombre según el contexto, el usuario tiene que reaprender la interfaz en cada pantalla. En un flujo de transferencia, esa carga cognitiva adicional aumenta directamente la probabilidad de error.
El mismo problema se extiende a la iconografía (iconos distintos para la misma función) y a los patrones de interacción (botones en posiciones diferentes para acciones equivalentes). La inconsistencia no es deuda de diseño — es un multiplicador de riesgo.
03. Core User Tasks
Acciones de alto riesgo: definición de éxito seguro
Este rediseño se centra exclusivamente en tres flujos críticos — los que implican dinero real y donde un error tiene consecuencias irreversibles. Consultar saldo: Éxito seguro significa que el usuario ve su saldo disponible real (no contable) con operaciones pendientes claramente diferenciadas. Nunca debe haber ambigüedad entre "lo que tengo" y "lo que puedo gastar". El saldo se actualiza en tiempo real o muestra explícitamente cuándo fue la última sincronización. Enviar dinero: Éxito seguro significa que el usuario confirma destinatario, importe y concepto en una pantalla de resumen antes de ejecutar. El IBAN se valida en tiempo real durante la introducción. El sistema bloquea doble ejecución. Tras confirmar, el usuario recibe feedback inmediato del estado (procesando → completado / fallido) sin abandonar el contexto. Confirmar transacción: Éxito seguro significa que la pantalla de confirmación muestra todos los datos críticos sin scroll. El botón de confirmación requiere acción deliberada (no es accesible por gesto accidental). Tras la ejecución, el usuario recibe confirmación con número de referencia, timestamp, y opción de compartir recibo.
- Consultar saldo — El usuario distingue sin esfuerzo entre saldo disponible, saldo contable y operaciones pendientes. Cero ambigüedad
- Enviar dinero — Validación en tiempo real, resumen previo obligatorio, bloqueo de doble ejecución, feedback de estado inmediato
- Confirmar transacción — Datos críticos visibles sin scroll, acción deliberada requerida, confirmación con referencia y timestamp
Insight Clave: Cada tarea crítica tiene una definición de "éxito seguro" que no es negociable. Si el usuario puede completar la tarea sin errores y sin incertidumbre, el diseño funciona.
04. UX Principles
Restricciones de diseño, no aspiraciones
Estos principios no son aspiracionales — son restricciones de diseño. Cada decisión de producto se evalúa contra ellos. Si una propuesta viola un principio, se descarta.
- Claridad financiera sobre simplicidad visual — Si simplificar la interfaz implica ocultar información financiera relevante, no se simplifica. El usuario siempre ve lo que necesita para tomar una decisión segura, aunque la pantalla sea más densa
- Prevenir errores en lugar de corregirlos — El sistema valida en tiempo real, muestra confirmaciones antes de ejecutar, y bloquea acciones duplicadas. La corrección post-error es el último recurso, no la estrategia
- Comunicar siempre el estado del sistema — Cada operación financiera tiene exactamente 5 estados posibles: idle, loading, pending, success, failure. Ningún estado es silencioso. El usuario siempre sabe qué está pasando con su dinero
- Cero ambigüedad en transacciones — Un término para cada acción. Un patrón para cada interacción. Un formato para cada dato financiero. La consistencia no es estética, es seguridad cognitiva
- Feedback proporcional al riesgo — Las acciones de bajo riesgo (consultar movimientos) reciben feedback ligero. Las acciones de alto riesgo (enviar dinero) reciben confirmación explícita, resumen completo, y verificación de estado post-ejecución
05. System Thinking
Comportamiento del sistema, no diseño de pantallas
Este rediseño define cómo se comporta el sistema, no cómo se ve. La interfaz es una consecuencia del comportamiento.
Máquina de estados: Cada operación financiera tiene 5 estados explícitos y transiciones definidas. idle → loading (el usuario inicia acción; indicador de progreso con tiempo estimado, no spinner genérico). loading → pending (operación enviada al banco; referencia provisional visible, el usuario puede cerrar la app sin perder contexto). pending → success (confirmación del banco; recibo con referencia final, timestamp, importe exacto). pending → failure (rechazo del banco; razón específica + ruta de recuperación + confirmación explícita de que el dinero no se ha movido). No existe un sexto estado. No existe un estado silencioso. Si el sistema no puede determinar el estado, muestra el último estado conocido con timestamp y opción de verificación manual.
Bucles de feedback: Respuesta en <300ms a cualquier acción. Si la operación requiere más tiempo, progreso incremental. Si la conexión se pierde mid-operación, el sistema diferencia entre "operación enviada antes del corte" y "operación no enviada" — esta distinción es la más crítica del sistema, porque determina si el dinero se ha movido o no.
Jerarquía de datos: Información ordenada por criticidad para la decisión. Balance: saldo disponible → pendientes → historial. Transferencia: importe + destinatario → detalles secundarios. Principio: datos de decisión y datos informativos nunca comparten el mismo nivel jerárquico.
Insight Clave: Un producto financiero no es un conjunto de pantallas. Es un sistema de estados, transiciones y feedback. Si el sistema se comporta correctamente, la interfaz se diseña sola.
06. Key Design Decisions
Cada decisión implicó rechazar una alternativa
Cada decisión importante implicó rechazar una alternativa. Documentar el trade-off es tan importante como documentar la decisión.
- Confirmación obligatoria pre-transferencia — Problema: usuarios ejecutaban transferencias por error (tap accidental, datos incorrectos). Alternativa rechazada: cancelación post-ejecución (técnicamente complejo, ventana real de segundos). Trade-off: añade un paso al flujo (+1 pantalla). Decisión: el coste de un tap extra es trivial comparado con el coste de una transferencia errónea. La fricción deliberada es aceptable cuando protege dinero real
- Un solo término para "enviar dinero" — Problema: "Transferir", "Enviar" y "Bizum" generaban confusión. Alternativa rechazada: terminología diferenciada por método de pago (más preciso técnicamente). Trade-off: se pierde especificidad técnica. Decisión: el usuario selecciona "Enviar dinero" y el sistema presenta los métodos en un segundo paso. La claridad del usuario pesa más que la precisión del sistema
- Saldo disponible como dato primario, no saldo contable — Problema: usuarios intentaban gastar dinero que técnicamente tenían pero no estaba disponible. Alternativa rechazada: mostrar ambos saldos con igual prominencia. Trade-off: usuarios avanzados pierden visibilidad inmediata del saldo contable. Decisión: el 95% necesita saber "cuánto puedo gastar", no "cuánto tiene el banco registrado". El saldo contable se muestra un nivel abajo
- Bloqueo de doble ejecución con feedback explícito — Problema: usuarios tocaban "Confirmar" dos veces porque no recibían feedback del primer tap. Alternativa rechazada: debounce silencioso (ignorar segundo tap sin avisar). Trade-off: el usuario ve un mensaje "Operación en curso" que ocupa espacio. Decisión: el debounce silencioso resuelve el problema técnico pero no el de confianza. El usuario necesita saber que el sistema ha registrado su acción
07. Error Prevention & Edge Cases
Diseño explícito para fondos insuficientes, fallos de red y duplicados
Cada escenario de error está diseñado con tres capas: prevención (evitar que ocurra), comunicación (explicar qué ha pasado), y recuperación (guiar hacia la solución).
Fondos insuficientes: Prevención — el campo de importe muestra el saldo disponible en tiempo real; si el usuario introduce un importe superior, el campo se marca antes de intentar enviar. Comunicación — "No tienes saldo suficiente. Tu saldo disponible es [X]. ¿Quieres enviar [X] en su lugar?" Recuperación — opción de modificar el importe sin salir del flujo.
Transferencia fallida: Prevención — validación de IBAN en tiempo real con formato visual (agrupación de dígitos). Comunicación — mensaje específico: "La transferencia no se ha completado porque [razón concreta]. Tu dinero no se ha movido." Recuperación — botón de reintentar que mantiene todos los datos introducidos.
Doble acción: Prevención — tras el primer tap en "Confirmar", el botón se desactiva y muestra estado "Procesando...". Comunicación — si el usuario intenta interactuar, mensaje: "Tu operación se está procesando. Te confirmaremos en unos segundos." Recuperación — no aplicable; la prevención es total.
Conectividad: Prevención — el sistema detecta conexión inestable antes de iniciar la operación y advierte. Comunicación — "Se ha perdido la conexión. Tu operación [se envió / no se envió]. Referencia: [X]." Recuperación — pantalla de verificación de estado accesible desde el historial.
Insight Clave: La diferencia entre "Ha ocurrido un error" y "La transferencia no se ha completado porque el IBAN no existe. Tu dinero no se ha movido" es la diferencia entre pánico y control.
08. Trust Design
Cómo el producto construye confianza con acciones concretas
La confianza en un producto financiero no se declara — se demuestra en cada interacción. Tres mecanismos concretos:
Transparencia: Cada pantalla de confirmación muestra todos los datos de la operación sin truncar: importe exacto (con céntimos), nombre completo del destinatario (no solo iniciales), IBAN completo (no enmascarado parcialmente), comisiones desglosadas (si aplican), y fecha estimada de recepción. El usuario nunca confirma algo que no puede verificar completamente.
Predecibilidad: El sistema se comporta igual cada vez. El botón de confirmar está siempre en la misma posición. Los mensajes de estado usan siempre el mismo formato. Los colores de estado son consistentes (verde = completado, amarillo = pendiente, rojo = fallido). El usuario no tiene que "reaprender" la app cada vez que la abre.
Feedback inmediato y preciso: Tras cada acción, el sistema responde en menos de 300ms con información específica. No "Operación realizada" sino "Has enviado 150,00 EUR a María García. Referencia: TRF-2021-84729. Llegará antes del 15/03." El nivel de detalle en la confirmación es proporcional al riesgo de la operación.
Insight Clave: La confianza se construye con tres cosas: mostrar todo, comportarse siempre igual, y responder siempre rápido. No hay atajos.
09. Expected Outcomes
Resultados esperados: medibles y realistas
Estos no son objetivos aspiracionales. Son mejoras esperadas basadas en los fallos documentados y las soluciones propuestas, con mecanismos de medición claros. Menos errores del usuario: La validación en tiempo real de IBAN y la confirmación pre-transferencia deberían reducir los errores de transferencia en un 60% estimado. Medición: ratio de transferencias fallidas por error del usuario vs. total de transferencias iniciadas. Completación más rápida: La unificación de nomenclatura y la reducción de pasos (de 8 a 4 en transferencias) debería reducir el tiempo medio en un 40%. Medición: time-on-task desde inicio del flujo hasta confirmación. Mayor percepción de control: La eliminación de estados ambiguos y el feedback inmediato debería aumentar la percepción de control del usuario. Medición: escala de 1-7 en test post-tarea ("Sabía en todo momento qué estaba pasando con mi dinero"). Mayor confianza en el sistema: La transparencia en confirmaciones y la comunicación precisa de errores debería reducir las llamadas a soporte en un 35%. Medición: volumen de llamadas categorizadas como "consulta de estado de operación".
10. Reflection
Supuestos no validados, riesgos pendientes y límites
Este rediseño parte de supuestos que necesitan validación con datos reales. Documentarlos es parte del rigor del proceso.
- Supuesto crítico: fricción deliberada aceptable — Añadir confirmación pre-transferencia es una apuesta: protege contra errores, pero puede aumentar abandono. Si el abandono sube >5% en A/B test, simplificar la confirmación (inline, no pantalla completa) sin eliminarla. No negociable: el resumen pre-ejecución nunca desaparece
- Supuesto no validado: terminología unificada — "Enviar dinero" vs. "Transferir"/"Bizum" es una decisión de claridad vs. especificidad. Usuarios intensivos de Bizum podrían sentir que su flujo habitual está enterrado detrás de un paso genérico. Test cualitativo con 10 usuarios de Bizum diario: si >40% buscan "Bizum" específicamente, el segundo paso necesita prominencia visual del método preferido
- Primer test: flujo de transferencia con dinero simulado — 8-10 usuarios, tareas reales (enviar 50€ a contacto), midiendo errores, time-on-task y la pregunta "¿en algún momento no supiste qué había pasado con tu dinero?". Si >1 usuario responde sí, el feedback de estados tiene un fallo
- Riesgo técnico: latencia del backend bancario — La máquina de 5 estados asume que el backend informa transiciones en tiempo real. Los sistemas bancarios legacy a menudo confirman con delay (minutos, a veces horas). Si pending → success tarda 30 minutos, el usuario ve "pendiente" durante 30 minutos — técnicamente correcto pero emocionalmente problemático. Mitigación: mostrar tiempo estimado de confirmación basado en histórico real del banco
- Qué se rompe a escala — Los principios de consistencia asumen un producto con 3 flujos. Si Imaginbank escala a inversiones, préstamos y seguros, un solo patrón de interacción para todo es insostenible. El framework necesita evolucionar hacia un sistema de patrones por nivel de riesgo (bajo/medio/alto), no un patrón único
- Trade-off que puede fallar: saldo disponible como dato primario — Si un usuario con operaciones pendientes grandes ve solo saldo disponible y no entiende por qué es menor al esperado, puede pensar que hay un error. El saldo contable "un nivel abajo" puede no ser suficiente. Necesita monitorización de taps en "ver detalle de saldo" — si >20% de usuarios lo consultan en cada sesión, el dato debe subir
Insight Clave: La mayor limitación de este proyecto es que se basa en auditoría heurística, no en datos cuantitativos del flujo actual. Las estimaciones de impacto son hipótesis fundamentadas — no certezas. La siguiente fase imprescindible es instrumentar el flujo actual para medir los baselines reales antes de cualquier implementación.
