Gym App Check-In: Fixing the Moving Target Problem

Redesigning a gym app's mobile check-in flow to solve the frustrating "moving target" problem where buttons shift position as options load dynamically.

I have used my gym's app for years, and this interaction has always been the same: open the app, wait for Bluetooth to detect nearby doors and gates, then rush to tap "GYM - Incheckning" before the list changes.

I used screenshots of the real app behaviour, then worked with Claude for prompt structuring and Codex in planned mode for rapid implementation. In a few minutes, the prototype demonstrated both the current failure mode and the favourites-based fix.

BeforeAfter

• Fixed tap target location for repeated check-ins
• State changes without layout shifts
• No functionality removed for broader use cases

This prototype works best on mobile or in a narrow browser window.

Every check-in starts with a dynamic list of entrances and gates. As new options come in range, items are inserted into the list and existing buttons move. I would reach for one target and tap another, or wait for the full list to settle before acting.

Not catastrophic, but consistently irritating. At the exact moment you want low friction, the UI behaves like whack-a-mole.

View full 8-screen sequence

The core issue is a tradeoff: real-time accuracy is prioritized over UX stability. The app is technically correct, but interaction reliability drops.

I considered alternatives:

• Fixed alphabetical order: stable, but poor priority for common actions like "GYM - Incheckning"
• Most recently used ordering: personalized, but still unpredictable over time
• Time-based smart ordering: possible, but over-engineered for this problem

The chosen solution is optional favourites.

Users can pin frequent actions to the top of the list. Favourited items keep a fixed position and only change state:

• Grayed out when out of range
• Active red when available

Everything else still loads dynamically below, so no functionality is removed.

This is a concept prototype, not a production-ready feature. If I pitched this to the gym chain, I would validate:

1. Cross-location behaviour: Should favourites sync globally or be location-specific?
2. Pattern clarity: Do users immediately understand favourites and the inactive/active state shift?
3. Real adoption: Do enough people set favourites to justify implementation effort, and does check-in speed/accuracy improve?

I do not see this as a major revenue driver, but it addresses a real recurring frustration.

The core interaction pattern is stable layout + clear state changes + user control. Next iterations could include:

• Smarter defaults: Suggest favourites after repeated behaviour (for example, repeated "GYM - Incheckning")
• Faster favouriting: Long-press to favourite/unfavourite directly in the list
• Contextual favourites: Different favourites by location or day pattern
• Proximity indicators: Show rough distance/signal confidence, not only inactive/active state

• Claude (prompt structuring)
• Codex (prototype development)
• Screenshots from the actual app
• GitHub + Vercel (deployment)
• Total time: ~30 minutes including screenshots and writeup