Jonas ForshellSenior Product Owner
jonas@jforshell.seEmail me
Case · Exercise

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.

Before
Before, moving targets. After, stable favourites with clear availability states.
  • The tap target stays where it was last time
  • State changes without the layout moving
  • Nothing removed for people who need the full list
View live prototype →

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.

Gym app searching state before entrances load
Early state, scanning starts and options begin to appear.
Gym app list changing as options load
Mid state, more options load and push the targets down.
Gym app final list with all options loaded
Late state, the list has settled once loading finishes.
View full 8-screen sequence
Gym app check-in list showing the Bluetooth searching state before any entrance is detected
Step 1
Gym app check-in list showing a single entrance, Entre, after the first Bluetooth match
Step 2
Gym app check-in list showing three entrances, Entre and two pass check-in doors
Step 3
Gym app check-in list reordered to four entrances as a new sluice door is detected
Step 4
Gym app check-in list showing six entrances including two accessibility doors
Step 5
Gym app check-in list showing seven entrances after the main gym check-in door appears
Step 6
Gym app check-in list showing eight entrances after a second accessibility door appears
Step 7
Gym app check-in list settled at eight entrances once Bluetooth scanning finishes
Step 8

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.

  1. Should favourites follow you between locations, or belong to one?
  2. Do people understand pinning at a glance, and the change from grey to red?
  3. 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