- Rol
- UX Senior
- Estado
- En producción · 11 años vivo · Chile, Perú, Colombia
Contexto
El simulador anterior pedía demasiada información antes de entregar un resultado: monto, cuotas, seguros, fecha de pago, productos asociados. El usuario tenía que llenar todo para ver una cuota — y muchas veces no llegaba al final.
El research mostró un patrón claro: prácticamente todos los usos del simulador eran iterativos. La gente no entraba con un escenario fijo — entraba con curiosidad y movía variables hasta llegar a algo que les hacía sentido. Cuotas, monto, seguros, fecha de pago: todo se cambiaba múltiples veces.
El simulador estaba diseñado como formulario de crédito. Pero el usuario lo usaba como herramienta de exploración. Esa era la brecha.
La decisión central: invertir el flujo
Diseñé la pantalla con dos parámetros mínimos — monto y cuotas — controlados desde un slider único, muy bien desarrollado. Antes de que el usuario tocara nada más, ya veía una cuota estimada en pantalla.
El resto de variables (seguros, fecha de pago, productos asociados) quedaron disponibles después, no antes. Si el usuario quería refinar el cálculo, lo hacía con un estimado ya en mano.
Validación con prototipos y usuarios
Antes de llevar el simulador a producción, armé prototipos navegables para testear el comportamiento del slider con usuarios reales. La pregunta no era “¿les gusta?” sino “¿logran simular sin instrucciones, mueven el slider, entienden el resultado?”.
Los resultados confirmaron la apuesta: los usuarios llegaban al primer resultado en segundos y entendían que podían volver a mover los parámetros sin “romper” nada. Ese hallazgo fue el insumo más fuerte que tuve para defender el diseño en las reuniones siguientes con negocio — no era opinión de UX, eran usuarios reales completando la tarea.
La decisión difícil: qué pedir al entrar
Los bancos manejan muchos datos obligatorios y muchos productos asociados (seguros, garantías, comisiones) que son parte del negocio. El equipo comercial quería incluir todo en la entrada para empujar adopción de productos adicionales.
Entre los resultados del testeo y las conversaciones internas, defendimos que la pantalla principal solo tenía que responder a una pregunta: “¿cuánto sería mi cuota?”. Los productos adicionales podían aparecer después, cuando el usuario ya estaba dentro del flujo y dispuesto a explorar más. Pasar ese filtro con negocio fue la parte más larga del proyecto.
De mobile a web
El simulador nació para la app de CMR Chile, pero el patrón funcionó tan bien que terminó subiendo a la web con la misma lógica. El slider, la cuota visible desde el primer segundo y los parámetros opcionales después se mantuvieron — solo cambió el tamaño del lienzo.
Resultado
El simulador nació para la app de CMR Chile. En el tiempo: escaló a la web — la idea original era solo mobile. Se adoptó en Perú y Colombia con el mismo patrón base. Y se extendió a flujos de avance y super avance — el mismo motor para productos distintos.
Sigue en producción hoy.
Lo que aprendí
Cuando un producto sigue vivo 11 años después, no es porque era “perfecto” — es porque acertó al patrón de uso real. La gente quiere jugar con cuotas y montos antes de comprometer información sensible. Diseñar para ese patrón en lugar de para el formulario regulatorio fue toda la diferencia. La longevidad no se diseña; se gana cuando el modelo mental del usuario coincide con la interfaz.