Gym app check-in, fixing the moving target problem
A small mobile check-in redesign for the frustrating moment when buttons move while options load.
- Context
- UX redesign concept
- Role
- Self-initiated product exercise
- Date
- February 2026
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.
The moment this is about
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.
Prototype
I took screenshots of the real app, wrote the brief with Claude and had Codex build it in planned mode. Within a few minutes the prototype showed both the failure and the fix.
- The tap target stays where it was last time
- State changes without the layout moving
- Nothing removed for people who need the full list
The prototype works best on a phone or in a narrow browser window.
Problem
Every check-in starts with a dynamic list of entrances and gates. As new doors come in range they are inserted into the list, and the existing buttons move. I reach for one and tap another, or wait for the whole list to settle before doing anything.
Not catastrophic, but consistently irritating. At the exact moment you want low friction, the UI behaves like whack-a-mole.
Approach
The app is trading stability for accuracy. The list is always right about what is in range, and never reliable to tap.
I considered three alternatives.
- Fixed alphabetical order, stable but a poor fit for the action everyone uses most, "GYM - Incheckning"
- Most recently used first, personal but still unpredictable over time
- Ordering by time of day, possible and over engineered for this
I went with optional favourites.
You pin the actions you use to the top of the list. A pinned item keeps its place and only changes state.
- Greyed out when out of range
- Active red when available
Everything else still loads below, so nothing is taken away.
What I would validate
This is a concept, not a feature ready to build. If I pitched it to the gym chain I would want three answers first.
- Should favourites follow you between locations, or belong to one?
- Do people understand pinning at a glance, and the change from grey to red?
- Do enough people pin anything to justify the build, and does check-in get faster or more accurate?
It is not a revenue feature. It removes one recurring annoyance, which is sometimes enough.
What could come next
The pattern is a stable layout, clear state changes and the user in control. From there it could grow.
- Suggest a favourite once the same action repeats, such as "GYM - Incheckning" every visit
- Long press to pin or unpin straight from the list
- Different favourites by location or by day
- Rough distance or signal confidence, instead of only grey and red
Tools and timeline
- Claude for the brief
- Codex for the prototype
- Screenshots from the real app
- GitHub and Vercel for deployment
- Around 30 minutes in total, including the screenshots and this write-up








