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.
Senior Product Designer · Design Lead
6 meses
1 co-lead · PM · Engineering
Grandes aseguradoras · +50 países
Impacto
Tiempo de revisión por siniestro
7,8 → 5,2 min · datos de producción. Para algunos clientes la mejora fue del 50%.
Click rate en alertas
Resultado de reorganizar y eliminar alertas — no solo rediseñarlas visualmente.
Clientes enterprise en plazo
OKR de negocio alcanzado. Primer producto de Bdeo basado en research real.
El MVP fue construido por un equipo externo, sin research con usuarios. Funcionaba, tenía clientes reales en producción. Pero los peritos no usaban las alertas — un sistema de IA que genera alertas automáticas y sus usuarios principales las ignoraban sistemáticamente.
Eso no es un problema de interfaz. Es un problema de comportamiento. Decidimos entender el flujo real antes de diseñar nada.
— Perito de siniestros, entrevista de research
Algunos stakeholders cuestionaron retrasar el diseño para hacer research. Lo defendimos: sin entender el flujo real, estaríamos optimizando sobre suposiciones.
entrevistas grabadas con peritos de grandes aseguradoras
insights extraídos y etiquetados en Airtable
métodos por sesión: journey · shadowing · card sorting
El shadowing fue el momento clave. Ver a un perito trabajar en directo reveló que el dashboard era una parada secundaria — no el centro. Buscaban el siniestro en otro sistema, lo validaban por tipo de vehículo, y entraban en Bdeo solo para las imágenes.
Las alertas no se usaban porque no correspondían al flujo operativo y eran difíciles de localizar visualmente.
Lo primero que necesitaban: VIN, matrícula, marca, modelo, número de póliza y expediente. Nada de eso estaba priorizado.
Las máscaras de IA sobre las imágenes — el showcase visual del producto — dificultaban la evaluación del daño real por parte del perito.
Tres momentos con tensión real entre el criterio de diseño y las expectativas del negocio.
Decisión 01
Propusimos eliminar varias alertas. La resistencia fue inmediata: "los clientes las pidieron, si las quitamos habrá quejas". Nuestro argumento era más 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 no fue estético — fue el comportamiento documentado.
+267% en click rate. Las que quedaron eran las que importaban.
Decisión 02
Las máscaras eran la demostración visual del valor tecnológico de Bdeo. El equipo de IA las defendía — era 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 control no restó valor al producto — lo aumentó.
De interferencia a herramienta de valor añadido
Decisión 03
Bdeo opera con configuraciones muy distintas por cliente. La presión era mantener esa fragmentación. 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.
Un producto que escala sin acumular deuda de diseño.
Antes
Después
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.
01
Arquitectura de información
02
Wireframes en baja
03
Wireframes en alta
04
Validación de prototipos
05
Componentización DSL
Proceso