Propuesta de rediseño · NextCaddy

Arquitectura de información para una plataforma de golf con mucho que contar

Rediseñé la web pública de NextCaddy para hacer más fácil encontrar un torneo, entender su estado e inscribirse.

Rol
UX/UI Designer
Dónde y cuándo
2026 · Green Slope
Feedback durante el proyecto
CEO + CTO
Alcance
Web pública desktop y móvil

El problema

NextCaddy reúne información, estados y casuísticas muy distintas. El reto era organizar esa complejidad para que encontrar la información relevante y entender qué ocurre en cada momento resultara más directo y consistente.

La propuesta

Reorganicé la arquitectura de la web y convertí esa complejidad en recorridos, estados de interfaz y componentes reutilizables, manteniendo una lógica coherente entre torneos, momentos y dispositivos.

Arquitectura de información

Una web para jugadores, con un negocio detrás

Los clubes y federaciones publican sus torneos desde un backoffice y los jugadores los consultan en la web pública, donde casi todo vivía en la página de inicio. Los listados de torneos y clubes ya existían, pero se alcanzaban desde puntos concretos del recorrido; en la propuesta pasan a formar parte de la navegación principal.

Lo que publica el backoffice, lo ordena la web

El rediseño se centró en la web pública: cómo organiza la información que clubes y federaciones publican para los jugadores.

  1. Clubes y federaciones

    Contratan el servicio y gestionan sus torneos.

  2. Backoffice

    Torneos, inscripciones, horarios y resultados.

  3. Web pública

    Lo que se rediseñó.

  4. Jugadores

    Se inscriben y siguen resultados.

De una página larga a recorridos más claros

La web analizada y la propuesta tienen listados de torneos y clubes; cambia el nivel en el que aparecen. En la propuesta están en el primer nivel, accesibles desde la navegación principal.

Organización de contenidos

Un Inicio con dos entradas

Inicio concentraba casi todo el contenido. Ahora distingue desde el primer momento entre quien contrata el servicio y quien juega, y lleva a cada uno a su recorrido.

Cada parte de Inicio lleva a un recorrido

La barra de navegación, las dos entradas y los resultados en directo ordenan la página según lo que busca cada usuario.

Página de inicio propuesta, en desktop, con datos de ejemplo.

  1. Una barra con lo esencial

    TORNEOS y CLUBES llevan a sus páginas; CONTACTO, al formulario.

  2. Dos entradas, dos necesidades

    Inicio diferencia desde el primer momento a clubes y federaciones, que contratan el servicio, y jugadores, que lo utilizan. Una entrada lleva a solicitar una demo; la otra, a explorar torneos.

  3. Resultados en directo con contexto

    Los resultados en directo se mantienen en Inicio, pero con más contexto. Cada card indica estado, modalidad, clasificación y jornada, y abre esa misma clasificación en la ficha del torneo.

Navegación y filtros

Encontrar un torneo

Un jugador quiere explorar torneos e inscribirse, pero en la web analizada el buscador solo era útil si ya conocía el nombre. En la propuesta, puede acotar la búsqueda por fecha, federación y disponibilidad.

Un torneo se encuentra sin saber su nombre

Partí de un caso concreto: un jugador tiene libre el fin de semana del 10 y 11 de octubre y busca un torneo con plazas.

Listado de torneos propuesto, en desktop, con datos de ejemplo. La Copa Bécquer del caso aparece con la inscripción abierta.

  1. Una sección propia

    Análisis

    Los próximos torneos vivían dentro de HOY, y el listado completo solo se alcanzaba desde una ficha.

    Propuesta

    Tienen entrada propia en la barra y se clasifican en próximos, en curso y finalizados.

  2. Acotar sin saber qué buscar

    Análisis

    La lista ordenaba torneos por fecha, sin filtros, y el buscador solo servía si ya sabías el nombre.

    Propuesta

    Se ordena por la fecha del torneo y se filtra por fecha, federación, modalidad y disponibilidad.

  3. La navegación no se pierde

    Análisis

    La ficha se abría sin la barra del sitio. Dependía del botón “atrás” del navegador.

    Propuesta

    TORNEOS permanece en la navegación principal y la ficha mantiene una vía de vuelta al listado: migas de pan en desktop y un enlace en móvil.

