Reducir la fricción y la incertidumbre en una decisión financiera de alta complejidad.
De simular un crédito a entender una decisión financiera
El problema no era solo completar un formulario: era entender qué significaban los resultados y saber cómo continuar.
Transformé hallazgos de research y pruebas con usuarios en una experiencia más clara, guiada y confiable, capaz de acompañar al usuario desde la exploración hasta una posible contratación digital.
La motivación existía, pero la dificultad percibida y los resultados poco claros frenaban el avance.
Realicé research con usuarios, identifiqué patrones, modelé el comportamiento con Fogg y traduje los hallazgos en una propuesta de producto.
Aumentar la continuidad del flujo y la intención de avanzar hacia un lead hipotecario digital.
- Menor abandono
- Menos dudas durante el flujo
- Mayor comprensión de resultados
- Mayor confianza
- Más leads calificados
De simular un crédito a entender una decisión financiera
El problema no era solo completar un formulario: los usuarios necesitaban comprender el resultado, confiar en él y saber qué hacer después.
Objetivo
Transformé un simulador hipotecario complejo en una experiencia más clara, guiada y orientada a conversión. El outcome buscado era que las personas pudieran comprender sus resultados, confiar en ellos y avanzar con claridad hacia el siguiente paso, en lugar de abandonar por incertidumbre. A través de research con usuarios, benchmark y Fogg Behavior Model, identifiqué las causas de fricción y traduje esos hallazgos en una dirección de producto: hacer accionables los resultados y aumentar la continuidad hacia un lead hipotecario digital, sin sacrificar comprensión ni confianza.
De simular un crédito a entender una decisión financiera
El problema no era solo completar un formulario: era entender qué significaban los resultados y saber cómo continuar.
Transformé hallazgos de research y pruebas con usuarios en una experiencia más clara, guiada y confiable, capaz de acompañar al usuario desde la exploración hasta una posible contratación digital.
Reducir la fricción y la incertidumbre en una decisión financiera de alta complejidad.
La motivación existía, pero la dificultad percibida y los resultados poco claros frenaban el avance.
Realicé research con usuarios, identifiqué patrones, modelé el comportamiento con Fogg y traduje los hallazgos en una propuesta de producto.
Aumentar la continuidad del flujo y la intención de avanzar hacia un lead hipotecario digital.
- Menor abandono
- Menos dudas durante el flujo
- Mayor comprensión de resultados
- Mayor confianza
- Más leads calificados
LA DECISIÓN DE PRODUCTO
Diseñar la continuidad después del cálculo.
El benchmark y los hallazgos publicados sitúan la fricción en dos momentos: completar la simulación y entender qué hacer con su resultado. La propuesta conecta ambos con un recorrido guiado, resultados comparables y opciones para guardar y retomar.
Conecté entrevistas y pruebas, benchmark y análisis de comportamiento con una propuesta UX/UI. Los artefactos muestran cómo esa lectura se traduce en pasos, ayuda contextual y continuidad hacia una consulta hipotecaria.
Favorecer un siguiente paso comercial sin confundir avance con comprensión. La persona necesita interpretar las condiciones y conservar la posibilidad de comparar antes de decidir.
Un benchmark, análisis de usuarios, wireframes y pantallas de la propuesta. El caso declara un MVP navegable; los materiales revisados no acreditan un lanzamiento ni resultados de conversión medidos.
La investigación y los diseños que siguen son los materiales existentes del caso. Al final, el respaldo de decisiones y validación distingue sus hallazgos publicados de las pruebas propuestas para evaluar la solución.
Realicé entrevistas y pruebas con usuarios reales de diferentes comunas de Santiago (Ñuñoa, La Florida, Puente Alto, San Miguel), todos pertenecientes al segmento socioeconómico C1b. Identifiqué frustraciones comunes como la repetición de datos y la falta de orientación durante el proceso.
Apliqué el Fogg Behavior Model para entender cómo la baja motivación extrínseca y la alta dificultad percibida estaban afectando el éxito del simulador.
User persona
“Uso el banco por que es el más económico, me cobra solo cuando lo uso. Siempre lo he tenido, desde que estudiaba y me sirve tenerlo por que quiero abrir una cuenta de ahorro para la vivienda y algún día podría sacar un subsidio para un hipotecario, ojalá me gane el subsidio”
Benchmark
El benchmark muestra una evaluación comparativa de la experiencia de simuladores hipotecarios en distintos bancos, destacando a BancoEstado con una de las puntuaciones más bajas en aspectos clave del proceso digital. Aunque su formulario es bien evaluado (nota 8), presenta serios problemas en funcionamiento (nota 3), claridad de resultados (nota 2) y percepción final del usuario (notas 4 y 5), lo que indica fricciones críticas en el flujo posterior a la simulación. Para el proceso DAP de BancoEstado, es fundamental priorizar mejoras en la presentación y comprensión de los resultados simulados, así como en la claridad del objetivo final, enfocándose especialmente en accesibilidad, feedback en tiempo real y confianza en el resultado entregado. Esto permitiría cerrar la brecha entre una buena entrada de datos y una experiencia satisfactoria de principio a fin.
Qué decisión orienta este benchmark. En la fila BancoEstado, la primera impresión del formulario recibe 8 y su funcionamiento 3; en resultados, la primera impresión recibe 2 y la calidad 5. Esta diferencia orienta la propuesta hacia el funcionamiento y la interpretación del resultado, además de la entrada de datos. Son notas del artefacto publicado: la escala, evaluadores y protocolo deben recuperarse antes de tratarlas como medición comparable o actual.
Diagrama de flujo
A partir del benchmark anterior y el diagrama de flujo DAP presentado, se concluye que el proceso actual de BancoEstado presenta una desconexión crítica entre la intención del usuario (simular) y la entrega de valor real del simulador. Aunque el flujo contempla decisiones lógicas (simular o no, comparar con otro banco), el benchmark evidencia que la calidad de los resultados, la percepción final del usuario y la claridad del output son aspectos deficientes. Esto sugiere que el flujo DAP necesita reforzarse en dos dimensiones clave: (1) enriquecer la ruta de simulación con mejores explicaciones y resultados accionables, y (2) hacer más visible el valor del sistema de ayuda para quienes no simulan. El rediseño debe enfocarse en evitar abandono post-simulación y mejorar la confianza del usuario en los datos entregados.
Simulador Hipotecario
Los usuarios acceden al simulador hipotecario para obtener información sobre préstamos hipotecarios.
Sistema de ayuda
Se ofrece un sistema de ayuda para guiar a los usuarios durante el proceso de simulación.
Enviar simulación a email
Los usuarios tienen la opción de enviar los resultados de la simulación a través de correo electrónico.
¿Simulación de otro banco?
Habrá un sistema para compartir las condiciones y los resultados con otras entidades financieras.
Consulta y seguimiento
Los usuarios tienen la opción de realizar realizar un seguimiento sobre su simulación.
Modelo de Fog
Usé el Modelo de Fogg para analizar el abandono del simulador hipotecario: los usuarios tenían motivación inicial, pero la alta dificultad percibida (formularios complejos y resultados poco claros) los ubicó en la zona de fallo. Esto permitió identificar la necesidad de simplificar el flujo y mejorar la comprensión para aumentar la conversión.
Objetivo de negocio: aumentar los leads y contrataciones de créditos hipotecarios online.
Objetivo de UX: crear una experiencia clara, guiada y fluida para apoyar decisiones hipotecarias informadas.
– Onboarding progresivo para captura de datos.
– Sistema de ayuda contextual paso a paso.
– Opción para enviar la simulación por correo.
– Posibilidad de comparar con simulaciones de otros bancos.
– Seguimiento posterior para retomar simulaciones iniciadas.
– Benchmarking
– User Personas y User Journey Map
– Diagrama de flujo DAP
– Wireframes
– Prototipo funcional de un MVP navegable
Del formulario al recorrido guiado. La propuesta distribuye la tarea en pasos, muestra progreso y permite volver; separa propósito de la simulación, propiedad, pie, plazo y tasa. La decisión busca reducir la carga de responder todo a la vez. Su contrapartida es una mayor cantidad de transiciones: la prueba debe observar si el progreso orienta o alarga la tarea, y si las personas comprenden las unidades y opciones.
Del resultado aislado a una decisión que puede retomarse. Las pantallas permiten comparar plazos, abrir el detalle, enviar el resultado por correo y revisar una consulta. Esto conecta comprensión, conservación y siguiente acción. El detalle añade carga de lectura; antes de afirmar una mejora habría que comprobar que las personas distinguen dividendo, costo total y condiciones, y que entienden qué han enviado y qué ocurre después. Los importes y condiciones de las imágenes pertenecen al prototipo histórico; no son una oferta vigente.
Diseño productos digitales accesibles, intuitivos y orientados a resultados.
RESPALDO DE LAS DECISIONES
De la investigación a lo que necesitamos comprobar.
La propuesta persigue continuidad con comprensión. Este respaldo conecta los materiales del caso con decisiones observables y una forma de evaluarlas. Los instrumentos de validación y medición son propuestas de esta revisión del 11 de noviembre de 2026.
Research brief
Reconstrucción del alcance a partir de lo publicado. Los antecedentes que no constan quedan pendientes, sin convertirlos en resultados nuevos.
Pregunta del caso
Contenido: Qué impide que una persona complete la simulación, comprenda su resultado y elija el siguiente paso con confianza.
Participantes y contexto declarados
Contenido: Usuarios C1b de Ñuñoa, La Florida, Puente Alto y San Miguel. Hay cinco láminas de análisis de personas; su número no demuestra el tamaño total de la muestra.
Métodos y materiales
Contenido: Entrevistas y pruebas declaradas, láminas individuales, síntesis, persona, benchmark, diagramas, análisis con Fogg, wireframes y propuesta visual.
Hallazgos publicados
Contenido: Repetición de datos, falta de orientación y dificultad para comprender los resultados. No se dispone aquí de frecuencia por hallazgo ni transcripciones para auditar saturación.
Datos por recuperar
Contenido: Número y selección de participantes, fechas, tareas, preguntas, moderación, registro de respuestas, escala del benchmark y equipo participante. La fecha del post no se usa como duración del proyecto.
Límite de interpretación
Contenido: Los artefactos documentan una dirección de diseño. No permiten atribuir causalmente abandono a una variable ni demostrar un cambio de conversión. Fogg se usa como lente de interpretación; no como medición por sí mismo.
Matriz de evidencia, decisión, solución y validación
Los dos primeros campos conectan lo publicado con la propuesta; la última columna define evaluación futura, no pruebas ya realizadas.
BE01 · Texto de entrevistas: repetición de datos y falta de orientación
Decisión: Dividir y orientar la tarea
Solución observable: Solucion1: pasos, progreso, volver y ayuda
Método de validación propuesto: Completar un escenario ficticio; registrar errores, retrocesos, solicitudes de ayuda y datos repetidos. Comprobar conservación de datos al volver en prototipo funcional.
BE02 · Benchmark: funcionamiento 3 frente a primera impresión del formulario 8
Decisión: Priorizar el recorrido funcional además de su presentación
Solución observable: Solucion1: secuencia por objetivo, propiedad y condiciones
Método de validación propuesto: Comparar tareas equivalentes en las dos versiones si se dispone de ambas; contrabalancear orden y mantener iguales los datos.
BE03 · Benchmark: primera impresión de resultados 2 y calidad 5
Decisión: Hacer comparables y explicables los resultados
Solución observable: Solucion2: tarjetas por plazo y vista de detalle
Método de validación propuesto: Pedir explicar con palabras propias la diferencia entre alternativas, dividendo y costo total; registrar errores de interpretación.
BE04 · Diagrama y texto del caso: desconexión entre simular y continuar
Decisión: Permitir guardar y retomar sin imponer contacto inmediato
Solución observable: Solucion2: envío por correo, confirmación y consulta
Método de validación propuesto: Pedir guardar, encontrar confirmación y retomar. Evaluar expectativa sobre recepción de correo y contacto comercial.
BE05 · Objetivo UX: confianza; objetivo de negocio: leads
Decisión: Evaluar continuidad junto con comprensión
Solución observable: Pantallas de resultados y siguiente acción
Método de validación propuesto: Medir tarea y comprensión conjuntamente; un clic o una solicitud no prueban una decisión informada.
Journey revisado
Mapa de experiencia propuesto a partir del flujo y las pantallas existentes.
Explorar
Necesidad y fricción: Saber si el simulador sirve al propósito personal
Respuesta de diseño: Entrada al simulador y alternativa para una cotización de otro banco
Qué observar: Comprensión del propósito, expectativas y elección de entrada.
Configurar
Necesidad y fricción: Entender qué información se solicita y cuánto falta
Respuesta de diseño: Pasos, progreso, volver y ayuda
Qué observar: Errores, retrocesos, comprensión de UF, pie, plazo y tasa; sin usar datos financieros reales en pruebas.
Interpretar
Necesidad y fricción: Entender cómo cambian las alternativas
Respuesta de diseño: Comparación por plazo y detalle de costos
Qué observar: Explicación correcta de diferencias y condiciones, no solo preferencia visual.
Conservar
Necesidad y fricción: Guardar el resultado sin tener que decidir inmediatamente
Respuesta de diseño: Enviar a correo y confirmación
Qué observar: Éxito de tarea y comprensión de lo enviado; utilizar cuentas de prueba.
Continuar
Necesidad y fricción: Saber qué paso sigue y recuperar una consulta
Respuesta de diseño: Mejorar simulación, revisar estado o iniciar solicitud
Qué observar: Qué acción elige y qué espera que ocurra; distinguir intención, solicitud y contratación.
Antes y propuesta: comparación funcional
La situación inicial se reconstruye del diagnóstico publicado; las imágenes de solución muestran una propuesta. No se dispone de una captura inicial equivalente para cada pantalla ni de una medición antes/después.
Repetición de datos y escasa orientación
Cambio propuesto: Secuencia progresiva con estado visible
Evidencia visual y costo de la decisión: Solucion1: progreso y botón volver. Más pantallas pueden agregar esfuerzo; la persistencia de datos debe probarse.
Resultado difícil de interpretar
Cambio propuesto: Comparar alternativas y acceder al detalle
Evidencia visual y costo de la decisión: Solucion2: plazo, dividendo, costo total y detalle. Más información exige jerarquía y lenguaje comprensible.
Desconexión tras simular
Cambio propuesto: Guardar, confirmar y retomar
Evidencia visual y costo de la decisión: Solucion2: correo y revisión de consulta. Depende de entrega de correo y continuidad operativa, no solo de una pantalla.
Continuidad comercial como objetivo
Cambio propuesto: Siguiente acción explícita con alternativas
Evidencia visual y costo de la decisión: Se conserva la opción de explorar y comparar. La evaluación debe detectar presión o confusión, además de clics.
Funnel de medición propuesto
Diseño de medición para una futura implementación autorizada. No se instalaron eventos ni analítica en el sitio, el banco o el prototipo.
Entrada · simulator_view
Definición: Sesión elegible que ve la entrada; contar una vez por recorrido
Lectura y límite: Denominador de entrada; no representa intención de contratar.
Inicio · simulation_start
Definición: Primera acción para configurar un escenario
Lectura y límite: Inicios / entradas; segmentar dispositivo y procedencia sin capturar datos personales.
Avance · step_complete
Definición: Paso superado y número de paso; registrar errores por código
Lectura y límite: Completados / iniciados en cada paso; no registrar montos, correo ni texto libre en analytics.
Resultado · results_view
Definición: Resultado renderizado correctamente
Lectura y límite: Resultados / inicios. Distinguir errores técnicos y abandono.
Comprensión · evaluación de tarea
Definición: Respuesta a preguntas de comprensión en prueba consentida
Lectura y límite: Respuestas correctas / evaluadas. Abrir detalles o permanecer en pantalla no sustituye esta medida.
Guardar · result_send_success
Definición: Confirmación técnica de envío, sin correo en el evento
Lectura y límite: Envíos exitosos / intentos; no implica lectura ni lead.
Continuar · next_action y lead_confirmed
Definición: Separar clic, envío de solicitud y recepción confirmada por sistema
Lectura y límite: Leads confirmados / resultados y / inicios. Contratación requiere una fuente posterior independiente.
Abandono · definición de sesión
Definición: Fijar ventana y regla de retorno antes de instrumentar; excluir tráfico interno
Lectura y límite: Reportar por paso y errores; comparar periodos equivalentes sin atribuir cambio causal al diseño por sí solo.
Protocolo de prueba
Propuesta de evaluación preparada en esta revisión, pendiente de acceso al prototipo funcional y participantes. No es un reporte de pruebas ejecutadas.
Objetivo
Diseño propuesto: Comprobar si la propuesta reduce dificultades de tarea y mejora comprensión sin inducir decisiones ni prometer aprobación.
Participantes
Diseño propuesto: Primera ronda formativa propuesta de 6–8 personas con intención o experiencia de exploración hipotecaria, variando familiaridad digital. Confirmar reclutamiento y criterios; no extrapolar porcentajes a todo el mercado.
Preparación
Diseño propuesto: Obtener consentimiento, explicar voluntariedad, usar escenarios y cuentas ficticias, registrar solo lo necesario y acordar conservación de notas. No pedir antecedentes financieros reales ni enviar solicitudes al banco.
Tareas
Diseño propuesto: Elegir propósito, configurar escenario, corregir un dato volviendo, comparar plazos, explicar resultado, guardar y retomar una consulta. El facilitador no debe sugerir las respuestas.
Comparación
Diseño propuesto: Si se cuenta con ambas versiones comparables, alternar el orden entre participantes y mantener datos y tareas equivalentes. Si falta la inicial, evaluar solo la propuesta y no presentar diferencias de rendimiento.
Métricas
Diseño propuesto: Éxito sin ayuda por tarea, errores críticos, retrocesos, tiempo descriptivo, comprensión de condiciones y siguiente paso, confianza declarada y motivos. Conservar numeradores y notas, no solo promedios.
Criterio de decisión propuesto
Diseño propuesto: Antes de evaluar, acordar que los errores que puedan llevar a interpretar una simulación como aprobación o a enviar datos sin entenderlo son bloqueantes. Continuar cuando no aparezcan errores críticos en la ronda y cada tarea esencial pueda completarse; repetir tras cambios. No confundir ausencia de error en muestra pequeña con garantía.
Detención
Diseño propuesto: Pausar ante uso accidental de datos reales, malestar, contacto con un sistema de producción o retiro del consentimiento. En pruebas de enlaces, usar entornos controlados.
Salida
Diseño propuesto: Matriz de hallazgos por tarea y severidad, cambios justificados, preguntas pendientes y nueva ronda. Vincular cada ajuste con BE01–BE05.
Estado, contribución y aprendizaje
Síntesis del alcance visible y las dependencias para acreditar impacto.
Trabajo mostrado
Estado: Research declarado, síntesis y modelos, benchmark, wireframes y propuesta visual. El caso menciona MVP navegable; verificar acceso y funcionalidades antes de evaluarlo.
Contribución
Estado: La narrativa atribuye a Cristian research, identificación de patrones, aplicación de Fogg y traducción a una propuesta. No se inventa liderazgo de equipos, responsabilidades de ingeniería ni autoría de terceros.
Implementación
Estado: No hay respaldo revisado de lanzamiento, instrumentación ni resultados operativos. La etiqueta histórica Cliente: Bancoestado no basta para inferir contrato o implementación oficial.
Aprendizaje del caso
Estado: El problema de conversión se puede abordar desde la comprensión y continuidad del recorrido: la tarea no acaba al mostrar una cuota. Los diseños permiten examinar esa dirección; las pruebas deben demostrar su efecto.
Próxima decisión
Estado: Priorizar comprensión de resultados y recuperación del recorrido antes de usar leads como único criterio. Si las personas avanzan pero interpretan mal las condiciones, la propuesta necesita ajustes.