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
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
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
De uso casi nulo a uso consistente en todos los clientes activos
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 en los que la decisión correcta no era la obvia.
Decisión 01
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 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. La alternativa era seguir con versiones separadas por cliente — la descartamos: no escala, acumula deuda y fragmenta el criterio del equipo de diseño. 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
No todo necesitaba intervención. Parte del trabajo fue decidir dónde no entrar.
Mantuve las vistas que ya funcionaban en producción — reemplazarlas sin evidencia habría sido ruido. No optimicé excepciones antes que el flujo principal — el caso frecuente manda. No eliminé las máscaras de IA — las hice controlables, porque el problema era el control, no la existencia de la feature. No forcé consistencia visual donde el comportamiento no la pedía.
La complejidad del negocio no desaparece — decides 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.
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.
Mostrar menos puede ayudar a decidir mejor. No fue un principio estético — fue la consecuencia directa de ver a peritos bloquearse frente a opciones que no necesitaban.
Resultado
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
Componentes
DSL
Spacing
Buttons
En este proyecto el research no validó el brief — lo cambió por completo. Lo que pensábamos que era un problema de interfaz era un problema de comportamiento no documentado.