El brief era mejorar la conversión del flujo de compra de fibra. Lo que encontramos al auditarlo fue diferente: métricas sin dueño, tests de usuario archivados y un campo de dirección implementado de cinco formas distintas por cinco equipos que nunca habían coordinado. El problema no estaba escondido. Estaba en los datos que nadie leía en conjunto.
Design Lead Squad
3 meses
1 PM · 1 UI Designer (front-oriented)
Flujo de compra online de fibra óptica para nuevos clientes. Producto B2C en producción en una de las tres mayores telcos de España, con analítica disponible y sin proceso sistemático para usarla.
Impacto
Conversión en el flujo
Concentrada en los pasos finales. Tasa base no publicada por Orange; dato medido internamente durante la implementación.
Ingresos recurrentes nuevos
Estimación conservadora: ~200.000 sesiones/mes, conversión base ~2,5%, ticket medio ~600€/año. +7% relativo ≈ 350 contratos adicionales/mes.
Estándar corporativo
El flujo y el componente de dirección unificado pasaron a ser la referencia para toda la web comercial.
Nota sobre las cifras económicas: el ~2.5M€ es una estimación conservadora basada en datos públicos de Orange España y benchmarks del sector. No es un dato interno publicado por Orange.
Llegué como único diseñador de UX de la squad. Lo primero que hice no fue diseñar — fue leer. Audité el flujo completo en producción, las métricas disponibles, los tests de usuario realizados en los meses anteriores. Todo existía. Nada estaba conectado.
Orange es una corporación grande. Cada squad tenía sus propias herramientas, sus propias analíticas, sus propios patrones heredados. El resultado acumulado era un flujo de compra con formularios desorganizados, pasos mezclados que deberían estar separados y más de cinco variantes distintas del selector de dirección — el campo más crítico de todo el proceso — implementadas de forma independiente por equipos que nunca habían coordinado.
Los datos de abandono mostraban un patrón claro: los usuarios llegaban al final del flujo y se iban. No al principio. Al final. Cuando ya habían invertido tiempo, rellenado datos, pasado pasos. El precio real aparecía demasiado tarde.
El problema no era técnico. Era arquitectónico. Y llevaba tiempo visible en los datos.
Antes de definir ninguna solución, necesitábamos dos cosas: saber cómo se comportaba el usuario real en el flujo, y entender dónde estábamos respecto a la competencia.
Research cualitativo — empresa externa.
Encargamos las entrevistas a una empresa externa especializada en research con usuarios. Ocho sesiones con personas que habían contratado o intentado contratar fibra online en los últimos seis meses — perfiles variados en edad, experiencia digital y operadora de origen. El objetivo no era validar hipótesis de diseño — era llegar sin sesgo al flujo antes de tocarlo.
El hallazgo central fue consistente en todas las sesiones: los usuarios no abandonaban por falta de interés. Llegaban al final del proceso — después de invertir tiempo, rellenar datos personales, seleccionar extras — y descubrían un precio que no era el que esperaban. Para entonces, la fricción emocional de haber invertido ese tiempo no compensaba la sorpresa. Salían.
Participante, sesión de research cualitativo
Benchmark funcional — 15+ operadoras
Analizamos el flujo de contratación de más de quince telcos nacionales e internacionales. El criterio no fue estético — fue funcional: ¿cuándo aparece el precio? ¿Cuántos pasos tiene el checkout? ¿Cómo piden la dirección? ¿Hay calculadora en tiempo real?
Benchmark propio. Criterio funcional, no estético.
El patrón era consistente: ningún operador con abandono bajo ocultaba el precio hasta el final. Orange ES era el único entre los quince analizados que no mostraba precio hasta completar los datos personales. El research lo explicaba desde el comportamiento. El benchmark lo confirmaba desde la competencia. Eso convirtió una hipótesis en evidencia — y la evidencia en argumento para el equipo de producto.
No era “mejorar el formulario”. Era: el flujo estaba organizado para la empresa, no para quien compraba.
Tres decisiones. La más importante no fue de diseño de producto.
Decisión 01
La decisión más difícil de este proyecto no ocurrió en Figma. Ocurrió en una reunión. Cinco variantes del selector de dirección en producción. Cada squad tenía ownership sobre la suya. Ninguna veía el problema como suyo — porque individualmente, su variante “funcionaba”. El problema era sistémico y solo era visible si alguien lo miraba desde fuera de una sola squad. El argumento no fue estético. Fue de datos: la tasa de error en el campo de dirección era una de las más altas de todo el flujo. Era el punto donde más usuarios abandonaban por fricción técnica, no por decisión.
Con eso sobre la mesa, la conversación cambió. No era “unificamos por criterio de diseño” — era “hay una variante que está costando contratos y podemos medirlo”.
El componente estandarizado se adoptó como patrón de referencia para toda la web comercial de Orange. El trabajo de negociación fue más largo que el de diseño.
Decisión 02
La arquitectura original seguía una lógica de recogida de datos: nombre, DNI, contacto — y al final, precio definitivo. El argumento para mantenerlo era de negocio: “si el usuario ve el precio real antes, puede irse sin dejarnos sus datos”.
Nuestro argumento era el contrario: si se va al final, hemos quemado su tiempo, el nuestro, y una sesión que los datos de marketing contabilizan como interés cualificado. El drop en los pasos finales era la evidencia de que esto ya pasaba, a escala, todos los días. El research con usuarios lo decía explícitamente: el problema no era el precio — era la sorpresa.
Reorganizamos el flujo para que la calculadora de coste mensual estuviera visible desde la selección de tarifa, actualizable en tiempo real según extras seleccionados.
El abandono en los pasos finales bajó de forma visible. Era el cambio más contraintuitivo para el negocio y el más predecible para el usuario.
Decisión 03
La primera vez que presenté wireframes antes de pasar a UI, el PM preguntó si era necesario “ese paso extra”. El equipo de UI estaba acostumbrado a recibir pantallas terminadas, no arquitectura. El cambio no fue bienvenido de entrada.
Lo que cambió la dinámica fue el primer handoff real con comportamiento especificado. El equipo de desarrollo recibió por primera vez un documento con estados, flujos de error y lógica de componentes definida. El feedback fue directo: era la primera vez que no tenían que asumir comportamiento por su cuenta. Sin preguntas abiertas en la implementación. Sin decisiones de diseño tomadas en código.
Eso fue suficiente para que el proceso dejara de ser “cómo trabaja este diseñador” y pasara a ser la referencia para el diseño comercial web de Orange.
Antes
Después
El brief era mejorar la conversión del flujo de fibra. Eso se cumplió. Pero el impacto más duradero fue diferente.
El flujo se convirtió en estándar corporativo.
Orange opera con múltiples productos comerciales en web. Cuando el equipo demostró que un proceso estructurado producía resultados medibles, la dirección decidió aplicarlo como referencia para el resto de la web comercial. El trabajo de una squad se convirtió en el método de todas.
El componente de dirección unificado redujo deuda acumulada de forma permanente.
Cinco variantes en producción significa cinco implementaciones que mantener, cinco posibles fuentes de error, cinco puntos de fricción distintos según por dónde entrara el usuario. Una sola implementación bien hecha elimina eso de forma estructural, no puntual.
Los datos pasaron a tener dueño.
La analítica y los tests de usuario existían antes de que llegara. Lo que no existía era alguien que los leyera sistemáticamente antes de diseñar. Parte del proceso que dejamos instalado fue precisamente eso: no empezar un ciclo de diseño sin pasar por los datos disponibles.
Con auditoría y research como base, ejecutamos en fases. La validación con 22 usuarios sobre prototipos navegables confirmó la hipótesis central — precio visible desde el inicio reducía la ansiedad de decisión — y reveló un problema no previsto: algunos usuarios interpretaban la calculadora como precio definitivo antes de confirmar cobertura, generando frustración cuando la disponibilidad modificaba el importe. No era un problema de cálculo — era un problema de comunicación de estado.
Lo resolvimos con un indicador explícito de precio “estimado / confirmado” visible y persistente durante todo el flujo. Un cambio pequeño de copy y estado que eliminó una fuente de confusión que no estaba en ningún brief y que solo apareció al poner el prototipo delante de usuarios reales.
Wireframe proceso
Auditoría del flujo en producción + análisis de métricas de abandono por paso
Research cualitativo con empresa externa — 8 sesiones con usuarios reales
Benchmark funcional con 15+ operadoras nacionales e internacionales
Arquitectura de información revisada: jerarquía de decisión del usuario, no secuencia de recogida de datos
Wireframes y prototipo navegable
Validación con 22 usuarios + ajuste del estado precio estimado / confirmado
Handoff al equipo de UI + definición del componente de dirección unificado como estándar corporativo
Resultado
En este proyecto el problema no estaba escondido. Estaba en los datos que todos tenían y nadie leía en conjunto.