Lo que aprendí en 10 años haciendo UX en banca regulada

En 2015 entregué mi primer flujo de onboarding bancario en un Word con capturas de Sketch. En 2025 estoy integrando modelos generativos a procesos conversacionales para abrir cuentas con KYC reforzado.

Mucho cambió en la herramienta. Casi nada cambió en lo que importa: ganar la confianza del usuario en 90 segundos antes de pedirle datos sensibles.

Diez años después, te dejo lo que solo se aprende haciendo UX dentro de la banca regulada — no leyéndolo en blogs.

La regulación no es enemiga del UX. Es la disciplina que te enseña a hacer UX maduro.

La regulación te enseña a justificar cada elemento

Mi primer instinto al ver un onboarding bancario fue el del Junior bien intencionado: quitar todo lo que sobraba. "¿Por qué este check? ¿Por qué este aviso legal de 4 líneas? ¿Por qué pedir el segundo apellido si ya pedimos el RUC?"

Mi gerente me sentó con el oficial de cumplimiento. En 30 minutos aprendí más sobre diseño que en 6 meses de cursos. Cada elemento que yo quería eliminar tenía detrás una norma específica, una multa potencial, o un caso real de fraude que se evitó con esa fricción.

La regulación no me decía "añade fricción". Me decía "justifica por qué cada paso existe — si no puedes justificarlo, está mal por otra razón". Eso es exactamente UX maduro.

Diseñadores que vienen de productos no regulados muchas veces hacen onboardings hermosos pero inaplicables en sectores donde el error no es UX, es legal.

El usuario bancario no es lento, es desconfiado por buenas razones

En LATAM hay 30 años de fricción real con bancos. Comisiones ocultas, cuentas que se cierran sin aviso, fraudes telefónicos que el banco no asume, atención al cliente que pide el mismo dato 4 veces.

Cuando un usuario abre una app bancaria nueva, no está leyendo "evaluando un producto". Está protegiéndose de una experiencia previa que probablemente le costó dinero.

"Diseñar simple" en este contexto no significa "diseñar amigable". Significa "diseñar transparente": explicar qué pasa, por qué, cuándo verá su dinero, qué hace el banco si algo sale mal.

Una vez en un proyecto, el equipo insistió en hacer el onboarding "más sencillo" — eliminamos pasos, reducimos textos, dejamos pantallas mínimas. La conversion bajó. La hipótesis fue que se sentía sospechosamente liviano. Volvimos a una versión más explícita y conversacional, y la conversion subió 18%.

Lo que el usuario interpretaba como "rapidez" lo leía como "le falta seriedad". En banca, la fricción explicada genera más confianza que la fricción eliminada.

Compliance no es checklist, es co-diseño

El error del Junior es tratar a Legal y Compliance como un filtro al final del proceso. Diseñas, mandas, te devuelven la lista de lo que no se puede, replanteas, ciclo lento.

El cambio que más me hizo madurar profesionalmente fue invitar a Legal y Compliance a las sesiones de discovery. No al final. Al inicio.

Te confieso algo que casi nadie escribe en blogs de UX: muy pocas veces te dicen "no". Casi siempre dicen "sí, pero adicionalmente esto". Tu trabajo como UX en sector regulado es traducir ese "sí pero" en una interacción que mantenga confianza, no en pelear contra él.

El día que entendí esto, dejé de ver Compliance como obstáculo y empecé a verlo como co-autor invisible del producto. Mis flujos empezaron a ser aprobados al primer intento. No porque cumplieran "menos", sino porque ya estaban diseñados con la regla en mente.

Lo que estos 10 años me dejaron operacionalmente

Tres patrones que aplico hoy en cualquier proyecto de banca, seguros o salud:

Métrica que sigo

El tiempo desde que el usuario completa el formulario hasta que hace su primera transacción real. No el "completion rate" del onboarding (vanidad), no el "time to first action" (engaño). El tiempo desde firma hasta uso real es la única métrica que captura si la experiencia generó la confianza necesaria para usar el producto.

Patrón que evito

"Explicarle al usuario por qué necesitamos X dato". Suena correcto, parece transparente, pero genera fricción cognitiva. El usuario no quiere saber por qué necesitas su dirección — quiere saber qué vas a hacer con ella y si es seguro. La diferencia es sutil pero decisiva.

Patrón que repito

Hacer visible la seguridad sin gritar "soy seguro". Iconos pequeños de cifrado, mensajes contextuales del tipo "esta información va directo a tu cuenta — el equipo de soporte no la verá", micro-feedback cuando el usuario completa un campo sensible. Cosas pequeñas que acumuladas construyen tranquilidad.

Si vas a entrar al sector, dos avisos

Si estás considerando moverte a UX en banca, seguros, fintech o salud, te dejo dos avisos antes de aceptar el rol.

Primero, tu portfolio funciona distinto. Los reclutadores en sectores regulados no buscan "wow visual". Buscan evidencia de criterio bajo restricción. Si tu portfolio muestra solo apps minimalistas con 3 pantallas, no convences. Muestra cómo decidiste qué priorizar dentro de un flujo regulatorio que no podías cambiar.

Segundo, aprende a leer regulación básica. No necesitas ser abogado. Pero conocer los términos básicos — KYC, AML, normativa local de protección de datos, reglamentos del regulador local — te diferencia inmediatamente de otros candidatos que llegan con experiencia más "creativa". Es lectura aburrida pero es exactamente lo que separa al UX que dura del que dura un proyecto y se va.

Mucho cambió en estos 10 años. Las herramientas, los frameworks, los términos de moda. Pero el trabajo sigue siendo el mismo: ganar la confianza de alguien en 90 segundos para pedirle algo importante. Si eso te emociona, este es el sector. Si quieres pantallas bonitas, hay otros lugares.

---