El contexto de uso manda
Pantalla a distancia, una mano libre como mucho, conexión inestable y poco tiempo. Todo el diseño parte de ahí, no de una galería de pantallas bonitas.
Las pantallas, de un vistazo
01 · Contexto y problema
Entrenar con pesa rusa no es el problema. Seguir, sí.
KETTELBRO nace de una pregunta de producto: ¿cómo pasa alguien de un reto de 30 días a un hábito de entrenamiento sostenido, sin pensar qué toca hoy?
Según el documento de producto del repo, las personas a las que va dirigida vienen precisamente de un reto de 30 días, entrenan en casa o en un gimnasio pequeño con una a tres pesas rusas, y usan el teléfono mientras entrenan: con las manos con magnesia o sudadas, el móvil apoyado a metros de distancia y entre 10 y 45 minutos como mucho. Las apps genéricas de fitness suelen darles una lista de rutinas «inventadas», sin explicar por qué están ahí.
Falta de criterio, no de rutinas
El posicionamiento declarado: un motor de programación determinista basado en protocolos documentados (Hardstyle, Girevoy Sport, periodización ondulante, RPE) en el que cada bloque puede citar su respaldo.
Honestidad como restricción
Nada de «tonificar» ni quema garantizada de calorías: las afirmaciones de salud se limitan a lo que la literatura respalda. Es una restricción de diseño, también para el copy.
Qué no sé (y no invento). El repositorio declara explícitamente que no hay testimonios, usuarios ni métricas reales. Por eso este caso habla de decisiones y de hipótesis, no de resultados de negocio.
02 · Usuarios y necesidades
Tres proto-personas, cada una con su fuente.
No hice entrevistas para esta versión. Estas proto-personas son una síntesis de lo que dicen PRODUCT.md, la FAQ y el motor de rutinas del repo; sirven para decidir y están marcadas como hipótesis hasta validarlas con usuarios reales.
La retadora que no quiere parar
Terminó un reto de 30 días y no quiere volver a decidir cada mañana qué hacer. Necesita que alguien decida por ella y que la racha no se rompa por perder un día.
Fuente: Users en PRODUCT.md; «el día avanza al completar» en MOTOR-DE-RUTINAS.md.El del garaje con la pesa sudada
Entrena con una o dos pesas, con mala luz y el móvil lejos. Necesita números enormes, un toque, sonido y vibración y poder retomar si cierra la app a mitad de sesión.
Fuente: Operating Context en PRODUCT.md; borrador de sesión activa en la arquitectura de datos.La principiante prudente
Nunca ha tocado una pesa rusa y duda de su espalda. Necesita progresión sin swings al inicio, técnica a la vista y un cribado de salud, no promesas.
Fuente: FAQ de la landing (primeros 14 días sin swings; modo de cuidado lumbar).Necesidades que se convirtieron en requisitos
- Leer de lejos: texto y contadores grandes, controles amplios, feedback sonoro y háptico opcional.
- Confiar: ver por qué toca cada bloque y qué estudio lo respalda, con su nivel de evidencia y sus límites.
- No perder nada: el historial vuelve igual al entrar con Google, incluso offline o a mitad de sesión.
- Tener poco tiempo: sesiones de 10, 15, 20 o 25 minutos, con calentamiento incluido.
03 · Principios de diseño
Cinco reglas que desempatan.
El repo las enuncia como principios de producto. Las uso como criterio para explicar cada decisión de este caso.
1
La ciencia es el motor, no el adorno
Cada bloque puede explicar por qué está ahí.
2
El historial es sagrado
Entrar con Google devuelve el estado exacto, offline o a mitad de sesión.
3
Durante la serie manda la mano ocupada
Legible a distancia, un toque, feedback sonoro y háptico.
4
Distinto cada día, nunca aleatorio
Variedad con intención fisiológica.
5
Progreso visible y honesto
Logros reales derivados de datos reales.
04 · Flujo y arquitectura de información
Entrar, decidir poco, entrenar mucho.
El flujo principal tiene cuatro pasos, y el segundo («cuéntanos de ti») se hace una sola vez. A partir de ahí, cada día es: abrir, ver la tarjeta, empezar.
- Entrar con Google
- Perfil: nivel, meta, tiempo, pesas, salud
- Hoy: tarjeta del día
- Sesión guiada
- Cómo fue (RPE y sensación)
- Ajusta el día siguiente
Arquitectura de información
La estructura sale de las rutas del repo (src/app). Hay una capa pública, pensada para que se pueda indexar y entender sin cuenta, y un área privada con cuatro destinos fijos en la barra inferior.
Público ├─ / landing: propuesta, cómo funciona, ciencia, FAQ, instalar ├─ /ciencia 74 referencias con diseño de estudio y nivel A-D └─ /guias técnica, pesos y rutinas Privado (tras Google) ├─ /bienvenida alta del perfil ├─ Tab bar: Hoy · Progreso · Metas · Perfil (+ /pesas) └─ /sesion acompañante en vivo, a pantalla completa
Decisión de IA: cuatro destinos, no seis. El día de hoy es la pantalla de aterrizaje; todo lo demás es consulta o ajuste. La sesión en curso queda fuera de la barra para que ninguna pestaña compita con el reloj.
Cómo se decide el contenido de «Hoy». El motor es puro: Día N → fase del mesociclo → enfoque del día → bloques → pasos. La semilla es UID + número de día, así que recargar o cambiar de teléfono da exactamente la misma tarjeta.
05 · Decisiones UX/UI
Cada decisión, con su porqué y lo que descarté.
Las alternativas descartadas son las que el repo documenta o las que se deducen directamente de una restricción escrita. Cuando es una lectura mía, lo indico.
Una tarjeta por día, no un catálogo de rutinas
Qué
Hoy muestra una carta con el número de día, el enfoque, el ejercicio principal y la prescripción. El mes es un plan que se va marcando.
Por qué
Quita la decisión diaria (principio 4) y convierte el progreso en algo visible, sin lista infinita.
Descartado
Una biblioteca de rutinas para elegir. Es lo que hacen las apps genéricas y reintroduce la fatiga de decidir.
Rutina determinista, no aleatoria
Qué
Semilla = UID + número de día. El mismo día da la misma sesión en cualquier dispositivo; cada usuario rota los ejercicios en su propio orden.
Por qué
Confianza y testabilidad: el motor es puro y se prueba con vitest. Variedad con intención, no azar.
Descartado
Generar al azar cada vez. Rompe la recuperación entre dispositivos y no se puede explicar «por qué hoy».
Sin botón «ya terminé»: la app lleva el tiempo
Qué
Cuenta atrás por serie, repeticiones marcadas por cadencia y cronómetro de descansos. Al final, una pregunta: qué tan duro fue.
Por qué
Con las manos ocupadas no se pulsan botones (principio 3). El RPE final alimenta el ajuste del día siguiente.
Descartado
Pedir confirmación serie a serie. Obliga a soltar la pesa y a tocar una pantalla pequeña en pleno esfuerzo.
Sesiones de 10, 15, 20 o 25 minutos, y nada más largo
Qué
Cuatro duraciones, máximo 25. Los ajustes antiguos de 35 o 45 minutos pasan automáticamente a 25.
Por qué
Es una apuesta por la adherencia. Respaldo indirecto citado por el propio producto: un meta-análisis de fuerza en general asocia una serie por ejercicio, una a tres veces por semana, con ganancias de fuerza.
Descartado
Sesiones de 35 a 45 minutos, que PRODUCT.md aún contemplaba. Se recortaron al afinar el motor.
El día avanza al completar, no por calendario
Qué
«Día N» es el N-ésimo día del programa del usuario. Perder un día no salta bloques ni castiga.
Por qué
Protege la motivación de quien falla un día y mantiene el orden fisiológico de los patrones de movimiento.
Descartado
Un calendario rígido de lunes a domingo, que convertiría cada ausencia en un hueco en el plan.
Solo acceso con Google
Qué
Un toque, sin contraseñas; popup en escritorio y redirección en móvil o PWA cuando el popup falla.
Por qué
Cero contraseñas que custodiar y fricción mínima. El historial viaja con la cuenta.
Descartado
Email y contraseña, y acceso anónimo en producción. El repo los excluye de forma explícita.
Ciencia visible, con sus límites
Qué
Cada bloque puede mostrar su estudio, su diseño y un nivel de evidencia de A a D. Hay una página pública con una lista de lo que NO se promete.
Por qué
La evidencia específica de pesa rusa es pequeña; decirlo genera más confianza que exagerar (principio 1).
Descartado
Cifras de calorías exactas, «tonificar» o «mejor que correr». El propio sitio explica por qué no.
Descartar una sesión exige mantener pulsado
Qué
El botón de abandono llena una barra durante 1,6 s; si sueltas antes, vuelve en 200 ms. Con teclado basta Enter o Espacio.
Por qué
Evita perder una sesión por un toque accidental con las manos sudadas. Lento mientras decides, rápido cuando el sistema responde.
Descartado
Un diálogo «¿seguro?» con dos botones juntos, fácil de acertar sin querer (lectura mía a partir del comentario del código).
Rediseño completo del sistema visual: de «Lotería de Hierro» a «Rendimiento nocturno»
Qué
Se sustituyó un sistema con papel, grano, rayos y temática de lotería por grafito casi negro, blanco frío y una tinta eléctrica por enfoque.
Por qué
DESIGN.md conserva la mecánica (una tinta por enfoque, una tarjeta por día, un mes que se marca) y «pierde la nostalgia». Mi lectura: un fondo oscuro y números grandes encajan mejor con garajes con poca luz.
Descartado
El sistema anterior: papel crema, grano, frijoles, palabras de lotería. Hoy son reglas explícitas de «no hagas».
06 · Sistema visual
Rendimiento nocturno: una tinta por día.
Grafito casi negro, blanco frío para el texto y una sola tinta eléctrica (la del enfoque del día) que pinta la tarjeta, el reproductor y los acentos.
Color
Potencia#f2432d
Fuerza#2a4de8
Resistencia#00a878
Híbrido#ffb41f
Técnica#ff5fa2
Recuperación#4fc9e8
night#0b0e14
night-2#121722
night-3#1b2230
seam#2c3649
paper#f4f6fa
paper-mute#8392aa
Regla de la tinta: es el único color saturado de una pantalla; no se mezclan dos tintas en la misma superficie (el mes, con una barra por día, es la excepción informativa). Cada tinta trae su par --on-ink para que el texto encima sea legible: negro sobre potencia, blanco sobre fuerza.
| Enfoque | Tinta | Qué trabaja |
|---|---|---|
| Potencia | Bermellón | Balístico de cadera |
| Fuerza | Cobalto | Empujes, tirones, sentadillas, bisagras lentas |
| Resistencia | Jade | Series largas e intervalos |
| Híbrido | Caléndula | Complejos |
| Técnica | Rosa | Get-up y control |
| Recuperación | Aqua | Flujos suaves; mantiene la racha |
Tipografía
Display · Barlow Condensed 800
Peso muerto
Titulares, nombres, botones. Condensada, cursiva, mayúsculas.Numeral · Anybody variable
8 × 8 kg
Cuentas atrás, reps y kilos. El eje--heat engrosa y estrecha los números con el esfuerzo.Cuerpo · Barlow 400
Cadera atrás y espalda larga: la pesa se levanta sin queja ni carga.
16 px mínimo en lectura; nunca en cursiva.Componentes con la web real
- Tarjeta del día: campo de tinta con profundidad, número inclinado 8°, etiqueta del enfoque en píldora oscura y banner con el nombre, que se encoge hasta caber en una línea.
- Tu mes: rejilla de 4 × 7 casillas; hecha = tinta con visto; hoy = tinta con aro; futura = grafito con una barra de la tinta de ese día; semana completa = pastilla «Semana completa».
- Reproductor: campo completo de la tinta; el escenario con el personaje es lo primero que se ve (al menos el 40 % del alto), con fases 1·2·3 y vistas de lado, de frente y en tres cuartos.
- Hojas y navegación:
<dialog>que entra y sale por el mismo borde; barra inferior de cuatro destinos con píldora de tinta tras el icono activo. - El Bro: la pesa con cara aparece en cargas, vacíos y celebraciones, para que los estados «sin contenido» también tengan voz de marca.
Nota sobre las capturas. La app privada requiere cuenta de Google y yo no creé ninguna para este caso. Las pantallas internas (Hoy) son las capturas que el repo publica en su README; las públicas (landing, ciencia, FAQ) las hice yo sobre la web real, en móvil 390 px y en escritorio.
07 · Microinteracciones y estados
El movimiento sirve a la serie, no al adorno.
Cuenta atrás con pulso
En los últimos tres segundos el número late (tick-pulse); al cambiar, hace un pequeño pop. El tamaño es fluido: entre 72 y 120 px según la altura de la pantalla, para leerlo desde lejos.
Números que se engrosan
El eje --heat de la tipografía variable cambia peso y ancho: más esfuerzo, números más densos. La cuenta de trabajo usa el valor máximo; el descanso, uno bajo.
Mantén pulsado para salir
El relleno lineal de 1,6 s deja tiempo para arrepentirse. Si sueltas antes, vuelve en 200 ms: la respuesta del sistema es rápida y la decisión del usuario es lenta.
Sonido, voz y vibración opcionales
Pitidos (WebAudio), voz (SpeechSynthesis) y vibración, cada uno apagable. Los navegadores exigen un gesto previo, así que el audio se inicializa en el primer toque de Empezar.
Estados que no dejan en blanco
Pantallas dedicadas para carga (Splash), carga lenta (SlowHint), error (LoadError) y navegadores integrados de apps (InAppBrowserNote), donde el acceso con Google puede fallar.
Retomar a mitad de sesión
La sesión activa se guarda como borrador. Si cierras la app, vuelves donde la dejaste; el cierre final se escribe en un único writeBatch, que funciona offline.
Todo el movimiento respeta prefers-reduced-motion (referenciado en las hojas de estilo, la figura 3D y la celebración). La regla de diseño es explícita: nada de destellos rápidos.
08 · Confianza y copy
Convertir la evidencia en interfaz.
La ciencia no es un párrafo escondido: se muestra como etiqueta de nivel, cita corta y diseño del estudio. Y se acompaña de una lista de lo que no se promete.
Tono de coach cercano
El repo fija una voz «bro», directa y motivadora, con la ciencia como respaldo y no como sermón. La landing mantiene términos claros: «pesa rusa» como principal y «kettlebell» como sinónimo.
Copy que se puede comprobar
El texto público limita las promesas a lo que cita (por ejemplo, que correr exigió más oxígeno que 10 minutos de swings a igual esfuerzo percibido) y avisa de los casos donde no hay grupo de control.
09 · Accesibilidad y rendimiento
Solo lo que he podido comprobar.
Lighthouse en la web real
Una ejecución mía (Lighthouse 13.5.0, móvil, 23 de octubre de 2026, desde mi equipo) sobre la portada: accesibilidad 100, buenas prácticas 100, SEO 100 y rendimiento 63, con LCP de 7,5 s simulados, CLS 0 y TBT 0 ms.
Una sola medición con throttling simulado; no sustituye a datos de campo.Diseño pensado para contexto adverso
Botones del reproductor de 44 px (h-11 w-11), números fluidos de hasta 120 px, aria-live asertivo solo en la cuenta atrás y apagado en el resto, aria-label y aria-pressed en los controles de salir y silenciar.
Contraste declarado
DESIGN.md indica que el gris de apoyo sobre night-2 alcanza 5,6:1, y define no depender solo del color ni del sonido para transmitir información.
Lo que no he medido
No probé la app privada con lector de pantalla ni con un dispositivo real en un gimnasio. El rendimiento de la sesión (3D, audio, voz) está sin medir por mí.
10 · Stack y decisiones técnicas
Poca magia: un motor puro y una caché local.
| Tema | Decisión | Motivo |
|---|---|---|
| Framework | Next.js 16 (App Router), React 19, TypeScript, Tailwind 4 | Landing renderizable en servidor para SEO; app como PWA. |
| Backend | Firebase Auth + Cloud Firestore (SDK modular) | Sin servidor propio; caché offline persistente y cola de escrituras integradas. |
| Datos | Subárbol users/{uid}/… | Reglas de seguridad triviales (request.auth.uid == uid). |
| Offline | persistentLocalCache + service worker de caché mínima | El gimnasio tiene mala cobertura; la app debe abrir y registrar sin red. |
| Cierre de sesión | writeBatch atómico | Una transacción exige conexión; un batch no. |
| Motor | Funciones puras con tests en vitest | Determinista, probable y válido en cliente, servidor o sin red. |
| Personajes | Figuras 3D (three.js) con pipeline de Blender y validador de GLB | Mostrar la técnica de lado, de frente y en tres cuartos. |
| Modo demo | LocalRepository detrás de una variable de entorno | Previsualizar la UI sin Firebase; nunca en producción. |
El acceso a datos va detrás de una interfaz Repository con dos implementaciones (Firestore y localStorage), lo que permite diseñar y probar la UI sin backend.
11 · Aprendizajes y próximos pasos
Lo que aprendí y lo que haría ahora.
Qué funcionó
- Escribir PRODUCT.md y DESIGN.md primero: cada decisión posterior tiene un criterio contra el que medirse.
- Tratar la honestidad científica como un requisito de UX, no como un aviso legal.
- Un motor puro: se puede razonar y probar sin abrir la app.
Qué corregiría
- Una promesa a conciliar: la landing dice sesiones «exactas», pero el repo anota que el código estima la duración dentro de un margen. Hay que medir y ajustar el texto o el motor.
- Rendimiento de la portada: el LCP de mi medición es alto. No he aislado la causa; lo primero sería auditar la imagen y las tipografías del hero.
Próximos pasos (hipótesis a validar)
- Validar con usuarios reales: 5 o 6 sesiones de entrenamiento observadas para comprobar la legibilidad a distancia y el uso con una mano. Hoy no hay datos.
- Mantener la pantalla encendida: en la búsqueda que hice en el código no encontré uso de la API Screen Wake Lock; en una sesión con el móvil apoyado a metros, es candidata clara.
- Medir adherencia: definir qué significa «volver cada día» (el éxito declarado) antes de añadir analítica.
- Resolver los pendientes legales: la propia landing marca privacidad, términos y canal de contacto como decisiones abiertas.
Pruébala
Tu primera sesión te espera.
La landing, la ciencia y las guías son públicas. Para entrar a la app hace falta una cuenta de Google.