Dashboard de gestión de siniestros · Bdeo

Resumen

Bdeo · B2B SaaS

Cuando el problema no era lo que parecía

El brief era mejorar el dashboard. Lo que encontramos fue diferente: los peritos ignoraban las alertas de IA porque el sistema nunca fue diseñado para su flujo de trabajo real.

Rol

Senior Product Designer · Design Lead

Duración

6 meses

Equipo

1 co-lead · PM · Engineering

Contexto

Dashboard de gestión de siniestros para grandes aseguradoras. Producto B2B enterprise en producción, con clientes reales que no usaban la funcionalidad core.

Impacto

• −33% Tiempo de revisión por siniestro — 7,8 → 5,2 min · datos de producción. Para algunos clientes la mejora fue del 50%.
• +267% Click rate en alertas — De uso casi nulo a uso consistente en todos los clientes activos
• 5 Clientes enterprise en plazo — OKR de negocio alcanzado. Primer producto de Bdeo basado en research real.

El problema

Un equipo externo construyó el MVP sin hacer research con usuarios. Funcionaba y tenía clientes reales en producción, pero los peritos no usaban las alertas: el sistema de IA las generaba automáticamente y sus usuarios principales las ignoraban.

El problema estaba en cómo trabajaban los peritos más que en la interfaz. Por eso decidimos entender su flujo real antes de diseñar nada.

No uso las alertas actuales. No corresponden a las que necesito leer y no las veo fácilmente en la pantalla.

Research

Algunos stakeholders cuestionaron retrasar el diseño para hacer research. Lo defendimos: sin entender el flujo real, estaríamos optimizando sobre suposiciones.

• +8h entrevistas grabadas con peritos de grandes aseguradoras
• 180+ insights extraídos y etiquetados en Airtable
• ×3 métodos por sesión: journey · shadowing · card sorting

1. El shadowing fue el momento clave. Ver a un perito trabajar en directo reveló que el dashboard era una parada secundaria en su trabajo. Buscaban el siniestro en otro sistema, lo validaban por tipo de vehículo, y entraban en Bdeo solo para las imágenes.
2. Las alertas no se usaban porque no correspondían al flujo operativo y eran difíciles de localizar visualmente.
3. Lo primero que necesitaban: VIN, matrícula, marca, modelo, número de póliza y expediente. Nada de eso estaba priorizado.
4. Las máscaras de IA sobre las imágenes, que eran el showcase visual del producto, dificultaban la evaluación del daño real por parte del perito.

Decisiones

Tres momentos en los que la decisión correcta no era la obvia.

Eliminar alertas que el negocio defendía

Propusimos eliminar varias alertas. La resistencia fue inmediata: "los clientes las pidieron, si las quitamos habrá quejas". Nuestro argumento era simple: los peritos no las usaban. Teníamos grabaciones, teníamos datos. Las reorganizamos, priorizamos y eliminamos las que no tenían sentido operativo. El criterio fue el comportamiento documentado.

Las máscaras de IA: cuando el showcase dificulta el trabajo

Las máscaras eran la demostración visual del valor tecnológico de Bdeo. El equipo de IA las defendía porque eran su trabajo hecho visible. El research mostraba que los peritos las ignoraban al evaluar daños. No las eliminamos: las hicimos opcionales y diseñamos un modo de comparación que daba control al usuario. Dar ese control aumentó el valor del producto.

Consistencia en un producto multi-cliente con tendencia a fragmentarse

Bdeo opera con configuraciones muy distintas por cliente. La presión era mantener esa fragmentación. Seguir con versiones separadas por cliente no escalaba, acumulaba deuda y fragmentaba el criterio del equipo de diseño, así que lo descartamos. Hicimos lo contrario: identificar una base común sólida y tratar los módulos variables como capas encima. Algunos stakeholders renunciaron a personalizaciones que consideraban esenciales.

Lo que no toqué

No todo necesitaba intervención. Parte del trabajo fue decidir dónde no entrar.

Mantuve las vistas que ya funcionaban en producción, porque reemplazarlas sin evidencia solo habría añadido ruido. Prioricé el flujo principal antes que las excepciones. Las máscaras de IA se quedaron, pero ahora las controla el perito. Y no forcé consistencia visual donde el comportamiento no la pedía.

Proceso

Con los insights consolidados, ejecutamos cinco fases. La validación con prototipos reveló un problema no previsto: los usuarios olvidaban guardar al editar datos por tarjeta individual. Rediseñamos el patrón de guardado antes del lanzamiento.

1. Arquitectura de información
2. Wireframes en baja
3. Wireframes en alta
4. Validación de prototipos
5. Componentes DSL

Aprendizajes

1. La complejidad del negocio no desaparece; lo que decides es dónde vive. Si la metes en la interfaz, el usuario la carga. Si la dejas en el sistema, la carga el equipo técnico. El trabajo es elegir quién puede cargarla mejor.
2. Validar antes reduce más fricción que simplificar tarde. Las tres decisiones principales partieron del mismo sitio: entender qué pasaba antes de proponer qué cambiar.
3. Mostrar menos puede ayudar a decidir mejor. Lo aprendimos viendo a peritos bloquearse frente a opciones que no necesitaban.

Cierre

En este proyecto el research cambió el brief por completo. Lo que parecía un problema de interfaz era una forma de trabajar que nadie había documentado.

El research es lo que decide si el proyecto tiene sentido.

Summary in English

Claims management dashboard · Bdeo

−33% review time per claim · +267% alert click rate

Bdeo · B2B SaaS

When the problem wasn’t what it looked like

The brief was to improve the dashboard. What we found was different: adjusters ignored the AI alerts because the system was never designed around their real workflow.

Role

Senior Product Designer · Design Lead

Duration

6 months

Team

1 co-lead · PM · Engineering

Context

Claims management dashboard for large insurers. Enterprise B2B product in production, with real clients who weren’t using the core feature.