Estados y reglas

De datos a estados:
la tournament-card

Un torneo combina tres datos que cambian por separado (fase, inscripción y resultados). Definí ocho estados de interfaz a partir de esas combinaciones de datos; cuando coinciden varias condiciones, un orden de prioridad determina cuál mostrar.

Etiqueta, contenido y botón cambian juntos

Cada estado define las tres partes a la vez, así que nunca se contradicen.

  1. Etiqueta

    Nombra el estado; el color solo lo refuerza.

  2. Contenido

    Muestra el dato que importa en ese momento: plazas, cierre, líder o ganador.

  3. Botón

    Lleva a la acción útil: inscribirse, unirse a la lista de espera, seguir el directo o ver la clasificación.

Ocho estados, del anuncio al resultado

Ordenados por el ciclo de vida del torneo.

  1. Antes del torneo · Inscripción aún no abierta

  2. Antes del torneo · Inscripción abierta con plazas

  3. Antes del torneo · Quedan pocas plazas

  4. Antes del torneo · Lista de espera

  5. Antes del torneo · Inscripción cerrada

  6. Durante · Sin resultados aún

  7. Durante · Resultados en directo

  8. Después · Clasificación final publicada

La misma tarjeta de la Copa Bécquer en los ocho estados de interfaz definidos. En la historia del caso solo aparece con la inscripción abierta.

Jerarquía de contenidos

Un torneo cambia con el tiempo

La ficha de un torneo tiene que servir antes, durante y después de jugarlo. En la propuesta, la página es la misma y lo que cambia es qué se prioriza: la inscripción, los horarios, la clasificación en directo o el resultado final.

Lo destacado sigue al momento del torneo

La estructura de la ficha se mantiene, pero en cada fase cambia qué información se prioriza y qué pestaña queda activa.

  1. Antes del torneo · Vie 2 oct, 13:00 · Inscripción abierta

  2. Durante · Sáb 10 oct, 08:45 · En curso, sin resultados aún

  3. Durante · Sáb 10 oct, 12:30 · En directo

  4. Después · Sáb 10 oct, 17:00 · Finalizado

Responsive y accesibilidad

La misma información en cualquier pantalla

En la web analizada, desktop y móvil no contaban lo mismo. En la propuesta, la ficha se reordena en móvil sin perder datos y el estado se entiende sin depender del color. Cada decisión se revisó con WCAG 2.2 AA.

Desktop y móvil cuentan lo mismo

La ficha de la Copa Bécquer en las dos versiones, con las decisiones de responsive y accesibilidad.

Ficha del torneo en desktop: el lateral de inscripción acompaña al contenido.
La misma ficha en móvil. Las migas de pan se sustituyen por un enlace ← Torneos con un área interactiva de 44 px de alto.

Responsive

  1. Mismos datos, otro orden

    Análisis

    Las plazas solo aparecían en desktop al pasar sobre Inscripción, y las categorías solo se veían en desktop.

    Propuesta

    Plazas, cierre, importe y categorías están en las dos versiones; en móvil, por encima de inscritos y horarios.

    Heurística · Consistencia y estándares

  2. El botón, siempre a mano

    Inscribirme queda fijo abajo mientras el bloque de inscripción no está en pantalla.

    Heurística · Flexibilidad y eficiencia de uso

Accesibilidad

  1. El estado se lee, no se adivina

    Análisis

    El estado no se comunicaba de forma consistente entre pantallas: con la inscripción cerrada, desktop seguía mostrando el botón y móvil lo ocultaba.

    Propuesta

    La etiqueta nombra el estado en las dos versiones y el color solo lo refuerza.

    Heurística · Visibilidad del estado del sistema

