Personal project · UX case study

PureGym Swiss App — redesign

Introduction

In April 2025 PureGym removed live occupancy from its app. What followed in the reviews wasn’t a complaint about convenience — members had lost the thing that told them whether a visit was worth making.

Role

Solo Project

Year

2026

Tool

Figma, Framer

Methods

/Review analysis

/competitor analysis

Problem

Year

2026

Tool

Figma, Framer

Methods

/Review analysis

/competitor analysis

Problem

The app averages 1.63 out of 5. Reviews naming the removed occupancy indicator start in April 2025 and don't stop. PureGym's website still advertises the feature the app no longer has.

It was the most frequent complaint across 100 reviews: not convenience, retention.

The app averages 1.63 out of 5. Reviews naming the removed occupancy indicator start in April 2025 and don't stop. PureGym's website still advertises the feature the app no longer has.

It was the most frequent complaint across 100 reviews: not convenience, retention.

A gym is a subscription business. The number that predicts cancellation is visit frequency. A member who shows up, finds the place packed, and has a bad session is less likely to come back, so members who drop below roughly one visit a week are the ones who cancel. The occupancy feature existed to prevent exactly that. Removing it didn’t make the app less pleasant; it removed the mechanism that protected attendance, which is the mechanism that protects revenue.

Website: Advertising Feature

App: Feature Missing

Research and discovery

100 App Store reviews and 6 comparable apps, analyzed to answer one question:

is the occupancy complaint an annoyance, or a pattern?

100 App Store reviews and 6 comparable apps, analyzed to answer one question:

is the occupancy complaint an annoyance, or a pattern?

Goals

- Understand user pain points

- Identify gaps in the current experience

- Discover patterns across fitness app experiences

- Understand user pain points

- Identify gaps in the current experience

- Discover patterns across fitness app experiences

Method

I read all 100 reviews first to get oriented, then used Claude to run keyword-based theme coding across the dataset. The first pass produced false positives like "about" matching "abo" (subscription) so I refined the method with word boundaries and manually reviewed flagged results. I guided and validated the analysis throughout, checking the outputs against the actual review text rather than accepting them at face value.

Reviews

100

corrected

43→35

after removing false matches

Top Theme

35%

Occupancy removed

35%

Confusing UI/navigation

13%

App crashes/bugs

11%

Login/account access

Review highlights

26 Mar · AppStore User

Confusing and unnecessary

Unfortunately, the app is very confusing—too many menus, and it’s easy to get lost. Plus, the promised occupancy data isn't displayed either...

Occupancy removed

6 Jul · AppStore User

Make the app useful again

Why did they remove two essential items from the app that was the occupation and the training guide?

Occupancy removed

24 Aug · AppStore User

Occupancy rate

They removed the occupancy rate function, which was the only useful and unique function of this app

Occupancy removed

Review highlights

Comparative &

pattern analysis

Comparative &

pattern analysis

Alongside direct competitors, apps not in the fitness category were reviewed for how they solved individual problems well. A search across what worked and what didn’t.

Direct competitor

High5 Gym

Navigation, booking

No live occupancy. Booking buried two levels deep.

Direct competitor

McFit

General app functions

No live occupancy. Entry code requires manual lookup.

Adjacent

Strava

Onboarding, goals

Goal selection before account creation.

Adjacent

Nike Training Club

Personalization

Shows a tailored result before asking to register.

Cross-industry

SBB Ticket App

QR scanning flow

Intuitive navigation. Scan reachable in one tap.

Cross-industry

Swica

Account verification

Clear step feedback during identity checks.

Limitations: n=100, Apple App Store only — a self-selecting sample that skews toward complaints.

Limitations: n=100,

Apple App Store only — a self-selecting sample that skews toward complaints.

Insight & design principles

Three findings, each turned into a rule the design had to obey. Each is written so it can be broken — a principle that can’t be violated isn’t doing any work.

Answer the question before the app opens

Occupancy gets checked before leaving the house, not on arrival. That makes it a pre-decision, and a pre-decision behind a tap is one members check once and then stop checking. It belongs on the first screen with no interaction required. This is what put the card on the home screen rather than leaving it behind the Live tab.

Answer the question before the app opens

The most frequent action gets the shortest path

Check-in happens every visit; everything else in the app happens occasionally. Frequency, not importance, decides what sits in reach. Scanning moved to a raised centre button in the navigation, thumb height and one tap from anywhere.

