He trabajado en fintech y banca durante aproximadamente un tercio de mi carrera de más de una década, comenzando en GFT en Brasil con dashboards en tiempo real para firmas de inversión, luego en BNP Paribas Cardif como desarrollador Angular, luego en Wonderlabs como desarrollador Angular y UX lead en una PWA de tarjeta de crédito en Canadá, y después en BMO como desarrollador front-end en una plataforma de solicitud de préstamos. Fuera de finanzas, he trabajado en una plataforma de empleo, una plataforma de viajes en grupo, una plataforma de chequeos médicos, mi propio producto SaaS y una plataforma de salud mental. El contraste es lo suficientemente marcado como para querer escribir al respecto directamente: diseñar para finanzas es genuinamente diferente de diseñar para otros sectores, y las diferencias van más allá de convenciones estéticas o una paleta de colores conservadora.
Este no es un post sobre hacer que las apps bancarias se vean modernas. Es sobre las restricciones de diseño fundamentales que hacen del UX financiero una disciplina distinta, y cómo trabajar efectivamente dentro de ellas.
La Confianza Es el Producto
En la mayoría de las categorías de software, el producto es un conjunto de funcionalidades. Los usuarios eligen Slack por su sistema de canales y búsqueda, o Notion por su editor de bloques flexible. En productos financieros, el conjunto de funcionalidades es lo mínimo esperado. El producto real es la confianza. Un usuario que no confía en que su dinero está seguro, o que la app le muestra información precisa, no la usará independientemente de lo elegante que sea la interfaz.
Esto significa que cada decisión de diseño en un producto financiero tiene que pasar un filtro de confianza. ¿Este patrón de UI comunica confiabilidad y estabilidad? ¿Este mensaje de error explica lo que pasó de manera clara y honesta? ¿Este estado de carga tranquiliza al usuario de que su transacción está siendo procesada, o crea ansiedad? Estas son preguntas que no surgen con la misma urgencia en, digamos, una app de reservas de viajes.
Señales Visuales de Confianza
La confianza se comunica parcialmente de manera visual. El lenguaje de diseño conservador de la mayoría de las apps bancarias, colores tenues, tipografía limpia, uso limitado de elementos lúdicos, no es un fallo de creatividad. Es una señal deliberada: esta es una institución seria y estable. Los usuarios han sido condicionados para asociar calma visual con confiabilidad financiera, y apartarse de esa convención requiere calibración cuidadosa.
Los design systems bancarios impulsan un diseño visual moderno y accesible mientras mantienen las señales de confianza que los usuarios esperan. El color primario se ubica en una paleta dominada por azul asociada con seguridad financiera. La tipografía es clara y legible, nunca decorativa. Las microinteracciones son intencionadas e informativas en lugar de agradables-pero-distractoras. En BMO construí features con el design system del banco, que era propiedad de otro equipo, y desde el asiento del desarrollador la lección es cuán poco margen debería dejar un sistema así para variaciones lúdicas. Un botón que se siente tonalmente inconsistente con el contexto de mover dinero cuesta confianza, no solo clics.
Cumplimiento Como Restricción de Diseño
Cada decisión de diseño en un producto financiero regulado tiene una dimensión legal. En la mayoría de las instituciones financieras, cumplimiento tiene voz antes de que comience el desarrollo. Eso no es una inconveniencia burocrática: es una parte fundamental del proceso de diseño, y yo meto las restricciones de cumplimiento en el primer wireframe en lugar de tratarlas como un paso de revisión final.
Las restricciones de cumplimiento en UX financiero incluyen: divulgaciones obligatorias que deben aparecer en ubicaciones específicas y a tamaños de fuente mínimos, pasos de confirmación requeridos antes de transacciones irreversibles, lenguaje específico para divulgación de comisiones, expiración de sesiones basada en tiempo con notificación apropiada al usuario, y requisitos de pista de auditoría que afectan cómo se registran y muestran las interacciones.
En diseño fintech, la restricción de cumplimiento no es el enemigo del buen UX. Es un brief de diseño del regulador. El desafío es satisfacerlo de una manera que también sea clara y usable.
El problema de ubicación de divulgaciones es un buen ejemplo. Los requisitos regulatorios frecuentemente exigen que las divulgaciones de comisiones aparezcan antes de que un usuario confirme una transacción. Una implementación ingenua pone esto como un párrafo de texto legal que los usuarios inmediatamente pasan de largo. Un mejor diseño integra la divulgación de manera significativa, resumiendo la información clave (Se te cobrará $4.50 por esta transferencia) en lenguaje simple, con un enlace al texto legal completo para usuarios que lo quieran. Esto satisface el requisito de cumplimiento y sirve al usuario.
Manejo de Errores en Flujos Financieros
Los estados de error en aplicaciones financieras son genuinamente de alto riesgo. Un mensaje de error vago durante una transferencia de fondos no solo crea frustración, crea pánico. ¿El dinero salió de mi cuenta? ¿Se perdió? ¿Debería intentar de nuevo? Si el usuario reintenta y la primera transacción sí pasó, puede haber enviado dinero dos veces. Esto no es un edge case teórico; es un escenario que los equipos de UX bancario toman muy en serio.
Los principios que aplico al manejo de errores en flujos financieros, siendo el movimiento de dinero el caso más difícil:
- Siempre dile al usuario el estado actual de su transacción. Si la transferencia falló antes de llegar a la red, díselo. Si fue enviada pero el timeout de respuesta venció, díselo, y explica qué significa eso para su saldo.
- Nunca dejes al usuario en ambigüedad sobre si el dinero se movió. Incluso si no conoces el resultado, di 'Estamos confirmando tu transferencia. Te notificaremos cuando tengamos confirmación.' Esto es mejor que el silencio.
- Distingue entre errores del usuario (formato de número de cuenta incorrecto) y errores del sistema (timeout de red) en el mensaje, porque la acción apropiada es diferente en cada caso.
- Proporciona un camino de recuperación claro. 'Por favor intenta de nuevo' es inadecuado. 'Por favor intenta de nuevo en unos minutos. Si el problema persiste, contáctanos al 1-800-XXX-XXXX' es accionable.
- Para errores irreversibles, proporciona información de contacto inmediatamente. No hagas que un usuario en pánico busque un número de teléfono.
Revelación Progresiva para Productos Complejos
Los productos financieros son inherentemente complejos. Una solicitud de hipoteca involucra docenas de datos, preguntas condicionales, acuerdos legales y verificación de múltiples pasos. Una vista de portafolio de inversiones involucra jerarquías de datos, cálculos de rendimiento, indicadores de riesgo y benchmarks comparativos. Presentar todo esto a la vez es cognitivamente abrumador. No presentar suficiente viola la necesidad de información del usuario al tomar decisiones consecuentes.
La revelación progresiva, revelar información progresivamente a medida que el usuario demuestra necesidad o disposición, es una de las técnicas más importantes en UX de fintech. En un formulario de solicitud largo, eso significa revelar preguntas en función de respuestas anteriores (no hace falta preguntar por el ingreso del cónyuge si el solicitante indicó que es soltero) y partir el formulario en algo que se sienta como una conversación. El onboarding es donde el diseño de flujo me ha rendido más claramente: en Wonderlabs rediseñé el flujo de onboarding de la plataforma de tarjetas de crédito a través de ciclos de prototipado y testing, y el engagement de usuarios subió 15%.
Arquitectura de Información por Capas
La revelación progresiva aplica no solo a formularios sino a la visualización de información. El patrón se generaliza bien a una vista de portafolio: las métricas esenciales de un vistazo, valor total, cambio de hoy, retorno general, y todo lo demás a una expansión de distancia. Por clase de activo, por valor individual, por período de tiempo. Esa estratificación respeta tanto al usuario que quiere una verificación rápida como al que quiere análisis profundo, sin abrumar a ninguno.
Seguridad Como Pilar de UX
Los requisitos de seguridad en aplicaciones financieras crean fricción real de UX, y el desafío de diseño es minimizar esa fricción sin comprometer el modelo de seguridad. Timeouts de sesión, autenticación de dos factores, pasos de confirmación de transacciones, re-autenticación biométrica para acciones sensibles: todos existen por razones legítimas, y todos agregan fricción a la experiencia del usuario.
El insight clave que he desarrollado es que la fricción de seguridad se siente aceptable para los usuarios cuando es proporcional al nivel de riesgo de la acción y está claramente explicada. Re-ingresar tu contraseña para ver tu saldo se siente absurdo e invasivo. Re-ingresar tu contraseña para cambiar tu cuenta bancaria vinculada se siente razonable: los usuarios entienden por qué esa acción merece verificación extra.
El modelo hacia el que convergen los bancos es la autenticación escalonada por riesgo, donde el nivel de fricción escala con el monto y el tipo de transacción. Las transferencias rutinarias de bajo valor (pagar una factura regular por debajo de un monto umbral) usan solo biometría. Las transferencias de alto valor o inusuales requieren biometría más un código de confirmación. Los nuevos beneficiarios requieren un desafío 2FA completo. Yo no he diseñado uno de estos modelos, pero la disciplina de hacer coincidir la fricción con el riesgo es la parte que vale la pena copiar en cualquier producto con acciones de consecuencia.
Accesibilidad en Industrias Reguladas
La accesibilidad en servicios financieros no es solo una obligación ética: en muchas jurisdicciones es una obligación legal. Los bancos canadienses son de regulación federal, así que caen bajo la Accessible Canada Act y la Canadian Human Rights Act, no bajo la AODA de Ontario (Accessibility for Ontarians with Disabilities Act). La AODA cubre a las organizaciones de regulación provincial en Ontario, las cooperativas de crédito entre ellas, y su Integrated Accessibility Standards Regulation (IASR) usa WCAG 2.0 AA como benchmark técnico (con excepciones para los criterios 1.2.4 subtítulos en vivo y 1.2.5 audiodescripción). En BMO, los features que construí tenían que cumplir accesibilidad, y eso lo trato como parte de terminado, no como algo posterior.
El UX financiero tiene desafíos de accesibilidad específicos que otros sectores encuentran con menos frecuencia:
- Las tablas de datos complejas (historiales de transacciones, vistas de portafolio) necesitan markup de tabla apropiado con encabezados de columna y fila para usuarios de lectores de pantalla. Una tabla visualmente elegante que colapsa en mobile y pierde su contexto de encabezados falla en accesibilidad.
- Los gráficos y charts son estándar en aplicaciones financieras pero inherentemente inaccesibles sin alternativas de texto. Cada gráfico necesita un resumen de texto y una tabla de datos alternativa accesible.
- Las sesiones con tiempo limitado crean un desafío de accesibilidad genuino. Los usuarios con discapacidades cognitivas o motoras pueden necesitar más tiempo para completar transacciones. WCAG 2.2.1 (Tiempo Ajustable) se cumple normalmente con una advertencia antes de la expiración y una forma simple de extender la sesión, y en una app bancaria esa advertencia tiene que ser anunciada a los usuarios de lectores de pantalla, no solo mostrada como un toast que se desvanece.
- Los mensajes de error en formularios financieros deben estar programáticamente asociados con sus campos de entrada para que los lectores de pantalla los anuncien correctamente. Este es un requisito de desarrollo que comienza en la etapa de especificación de diseño.
Qué Se Transfiere de Otros Sectores
No todo es diferente en UX fintech. Los fundamentos de investigación de usuarios, pruebas de usabilidad, arquitectura de información y diseño de interacción aplican en todas partes. El trabajo que hice en la plataforma de salud mental me enseñó mucho sobre diseñar para usuarios en estados emocionalmente vulnerables, lecciones que se transfieren directamente al UX financiero, donde los usuarios frecuentemente están estresados (cuenta sobregirada), ansiosos (volatilidad del mercado) o abrumados (solicitud de hipoteca).
El cambio al entrar al diseño fintech desde otros sectores es menos sobre aprender técnicas nuevas y más sobre internalizar un modelo de riesgo diferente. En fintech, las consecuencias de una mala experiencia de usuario no son solo usuarios insatisfechos: son daño financiero, incumplimiento regulatorio y erosión de la confianza que es la base de todo el producto. Ese peso cambia cómo diseñas, para mejor.
Referencias
- Financial Consumer Agency of Canada, Financial Consumer Protection Framework. https://www.canada.ca/en/financial-consumer-agency/services/banking/rights-new-protections/consumer-protection-framework.html
- WCAG 2.1 Understanding. https://www.w3.org/WAI/WCAG21/Understanding/
- Accessibility for Ontarians with Disabilities Act. https://www.ontario.ca/laws/statute/05a11
- Accessible Canada Act, resumen. https://www.canada.ca/en/employment-social-development/programs/accessible-people-disabilities/act-summary.html