LDP (librodepases)

Contexto

LDP es una plataforma SaaS que centraliza datos de rendimiento y estadísticas avanzadas para que los equipos de scouting de clubes de fútbol profesional tomen mejores decisiones. Cuando llegué en 2022, el producto existía: había código, había usuarios, había datos. La empresa quería potenciar la usabilidad de las nuevas herramientas con AI, y ahí entré yo.

El equipo venía tomando decisiones de diseño de forma deliberada, pero la escalabilidad era necesaria. Los clubes no usaban tanto la plataforma, no porque no fuera buena, sino porque había que potenciar la facilidad de uso, el acceso a la información y, principalmente, habilitar una personalización real en el uso.

El gap que cubría era real: clubes de primera y segunda división que no podían pagar herramientas europeas como Wyscout, pero necesitaban algo más estructurado que planillas de Excel compartidas por WhatsApp. El producto tenía la lógica correcta. La interfaz los obligaba a adivinar dónde estaba cada cosa.

El problema

Los scouts pasaban demasiado tiempo armando una lista de candidatos para una posición. De los que arrancaban el flujo, la mayoría lo abandonaba antes de llegar al tercer jugador. Los datos estaban ahí — el problema era que la interfaz no dejaba claro cómo usarlos ni cómo gestionar tanta información de forma práctica, para todos los usuarios, incluso los que no tenían conocimientos técnicos.

El dato que más impactó en las primeras semanas fue la cantidad de reportes manuales descargados. Pagaban la plataforma pero la usaban como etapa intermedia hacia Excel, perdiendo días de trabajo. Cuando liberamos la generación automática, con un par de clicks tenían un reporte completo, visualmente claro, con gráficos y métricas.

Approach

Dos principios guiaron los tres años:

Los scouts no buscan — deciden. Cada pantalla tenía que responder “¿qué decisión toma el scout con esto?”, no “¿qué datos tiene disponibles?”. Si una métrica no ayudaba a decidir, sobraba en la vista general.

La velocidad es accesibilidad. Un scout en una tablet en el banco de suplentes, con lluvia y 30 segundos para tomar una nota, no puede lidiar con dropdowns de ocho niveles. Velocidad de tarea = accesibilidad en contexto real.

Decisiones clave

Iniciativa 1 — Dashboard de scouting

Reemplazamos el listado plano de jugadores con un dashboard orientado a shortlists activas. Los datos mostraban que la mayoría de las sesiones eran de seguimiento —usuarios volviendo a jugadores ya vistos—, no de descubrimiento. Guardamos el descubrimiento para un flujo dedicado. El tiempo de tarea de “actualizar el estado de un jugador” se redujo drásticamente.

Iniciativa 2 — Comparador de jugadores

El pedido original era “agregar una vista de comparación”. Lo que construimos fue diferente: un sistema donde los benchmarks son el promedio de la posición en el contexto competitivo del club, no valores absolutos.

La decisión clave: no mostramos números sueltos. Mostramos porcentajes según equipo, torneo, partido y rival. Un porcentaje de pases exitosos no significa nada sin saber cuál es el promedio de esa posición en esa liga. Cambiamos la unidad de visualización de “valor” a “diferencia respecto al benchmark”.

Iniciativa 3 — Design System v1/v2

Después de 18 meses diseñando componente por componente, el producto tenía cuatro versiones distintas del mismo dropdown y tres formas de mostrar un badge de estado. Paramos el feature work seis semanas para construir el sistema.

La decisión más difícil: diseñar en Figma en paralelo con el Storybook de Frontend. Un sistema que vive solo en Figma genera drift constante entre lo documentado y lo implementado. Construimos los componentes en Figma, se documentaban en Storybook, y el sistema pasó a ser referencia real para cualquier composición.

Seis meses después del lanzamiento, el tiempo de implementación de nuevas features bajó de forma significativa.

Iniciativa 4 — UI de Recomendaciones AI

La incorporación del modelo de recomendaciones fue el cambio más significativo del producto. Lideré el proyecto y diseñé cómo presentar las sugerencias sin que parecieran una caja negra que el scout no puede cuestionar.

La tensión: mostrar el “por qué” de cada recomendación vs. no sobrecargar con justificaciones que el usuario no pidió. Resolvimos con progressive disclosure: la recomendación aparece simple, con un “ver fundamentos” que expande el razonamiento del modelo para quien quiera profundizar.

Lo que descartamos: un score de compatibilidad como porcentaje. Los primeros prototipos lo tenían como titular de cada recomendación. Lo eliminamos porque generaba falsa precisión y desplazaba la atención del jugador al indicador, en lugar del razonamiento detrás.

Solución

El producto actual tiene múltiples módulos nuevos. Los más relevantes: el dashboard de shortlists activas, el explorador de jugadores con filtros contextuales y el perfil de jugador con reporte descargable automático y comparación entre rivales posicionales.

El flujo principal —ir de “necesito un extremo derecho menor de 23 años para préstamo” a tener cinco candidatos documentados— hoy toma una fracción del tiempo que tomaba al inicio, sin importar cuánto conociera el scout la plataforma.

Impacto

• Tiempo promedio de research: se redujo de forma significativa tras el rediseño del dashboard principal
• Completación del flujo de candidatos: mejoró considerablemente tras reorganizar la navegación y el dashboard
• Retención mensual de clubes: mejoró de forma sostenida tras el rediseño del dashboard
• Dependencia de Excel: se redujo drásticamente — el indicador más honesto de adopción real
• Base de clubes activos: creció de forma continua durante los tres años

La plataforma pasó de ser “la herramienta que usamos porque no hay otra” a ser la que el equipo de scouting defiende en las reuniones de presupuesto.