Flujo de compra de fibra · Orange

Resumen

Orange · B2C

Cinco equipos. Cinco versiones del mismo formulario. Cero propietarios.

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. La información estaba ahí, en datos que nadie había leído en conjunto.

Rol

Design Lead Squad

Duración

3 meses

Equipo

1 PM · 1 UI Designer (front-oriented)

Contexto

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

• +7% Conversión en el flujo — Concentrada en los pasos finales. Tasa base no publicada por Orange; dato medido internamente durante la implementación.
• ~2.5M€ 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.
• 1 squad → toda Orange 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.

El problema

Llegué como único diseñador de UX de la squad y, antes de diseñar, me puse a leer. Audité el flujo completo en producción, las métricas disponibles y los tests de usuario de los meses anteriores. La información existía, pero estaba desconectada.

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 del selector de dirección, el campo más crítico del proceso, implementadas de forma independiente por equipos que nunca habían coordinado.

Los datos de abandono mostraban que los usuarios se iban al final del flujo, después de invertir tiempo y rellenar sus datos. El precio real aparecía demasiado tarde.

Era un problema de arquitectura del flujo, y llevaba tiempo visible en los datos.

Research

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.

1. Research cualitativo con una 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, con perfiles variados de edad, experiencia digital y operadora de origen. Queríamos ver el flujo sin sesgo antes de tocarlo.

Pensé que el precio que veía era el final. Cuando llegué al resumen era diferente. Ya no me fiaba.

1. Benchmark funcional de más de 15 operadoras. Analizamos el flujo de contratación de más de quince telcos nacionales e internacionales. Nos fijamos en cómo funcionaban: ¿cuándo aparece el precio? ¿Cuántos pasos tiene el checkout? ¿Cómo piden la dirección? ¿Hay calculadora en tiempo real?

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. Con las dos fuentes, la hipótesis se convirtió en un argumento sólido para el equipo de producto.

El flujo seguía el orden en que la empresa recogía datos. Quien compraba necesitaba otro.

Decisiones

Tres decisiones, y la más importante se tomó fuera de Figma.

Convencer a tres squads de que tenían el mismo problema

La decisión más difícil del proyecto se tomó en una reunión. Había cinco variantes del selector de dirección en producción y cada squad era dueña de la suya. Ninguna lo veía como un problema propio, porque su variante, por separado, “funcionaba”. Solo se veía mirando desde fuera de una squad. Mi argumento fueron los datos: la tasa de error en el campo de dirección era de las más altas del flujo, y era el punto donde más usuarios abandonaban por fricción técnica.

Con eso sobre la mesa, la conversación cambió: ya no hablábamos de criterio de diseño, sino de una variante que estaba costando contratos y que podíamos medir.

Mostrar el precio antes de pedir los datos

La arquitectura original seguía una lógica de recogida de datos: nombre, DNI, contacto y, al final, el 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 lo decía claramente: a los usuarios les molestaba más la sorpresa que el precio.

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.

Introducir proceso donde no había ninguno

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. No quedaron preguntas abiertas en la implementación ni decisiones de diseño tomadas en código.

Impacto real

El brief era mejorar la conversión del flujo de fibra. Se cumplió, pero el impacto más duradero vino por otro lado.

1. 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.
2. 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 ese problema de raíz.
3. 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 fue no empezar un ciclo de diseño sin revisar antes los datos disponibles.

Proceso

Con auditoría y research como base, ejecutamos en fases. La validación con 22 usuarios sobre prototipos navegables confirmó la hipótesis central (ver el precio desde el inicio reducía la ansiedad al decidir) y reveló un problema no previsto: algunos usuarios tomaban la calculadora como precio definitivo antes de confirmar la cobertura, y se frustraban cuando la disponibilidad cambiaba el importe. Había que comunicar mejor el estado del precio.

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.

1. Auditoría del flujo en producción + análisis de métricas de abandono por paso
2. Research cualitativo con empresa externa: 8 sesiones con usuarios reales
3. Benchmark funcional con 15+ operadoras nacionales e internacionales
4. Arquitectura de información ordenada según cómo decide el usuario
5. Wireframes y prototipo navegable
6. Validación con 22 usuarios + ajuste del estado precio estimado / confirmado
7. Handoff al equipo de UI + definición del componente de dirección unificado como estándar corporativo

Cierre

En este proyecto la respuesta estaba en datos que todos tenían y nadie había leído en conjunto.

En una organización grande, diseñar bien también es saber dónde está la información, quién es dueño de cada pieza y cómo construir el argumento que alinea a equipos distintos.

Summary in English

Fibre purchase flow · Orange

+7% conversion · ~€2.5M new recurring revenue · Corporate standard

Orange · B2C

Five teams. Five versions of the same form. Zero owners.

The brief was to improve conversion in the fibre purchase flow. Auditing it showed something else: metrics with no owner, user tests filed away, and an address field built five different ways by five teams that had never coordinated. Everything was there, in data nobody had read as a whole.

Role

Squad Design Lead

Duration

3 months

Team

1 PM · 1 UI Designer (front-oriented)

Context

Online fibre purchase flow for new customers. B2C product in production at one of Spain’s three largest telcos, with analytics available and no systematic process to use them.