Gestión de Deuda UX a Escala
Contexto y Desafío
Adevinta Spain opera productos digitales de larga trayectoria como Coches.net, InfoJobs, Fotocasa y Milanuncios, algunos de ellos activos desde hace más de 20 años. Años de entrega continua entre múltiples equipos y plataformas llevaron inevitablemente a la acumulación de inconsistencias de UX: interfaces fragmentadas, patrones de interacción desiguales, brechas de accesibilidad y un declive en la calidad percibida.
Aunque los equipos eran conscientes de muchos de estos problemas, no existía un lenguaje compartido, un modelo de ownership ni un framework operativo para abordarlos. El UX debt existía, pero era invisible, no se trackeaba y se despriorizaba sistemáticamente en favor de la entrega de nuevas features.
El reto era hacer el UX Debt explícito, gestionable y parte de la toma de decisiones normal de producto, sin ralentizar la entrega.
Mi Rol
Como Director de UX, lideré esta iniciativa a nivel de compañía.
Mi responsabilidad abarcó:
- •Definir una definición compartida y pragmática de UX debt
- •Alinear a los líderes de producto, diseño y ejecutivos en torno al problema
- •Integrar la gestión de UX debt en los workflows existentes de delivery y priorización
- •Asegurar la sostenibilidad a largo plazo mediante visibilidad, reporting e incentivos
Qué hicimos
Definir UX Debt
Empezamos creando una definición clara y estricta para evitar ambigüedad y mal uso.
UX debt se definió como: problemas de experiencia de usuario conocidos que impactan negativamente a los usuarios y permanecen sin resolver a lo largo del tiempo.
Igualmente importante fue definir lo que UX debt no era. Excluimos explícitamente:
- •Nuevas features basadas en necesidades validadas de usuario
- •Bugs técnicos (gestionados a través de procesos existentes)
- •Problemas de rendimiento (considerados deuda técnica)
- •Iteraciones planificadas de features — a menos que se pospusieran durante más de dos trimestres, momento en el que se convertían en UX debt
Esta claridad ayudó a los equipos a distinguir entre trabajo de product discovery, problemas técnicos y genuina deuda de calidad UX.
Categorizar UX Debt
Para asegurar consistencia entre equipos y productos, establecimos un modelo de categorización compartido:
- •User Interface: inconsistencias visuales y componentes desalineados
- •Interaction Design: falta de reutilización de patrones de interacción establecidos
- •Information Architecture: problemas estructurales y de navegación
- •Content: tono, claridad o mensajes inconsistentes
- •Accessibility: contraste, semántica, navegación por teclado, soporte de lectores de pantalla
- •Cross-Channel Experience: desalineación entre web, apps nativas y otras plataformas
Esta categorización nos permitió analizar patrones, identificar problemas sistémicos y mover la conversación más allá de problemas de UI aislados.
Operacionalizar UX Debt
Para pasar de la teoría a la acción, el UX debt tenía que vivir donde los equipos ya trabajaban.
Introdujimos UX debt como un tipo de issue dedicado en Jira, alineado con el tracking existente de deuda técnica. Se pidió a los diseñadores de todos los equipos de producto que documentaran sistemáticamente los problemas de UX conocidos que cumplieran la definición.
Para apoyar la priorización, creamos un calculador de prioridad de UX debt, ayudando a los equipos a evaluar impacto versus esfuerzo y evitar centrarse solo en los "quick wins".
A nivel de liderazgo, acordamos un compromiso concreto: cada equipo de producto resolvería un número fijo de issues de UX debt por trimestre. Aunque no era perfecto, este acuerdo creó responsabilidad e hizo el UX debt visible en las conversaciones de planificación.
Sostener el momentum a través de la visibilidad
Sostener la iniciativa requería visibilidad y refuerzo continuos.
Nos enfocamos en tres palancas:
- •Comunicación regular: el UX debt se reforzaba consistentemente a través de ceremonias de UX, canales de Slack y foros de liderazgo.
- •Reporting a nivel ejecutivo: el progreso de UX debt se incluía en las revisiones mensuales de producto, junto con la entrega de roadmap y KPIs. Esto posicionó la calidad UX como una preocupación de negocio, no solo de diseño.
- •Dashboards compartidos: un dashboard de Jira hacía transparente la creación y resolución de UX debt entre productos, equipos y mercados.
También celebramos activamente a equipos y diseñadores que hicieron progresos significativos, reforzando el comportamiento positivo y la responsabilidad compartida.
Por qué fue importante
Esta iniciativa cambió la forma en que los equipos pensaban sobre la calidad UX a escala.
- •El UX debt se hizo explícito en lugar de invisible
- •Los trade-offs de calidad se convirtieron en decisiones conscientes
- •La salud del producto a largo plazo pudo equilibrarse con la entrega a corto plazo
Al tratar el UX debt como una preocupación de primer nivel, los equipos pudieron mejorar la consistencia, la accesibilidad y la calidad percibida sin sacrificar velocidad.
Más allá de los números, el resultado más importante fue cultural. El UX debt reenmarcó la calidad como algo que los equipos gestionan activamente, no algo a lo que reaccionan cuando los problemas se vuelven críticos.