Flujos e interacción

Inscribirse sin sorpresas

Inscribirse pide datos, categoría, tarifa y pago. La propuesta lo ordena en tres pasos y una confirmación, con un resumen siempre a la vista: torneo, plazas, cierre e importe.

El resumen acompaña todo el proceso

Lucía, con licencia de Madrid, se inscribe en la Copa Bécquer: del primer paso a la confirmación.

  1. Paso 1 · Jugador

  2. Paso 2 · Categoría y tarifa

  3. Paso 3 · Pago

  4. Confirmación

Design system

De la variable al componente

Una propuesta con tantos estados necesita reglas que desarrollo pueda seguir. Construí un design system con variables en tres niveles, componentes con sus estados y una hoja de documentación por pieza.

Cada valor se define una vez y se usa por su nombre

El componente no sabe de colores; sabe de funciones.

  1. Primitivos

    Valores base que alimentan el sistema.

    • color-palettes/lime/500#D4FF14
    • color-palettes/grey/900#0D0D0D
    • spacing-scale/40016

  2. Semánticos

    Qué significa cada valor.

    • color/core/brand/500→ lime/500
    • color/text/on-brand→ grey/900
    • spacing/inset/md→ spacing-scale/400

  3. Componentes

    Dónde se usa.

    • button/primary/default/bg→ color/core/brand/500
    • button/primary/default/text→ color/text/on-brand
    • button/md/padding-x→ spacing/inset/md

  4. Resultado

    El botón, con sus variables aplicadas.

    Inscribirme
Cadena real del botón principal de NextCaddy.

Siguientes pasos

Lo que haría después

La propuesta no llegó a producción ni a testearse con usuarios. Lo siguiente sería validarla, poner a prueba sus reglas y revisar su viabilidad con desarrollo.

  1. Validarlo

    Probaría con golfistas las tareas centrales del recorrido: encontrar un torneo con plazas, entender su estado y completar una inscripción. Observaría errores, dudas y puntos de bloqueo.

  2. Poner a prueba las reglas

    Aplicaría el sistema a más torneos y casuísticas reales para comprobar que los estados, prioridades y componentes siguen funcionando antes de ampliar la propuesta.

  3. Revisar con desarrollo

    Revisaría la propuesta junto a desarrollo teniendo en cuenta la base existente: qué puede reutilizarse, qué restricciones introduce el código legacy y dónde conviene adaptar o replantear la implementación.

Transparencia

Sobre los datos

La propuesta no llegó a producción, así que las pantallas usan datos de ejemplo. Aquí cuento qué es real, qué es inventado y cómo muestro la web analizada.

El proyecto y la marca

Propuesta de rediseño de la web pública de NextCaddy que realicé como UX/UI Designer en Green Slope. NextCaddy, su logotipo y su marca pertenecen a Green Slope y se muestran únicamente para presentar mi trabajo. La propuesta no llegó a producción.

Lo que es inventado

Todos los torneos, inscripciones, horarios, resultados y personas que aparecen son inventados. El Club de Golf La Almazara y la Copa Bécquer no existen.

Lo que es real

Los clubes reales aparecen solo con información pública y verificable. Las federaciones y modalidades de juego son reales. Las cifras de la portada de NextCaddy proceden de su web pública en el momento del análisis.

Cómo muestro la web analizada

Las referencias a la web analizada se muestran como esquemas, sin capturas con nombres, licencias ni otros datos de personas reales.

Referencias

Lo que dice el equipo

Feedback del CEO y el CTO de Green Slope durante el proyecto.

«No es fácil contar con gente con el gusto y la profesionalidad de Lili. Una verdadera suerte trabajar con ella para mí y para todo el equipo.»

Ignacio PérezCEO · Green Slope

«Destacaría especialmente su habilidad para analizar situaciones, comprender las necesidades reales de cada proyecto y aportar ideas con criterio propio.»

Juan Jesús CabreraCTO · Green Slope