Written by:
Biarnés, Adriana
Published on:
PRODUCT DESIGN
UX ANALYSIS
MOBILE APP
UX DESIGN
CLIENT
Symmetry
PRODUCT
Strength training app with workout logging, AI coaching and social rankings
AUDIENCE
Lifters at every level, from never trained to advanced
STAGE
Live product, activation problem
DURATION
1 week
MY ROLE
Product Designer · Data analysis, hypothesis and prototypes
Challenge
Symmetry came to me with one number and a question.
Around 50% of users who start their first workout log zero sets. They open the app, they tap Start, and then nothing happens. No weight, no reps, no checkmark. They leave the session empty.
They wanted three options on the table, not one recommendation. So the first job was working out what was actually breaking, because the wrong diagnosis produces three wrong options.
The data pointed somewhere specific immediately. Completion was not flat across the user base. It sorted almost perfectly by experience:
Experience | Completion | Equipment | Completion |
|---|---|---|---|
Advanced | 54.77% | Commercial gym | 53.63% |
Intermediate | 53.61% | Small gym | 49.67% |
Beginner | 49.71% | No equipment | 48.18% |
Never trained | 44.82% | Calisthenics | 48.00% |
Ten points separate someone who has trained for years from someone who has never trained at all. The drop-off is inversely proportional to experience: the less the user knows, the more likely they are to leave.
I have trained for years, and from the inside it is easy to forget how much that costs a beginner. Anyone who has spent time in a gym carries a pile of tacit knowledge. They know what each machine does, roughly how many reps belong in a set, a bit of anatomy. None of that is visible, and all of it is what lets you look at a table of weight, sets and reps and immediately know what to do. A new lifter has no reason to have that map.
Equipment tells the same story from a different angle. A commercial gym has machines and variables worth tracking, so logging weight and reps is genuinely useful for progression. Calisthenics is the opposite: bodyweight, few resources, a minimal approach. That user leans toward a fast, essential log, focused on getting the movement rather than the detail. Same product, two different needs, and one screen serving only one of them well.
Both patterns say the same thing. If the user already knows how to log a set, they stay. If they don't, they go.
Approach
I worked the problem as three questions.
What is blocking the user? A screen that doesn't tell them what to do. Tapping Start lands them on a control panel: timer, muscle map, Guide / Replace / Delete, an exercise carousel, an AI button, and a table with a grey 0 and a checkmark that already looks ticked. Six things shouting at once, and no signal about the next step. The concrete friction is that at the exact moment of logging, there is no single obvious action. The user stares at it, and leaves, because they came to train and not to work out an interface.
Why is it happening? "Start workout" promises one thing and delivers another. It promises the app will take you through it. It delivers a dashboard that only makes sense to someone who already knows how to log. Two layers in the same instant: a broken expectation, and overload with no hierarchy. Without an obvious primary action, the inexperienced user stalls.
Why this hypothesis and not the others? I had four candidates:
A. The component confuses. The control itself, the grey
0and the pre-ticked checkmark, doesn't make clear what to tap to count a set.B. Broken expectation. "Start" promises guidance. The user doesn't expect to fill anything in, they expect to start training.
C. Overload. Too many elements competing at once with no primary action to lead, because the hierarchy is weak. Delete is the most prominent button on the screen.
D. The exercise intimidates. The first exercise scares a beginner who may not know the jargon, may not have that machine where they train, and may not know how to use it.
The data settles it. The drop-off is inversely proportional to experience, and that rules A and D out as the main cause. Neither depends on how experienced the user is: the component is identical for everyone, and experienced lifters are already familiar with it. An intimidating exercise would hit beginners far harder than experts, which makes it a patch rather than a cause.
What does vary with experience is arriving with the mental model to know what to do. Since the outcome tracks experience so closely, the variable deciding who completes is not the control and not the exercise. It's that mental model. When it's missing, what fails is the guidance: the expert covers the gap with what they already know, the beginner can't. That's B and C together. Broken promise, plus overload with no clear action.
Diagnosis: it isn't that the user doesn't know how to train. It's that the screen doesn't tell them what to tap. And that is a design decision: guided by default, depth on demand.
Solution
Three experiments against the same problem, at three levels of intervention, from least to most invasive. A copy change, a guide layered over the current screen, and a restructure of the flow. They are independent: each can be tested on its own, and the winner can be combined with the rest.
Shared metric: percentage of users who log a complete first set, meaning weight plus reps plus the checkmark.
1 · Expectation reset · copy only. One line when the first set opens: "Every set counts. Log the weight and the reps, then tick when you're done." It tells the user what is expected of them at the moment they need to know. It attacks the broken promise and needs no design. Guardrail: that the line doesn't slow logging down or read as clutter people leave over.
2 · Guided path · flow. Pick a preset workout or build your own, then everything dims except one action: weight, reps, tick, step by step. It delivers on the promise of guidance and removes the overload. Guardrail: that the guidance doesn't become friction of its own. It shouldn't slow the path to the first set, nobody should drop out mid-tutorial, and an expert has to be able to skip it.
3 · Logging as the path forward · structure. Instead of one screen holding everything, one set per screen. The user sees only the set in progress and a "Next" CTA that activates once the data is in. Logging stops being optional and becomes the way to advance.
Screen 1: one set, plus "Next".
Screen 2: set 1 completed and marked green, set 2 waiting, "Next" again once it's filled.
Helper microcopy above the CTA: "Log the set to continue."
So a beginner isn't blocked by not knowing what weight to enter, fields arrive with a suggested value prefilled, either the previous session's or a recommended one. Completing becomes confirming rather than filling in from scratch. Scoped to the first workout and to beginners, since an expert will most likely change it anyway. Guardrail: that forced progression doesn't increase abandonment, that the prefilled value doesn't generate junk data, and that experts aren't slowed down.
This is the one I recommended. It attacks B and C by restructuring the flow rather than guiding over the top of it, it serves the business goal of more engagement, and it serves the beginner who needs the guidance most. Experiments 1 and 2 stay on the table as lighter, faster tests.
On top of whichever experiment wins, gamification can be layered: points for completing a first workout, wired into the Get Started Challenge that already exists. It keeps Symmetry's DNA, the rankings and the social layer, without contaminating the base experiment.
How I would measure it: an A/B against the current flow, with enough users and enough time to trust the result is real and not noise. A minimum of one to two weeks, to cover the full weekly training cycle.
Results
The team confirmed they were already moving in the direction of experiment 3, building logging into the flow instead of leaving it as an optional action on a crowded screen. Arriving at the same structural answer from the outside, from the data alone, was the useful part.
What the work produced was the argument, not just the screens. Four plausible hypotheses, narrowed to one by asking which of them could explain why the failure scales with inexperience. Three options priced by how much they cost to ship, so the team could pick its level of risk instead of being handed a single take-it-or-leave-it redesign. And a way to tell whether any of it worked.
When completion sorts by how much your user already knows, the screen isn't confusing. It's assuming. Guided by default, depth on demand.
