Senior Product Designer en Madrid, España
El brief era aumentar la conversión del flujo de contratación de fibra. Lo que encontramos fue diferente: los usuarios llegaban con intención de compra y se caían dentro del proceso. El problema no era la oferta — era que el flujo nunca fue diseñado para ayudar a alguien a decidir.
Design Lead
4 meses
PM · Engineering · Legal
Flujo solo fibra · Orange España · web comercial
Impacto
Conversión global del flujo Primer proyecto de diseño en Orange con proceso estructurado de research.
Adoptado como estándar interno para todos los flujos de la web comercial.
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.
Orange tenía tasas de abandono altas en pasos intermedios, no al final. Los usuarios llegaban con intención — ya habían visto tarifas, ya habían comprobado cobertura — y se caían dentro del proceso. La hipótesis inicial era que el precio frenaba. El análisis de comportamiento decía otra cosa: la fricción era de arquitectura, no de oferta. Cada pantalla pedía una decisión que el usuario no estaba preparado para tomar.
Lo que hacía el problema más difícil era el contexto interno: en Orange no existía un proceso de diseño estructurado para flujos web. No había research previo a la ejecución. Proponer pararlo todo para entender antes de diseñar no era una decisión técnica — era una decisión política.
— 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
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
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.