The most frequent action gets the shortest path

Show the value before asking for the commitment

Personalization data collected during onboarding now comes first and pays off immediately with a matched class, so the registration ask arrives after the value has been demonstrated rather than before.

Show the value before asking for the commitment

UX process

The occupancy screen — from a number to an answer

UX process

The occupancy screen — from a number to an answer

The first version showed everything at once — a ring, a full-day chart, best times, a breakdown by gym area. All accurate, none of it prioritised. The second grouped it into cards and gave the number a plain-language reading, and the area breakdown was cut: no per-zone sensors exist, so it couldn't be honest. The final version gives every card one job and one conclusion. The reading sits beside the number, the best window comes with a reason, the comparison states the delta, and a last-updated line makes the live number something you can act on.

First version

Second version

Final

Onboarding sequencing

Personalization data is collected before the registration ask, and its value, a matched class recommendation, is shown immediately after. This reorders the typical "register first, personalize later" pattern: users see what their data bought them before being asked to commit.

→

Choose 3 Goals

→

Fitness level

→

see your match

→

Create account

Final solution

Three changes: occupancy where the decision gets made, check-in where the thumb already is, and onboarding that sets expectations before the first visit.

Home screen — occupancy card

The answer arrives without being asked for. No tab, no tap, no menu — the card is the first thing on the home screen, because occupancy gets checked before leaving the house, and anything that costs a tap is something a member checks once and then stops checking.

Live tab — the full picture

The card answers “now”; the Live tab answers “when”. Best time to go, today against yesterday, and a timestamp so the number can be trusted. The card was never meant to replace this screen — it removes the need to open it for the common case.

Occupancy card — states

The card has to answer “should I go now” even when there is no number to give. Four states, so the answer is never a blank space.

Gym Entry

Check-in is the most frequent thing a member does in the app, and it sat behind a menu. Swica's insurance app puts the equivalent action in a raised centre button at thumb height, reachable from anywhere. I adopted the pattern directly — it solved a problem I'd otherwise have solved worse.

Onboarding

Onboarding wasn't a review theme. It came from the comparative analysis, where Strava's overloaded flow and Nike Training Club's more fundamentals-first approach showed both ends of the range.

Choose 3 Goals

Fitness level

see your match

Create account

Expected impact

Nothing here shipped, so nothing here is measured.

What follows is what I'd measure and what would prove me wrong.

Nothing here shipped, so nothing here is measured.

What follows is what I'd measure and what would prove me wrong.

Hypotheses, not measured results. One baseline comes from my own research; the other two would require PureGym's internal analytics.

Occupancy

Baseline:

35% of negative reviews cite occupancy; rating 1.63/5.

Prediction:

those complaints drop below 10% and pre-visit opens rise.

Falsified if they persist after the feature returns — removal was never the driver.

QR/Entry

No baseline available.

Entry support volume and time-to-scan are PureGym-side data.

Prediction:

fewer entry contacts, faster average scan.

Falsified if scan time is flat: reach was never the bottleneck.

Onboarding

No baseline available.

Registration completion is PureGym-side data.

Prediction:

completion rises, since value is shown before the ask.

Falsified if flat or lower: the added steps cost more than they earn.

Reflection

The strongest input was treating 100 App Store reviews as qualitative data rather than a pile of complaints, and tightening the coding method once the first pass overstated the findings. If scope allowed more work, app crashes and stability (11% of reviews) would be the next priority.

What I'd do differently

— Moderated usability testing, rather than relying solely on review-mining

— Broader review sourcing (Google Play next to direct competitors) for a more representative sample

— Access to PureGym's actual changelog to confirm, not just infer, the occupancy removal timeline

The real limitation: I worked from public reviews, not from PureGym's support tickets or churn data, which is exactly the data that would confirm or kill my central argument.

Socials

Navigation

Socials

Navigation

Closing

A missing feature turned out to be a measurable business problem, not a complaint to be managed. That reframe is the part of this project I'd carry into the next one.

What this case study can't do is close the loop. Every number in Expected impact is a prediction, not a result. The work I want next is the kind where the change ships, the metric moves or fails to, and I find out whether the argument actually held.

Socials

Navigation

Socials

Navigation

Choose 3 Goals

Fitness level

see your match

Create account