Vodafone vende dispositivos siempre vinculados a una tarifa. En la web pública, eso significaba que cualquier persona podía iniciar una compra antes de ser cliente — y eso lo hacía muy vulnerable al fraude.

A finales de 2021, el 91% de los pedidos se cancelaban y el 62% de esas cancelaciones eran fraude. Solo el 9% de las ventas llegaban a una activación real. Con esos números encima de la mesa, el negocio planteaba cerrar el canal online y derivar toda la venta a tienda física o canal asistido.

El reto no era mejorar un flujo. Era ver si el ecommerce tenía futuro.

Tras un workshop con producto, negocio y desarrollo, exploramos varias opciones. El equipo de diseño trabajó junto a los analistas para entender el patrón de fraude real — dónde se producía, qué tipo de usuarios lo generaban, qué pasos del journey eran el punto de entrada. Barajamos un modelo de renting de dispositivos, reservas con señal, y distintas combinaciones de pasos. Todas tenían el mismo problema: cualquier modelo que dejara la compra del dispositivo accesible antes de verificar la identidad del usuario seguía siendo vulnerable al fraude.

La única que lo resolvía de raíz era invertir el orden: primero cliente, luego dispositivo. El usuario compraría una tarifa SIM Only en la web, pasaría por un proceso de preactivación y, una vez activo, podría comprar el dispositivo desde la app de Mi Vodafone.

Lanzamos el piloto al 100% de usuarios con personalizaciones gestionadas manualmente. Al mismo tiempo arrancamos diarios de uso con 3 perfiles reales, acompañados durante todo el proceso desde la web hasta la activación de la SIM.

Los datos cuantitativos eran positivos — la conversión subía y las cancelaciones bajaban. Los cualitativos eran duros:

Un NPS de −100 es fácil de racionalizar cuando las métricas cuantitativas van bien. La tentación era exactamente esa: "el modelo funciona, ya mejoraremos la experiencia". Nuestra posición fue la contraria — que lanzar sobre esa base era aplazar un problema que iba a ser más caro de resolver cuanto más creciera el volumen.

Con los datos de conversión sobre la mesa, negocio quería escalar inmediatamente. La lógica era comprensible: las métricas de fraude y cancelación mejoraban, el canal tenía futuro, había urgencia. Los datos cuantitativos decían que habíamos ganado.

Los cualitativos decían otra cosa. Y la conversación más difícil del proyecto no fue diseñar el modelo — fue convencer al PO y a negocio de que un NPS de −100 no era un detalle a resolver después, sino una señal que podía matar el canal más despacio si no se atajaba antes de escalar. Con los analistas ya teníamos alineamiento; el trabajo fue traducir esos datos en un argumento que negocio pudiera aceptar sin sentir que estábamos bloqueando el lanzamiento.

El modelo web-to-app sigue en producción hoy. No como experimento sino como la forma estándar de vender dispositivos online en Vodafone España.

Quedaron cosas sin resolver: la reserva de stock, códigos de descuento para hacer tangible la espera, una integración más fluida entre web y app. Lo documentamos y lo dejamos listo para la siguiente iteración — sabiendo que el canal, al menos, ya tenía futuro.

El Corte Inglés tiene una sola marca digital, pero la forma en que la gente compra en el supermercado no tiene nada que ver con cómo compra moda o electrónica. Quien busca un abrigo navega, compara, vuelve. Quien compra para la semana ya sabe lo que quiere y lo que necesita es no perder tiempo.

El histórico dentro de El Corte Inglés había sido siempre replicar los comportamientos de la tienda matriz. El trabajo fue argumentar por qué eso no funcionaría y hacerlo de forma que convenciera a negocio y dirección.

Cuando llegué al proyecto, negocio no tenía una métrica clara para el supermercado digital. Había objetivos de venta, pero nada que capturara lo que hace valioso un supermercado online a largo plazo: que el usuario vuelva la semana que viene.

Propuse definir un North Star antes de tomar ninguna decisión de diseño: número de pedidos mensuales de clientes recurrentes. Una métrica que distingue entre alguien que compra una vez atraído por una oferta y alguien que ha integrado el supermercado en su rutina.

No hubo resistencia porque no había nada que desplazar — el vacío hacía que cualquier propuesta razonada tuviera espacio. Lo difícil no fue convencer, sino asumir la responsabilidad de que esa métrica iba a condicionar todas las decisiones de producto que vinieran después.

La estructura que existía reflejaba cómo el negocio organiza su catálogo y cómo se disponen los productos en tienda física — algo que tiene años, que todo el mundo interno conoce, y que nadie había cuestionado formalmente desde el punto de vista del usuario.

Diseñé y ejecuté los estudios de cardsorting y treesting con usuarios reales. Los resultados mostraron dónde la estructura actual generaba confusión, qué profundidad de navegación tenía sentido y qué agrupaciones eran más cercanas al modelo mental de quien compra. La parte más incómoda fue presentar esos resultados a los equipos que llevaban años trabajando con esa estructura — no porque hubiera hostilidad, sino porque cuestionaba algo que para ellos era transparente y para el usuario no.

De ahí salió un sistema de reglas compartido: criterios claros para que negocio pudiera crear y modificar categorías sin romper la coherencia de la navegación.

Además identifiqué la necesidad de hablar el mismo idioma en todos los equipos y nombrar y diferenciar entre categorías de producto — Sección, Familia y variedad —, universos, campañas, promociones y acciones comerciales básicas. Este punto fue clave para jerarquizar y dar forma a todas las necesidades tanto del usuario como de negocio para comunicar correctamente el running de ofertas.

El carrito y el checkout se quedan como webview en esta versión. Es en parte una limitación técnica, pero también fue una decisión de scope: con el tiempo encima y el lanzamiento comprometido, nativizar el checkout habría supuesto varios meses más de desarrollo. Elegimos lanzar con esa deuda antes que no lanzar.

Es algo con lo que no estoy del todo cómoda. Ese momento — cuando el usuario está a punto de pagar — es el más crítico de toda la experiencia, y un webview lo rompe. Lo hemos documentado como deuda conocida con impacto estimado, y está en el roadmap para la siguiente iteración.

Lo que esperamos medir y mejorar con esta versión: