Cuando el reembolso funciona, pero el usuario queda a ciegas
Rediseñé la experiencia de seguimiento de reembolsos de salud en Bice Vida para que las personas entendieran qué estaba pasando con su solicitud, cuánto recibirían y cuál era el siguiente paso.
El Desafío 🧨
El problema no estaba en el proceso de reembolso, sino en que el usuario no podía entenderlo.
El reembolso es la principal razón por la que las personas entran a la Sucursal Virtual y a la App: involucra su dinero y su salud. Los SLAs se cumplían — pero apenas se enviaba la solicitud, el usuario quedaba sin señales. Mi objetivo fue transformar un proceso opaco en uno comprensible y trazable.
El comportamiento de los usuarios confirmaba lo que decían: en el Historial, miles de personas entraban a buscar una solicitud, no la encontraban y se devolvían sin resolver nada — casi 18.300 veces en un solo mes. En el Detalle, en vez de confiar en lo que veían en pantalla, preferían descargar el PDF de liquidación para entender cuánto les habían pagado: casi el doble de personas descargó el PDF frente a las que revisaron el detalle directamente. Y cuando les preguntamos por qué calificaban mal esa pantalla, 8 de cada 10 respuestas de junio decían lo mismo: no entendían el resultado.
El usuario no estaba buscando información nueva. Estaba buscando certeza — sin llamar, sin revisar el banco, sin pedir ayuda.
Cómo lo investigamos
Triangulación 🔎No quería diseñar basándome solo en lo que los usuarios decían — quería entender dónde se rompía realmente la experiencia. Por eso combiné investigación generativa, evaluativa, actitudinal y conductual, para que cada decisión quedara respaldada por más de una fuente.
Generativa
Research consolidado 2025–2026, entrevistas y mapeo del servicio (service blueprint) con Operaciones/Liquidación: qué ve el usuario y qué pasa detrás, en el proceso interno.
Evaluativa
10 testeos moderados de usabilidad (2025 y 2026): sesiones remotas para la web y presenciales para validar el prototipo de la App.
Actitudinal
Encuestas continuas de satisfacción (ISN) y esfuerzo percibido (CES), encuesta de naming de estados (n=838).
Conductual
Analítica de producto y monitoreo técnico (Pendo, Datadog) y datos del Contact Center: descargas, reintentos y devoluciones sin resolver, tiempo en cada pantalla.
✅ Lo que confirmamos — validado por más de una fuente
- "Liquidada" y "aprobado" se leen como pagado, cuando no lo son.
- Cuesta entender cómo se calculó el monto reembolsado.
- La fecha de pago confiable elimina la ansiedad — y 7 de 8 usuarios usan el banco como esa fecha, no la plataforma.
- Los datos del historial no permiten reconocer una solicitud fácilmente; faltan estados y tiempos entre ellos.
💡 Lo que planteamos como hipótesis — a validar en testeo
- Un estado con resultado, causa y próximo paso reduciría la ansiedad.
- Mostrar el cálculo del monto con porcentajes explícitos generará confianza.
- Un historial pensado como panel de seguimiento reducirá la búsqueda repetida.
- Poder nombrar o identificar cada solicitud ayudaría a encontrarla más rápido.
Insights clave
El problema no era el flujo: era la comprensión.
El estado no responde la pregunta del usuario
Los estados ("aprobado", "liquidada") describían el proceso interno, no si el dinero ya había sido depositado ni cuál era el siguiente paso.
El monto era una caja negra
El usuario no podía reconstruir cómo se llegó a lo que recibe, y terminaba dependiendo del PDF de liquidación.
No había seguimiento ni fecha de pago
Sin trazabilidad ni próximos pasos, el usuario volvía una y otra vez a revisar, y solo confirmaba el pago al verlo en su cuenta bancaria.
No todos los rechazos eran finales
El historial no distinguía una solicitud recuperable de una rechazada de verdad — la encontrabilidad era el dolor n.º 1.
De insights a decisiones
Primero definí qué no sabía, y recién ahí elegí el método para resolverlo: construí dos perfiles de usuario (Patricia, la experta; Ernesto, el novato) con su recorrido completo, un mapa de oportunidades que conecta cada hipótesis con su evidencia, una encuesta Kano para priorizar qué construir primero, y una matriz que asigna a cada duda abierta el método correcto para validarla.
Pantallas diseñadas 📱
Un Detalle que se explica solo: mismo lenguaje en "en revisión" y "pagado" — la única diferencia es la información completándose, no una pantalla distinta. La misma claridad se llevó a la App, donde el segmento reembolso era el peor evaluado.
Una solución, dos contextos
En Web, el Historial tiene más espacio para el detalle completo. En App, prioricé cuadros-resumen (reembolsado, en revisión, por validar) y estados por color para reconocer cada solicitud sin abrirla — la misma claridad, adaptada al contexto de cada plataforma.
Validación
Dividí la validación en dos etapas, según lo que había que probar en cada plataforma: 6 sesiones remotas con usuarios de Sucursal Virtual (web) y 4 sesiones presenciales, necesarias para validar de cerca el prototipo de la App — perfiles novatos, expertos y clientes migrados desde otra aseguradora. Separé con cuidado lo que era falla del prototipo de lo que era un problema real de comprensión, para no contaminar los resultados.
Lo que funcionó
- La explicación del deducible fue lo mejor evaluado — varios 5/5 por el ejemplo práctico.
- "Apelar una solicitud rechazada" fue la funcionalidad más valorada por todos.
- Los cuadros-resumen del historial gustaron y refuerzan el valor percibido del seguro.
- Los clientes migrados percibieron la experiencia como más fluida que su aseguradora anterior.
Lo que seguimos iterando
- El copago no se explica: la mayoría no sabe qué es (misma receta que el deducible).
- Una solicitud con dos estados (una parte pagada, otra pendiente) confunde.
- Editar/corregir tiene baja descubribilidad; piden un ícono de lápiz explícito.
- Buscar por número de solicitud no sirve; quieren buscar por tipo y fecha.
El mayor cambio no fue rediseñar el reembolso. Fue hacer visible lo que siempre había estado ocurriendo detrás.
Impacto esperado: reducir la dependencia del PDF de liquidación, aumentar la comprensión del estado y monto del reembolso, y disminuir la incertidumbre sobre el próximo paso.
Diseño validado en research y en 10 sesiones de usabilidad (web + App). El flujo pasa ahora a implementación — métricas de impacto en producción, conectadas a las metas 2026 de Experiencia, pendientes de medir tras el lanzamiento.