Gym app check-in, fixing the moving target problem

The short version

The problem

My gym app's check-in buttons move while options load, so you tap the wrong one.

What I did

Prototyped optional favourites. Pinned actions that hold their place and only change state.

What it was worth

A working prototype in about 30 minutes, and a clear list of what I would validate before building it.

The call

Fix the one broken moment. Everything else still loads below, so nothing is taken away.

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 trade-off. Real-time accuracy is prioritised over UX stability. The app is technically correct, but interaction reliability drops.

I considered three alternatives.

• Fixed alphabetical order, stable but a poor priority for common actions like "GYM - Incheckning"
• Most recently used ordering, personalised 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.

• Greyed 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 want three answers.

1. Cross-location behaviour. Should favourites sync globally or be location-specific?
2. Pattern clarity. Do users immediately understand favourites and the shift between inactive and active?
3. Real adoption. Do enough people set favourites to justify the implementation effort, and does check-in get faster or more accurate?

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

The core interaction pattern is a stable layout, clear state changes and user control. Next iterations could include these.

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

• Claude for prompt structuring
• Codex for prototype development
• Screenshots from the actual app
• GitHub and Vercel for deployment
• Around 30 minutes in total, including screenshots and the writeup