CASO DE ESTUDIO · POLICÍA FORAL TRAINING

Cómo construimos una plataforma de entrenamiento que cambia cuando cambia la semana

El punto de partida era personal: preparar unas pruebas físicas durante muchos meses sin que una semana imperfecta inutilizara todo el plan. La aplicación debía recordar el objetivo, pero también entender lo que realmente había ocurrido.

El problema no era encontrar ejercicios

Había entrenamientos disponibles, instalaciones y un objetivo claro. Lo difícil era coordinar carrera, natación, fuerza, movilidad y recuperación mientras cambiaban horarios, molestias, sueño y preferencias.

Un PDF o una hoja semanal podía decir qué tocaba, pero no conectaba el plan con lo completado. Si una sesión se movía, se reducía o no se hacía, el resto de la semana seguía comportándose como si nada hubiera pasado.

Las preguntas que tuvimos que resolver

  • ¿El calendario debía mandar o solo proponer?
  • ¿Cómo diferenciar cansancio normal, falta de tiempo y una molestia física?
  • ¿Qué datos merecía la pena registrar sin convertir entrenar en rellenar formularios?
  • ¿Cómo combinar deportes con cargas difíciles de comparar?
  • ¿Cuándo recomendar una reducción y cuándo mantener el estímulo?
  • ¿Cómo mostrar progreso sin premiar únicamente hacer más volumen?

Cómo lo afrontamos

  1. 1

    Diseñar alrededor de la siguiente acción. La portada debía responder primero a una pregunta: ¿qué hago hoy? Calendario, métricas e historial quedan disponibles sin competir con esa decisión.

  2. 2

    Unir planificación y ejecución. Cada sesión planificada se abre como entrenamiento guiado y, al completarse, actualiza el mismo registro. Se evita duplicar datos entre calendario e historial.

  3. 3

    Añadir contexto antes de adaptar. El check-in recoge solo señales accionables: energía, sueño, molestias y disponibilidad. No intenta hacer un diagnóstico médico.

  4. 4

    Medir lo suficiente. Resultados, percepción de esfuerzo, duración, carga y evaluaciones permiten observar tendencias sin exigir un registro excesivo.

  5. 5

    Probar semanas reales. Movimos sesiones, omitimos entrenamientos y cambiamos preferencias para comprobar si la aplicación seguía siendo útil fuera de una semana perfecta.

Qué cambió durante el desarrollo

De calendario estático a ciclo continuo

El plan dejó de ser una lista semanal y pasó a conectarse con check-in, ejecución, resultados y siguiente ajuste.

De muchas métricas a información accionable

Se redujo el protagonismo de datos que parecían interesantes pero no cambiaban ninguna decisión.

De sesión registrada a sesión guiada

No bastaba con anotar que se había entrenado. La aplicación debía acompañar ejercicio por ejercicio y conservar los resultados.

De adherencia perfecta a flexibilidad controlada

Mover o modificar una sesión dejó de tratarse como fallo. Lo importante pasó a ser conservar equilibrio, recuperación y dirección.

De producto estrictamente personal a base reutilizable

Aunque nació para una preparación concreta, la estructura se generalizó para que un entrenador pueda adaptar deportes, evaluaciones y criterios.

Qué resuelve ahora que está en funcionamiento

  • Muestra la siguiente acción con el contexto de la semana.
  • Permite editar el calendario sin perder el historial.
  • Conecta el check-in diario con recomendaciones de carga.
  • Guía cada sesión y registra resultados por ejercicio.
  • Actualiza progreso, mejores marcas y carga al terminar.
  • Reúne planificación, ejecución y evaluación en un mismo sistema.

Lo que aprendimos

  • Una herramienta personal también necesita decisiones de producto rigurosas.
  • Registrar más datos no significa entender mejor al deportista.
  • La adaptación útil necesita límites claros y supervisión humana.
  • La mejor señal de diseño fue que la aplicación siguiera ayudando después de saltarse el plan.