Designing Traksta
a workout app for people who lift.
It gives people who train with weights a plan and clear progress, without hiring a coach. I led design and product on a two-person team, from first idea to closed testing.
A full workout app, from onboarding to paywall, designed and shipped to closed testing by two people. AI tools made screens quick to produce, so most of my work was catching mistakes in them and deciding what not to build.
The problem
Most workout apps give everyone the same fixed programme. When it doesn't fit, people start over in another app and lose their history.
What I did
Led design and product: the brand, the data model, the design system, every screen and prototype, and decisions on what to build first and what to cut.
The method
Built the design system first. Then, for each flow: prototype in Claude Design, test with peers, revise, and hand the developer working HTML instead of static mockups.
Limitations
The app isn't in the stores yet, so there are no usage numbers. There was no formal user research: the user profiles come from my own training and app reviews. The evidence comes from peer testing.
Log your workout in seconds,
see what's working
Traksta is a workout log for people who train with weights. Logging takes seconds, and the app reads your training back to you: what's improving, what's stalled and what you're skipping.
Logging happens between sets, one-handed. Every tap counts.
- Remembers your last session, so most sets take one tap.
- No program needed. Open, log, close.
- Free, with no limit on workouts or history.
A log only helps if the app reads it back to you.
- A Monday review: one win, one thing to watch, one next step.
- Flags stalled lifts and under-trained muscles.
- No numbers without enough data behind them.
One developer, no budget,
and a full app to build
AI tools let me design and prototype a working flow in a day, so producing screens was never the problem.
The real work was checking each screen for mistakes and deciding what not to build.
AI-generated screens look finished, but they break in predictable places. Every bug found in testing was in a first-use, confirmation or error state, not in the main flow.
With one developer, every feature took weeks of our only build time. Deciding what not to build mattered more than polishing the design, and every change after handover cost more than getting it right first.
One developer, part-time, no budget. Developer capacity was the hard constraint on everything else.
A full app, not one flow: twelve areas plus a Pro subscription and paywall.
iOS and Android, built by one developer from the same HTML designs.
The app had no users yet, so nothing could rely on ratings, popularity or recommendations.
Both kg and lb, defaulting to the user's region, since users are in more than one country.
Peer testing showed plan schedules had to work differently. Fixing it mid-build meant reworking the plan library, plan detail and home screens.
Two types of user,
with different needs
Intermediate lifters
Train three to five times a week, already running their training out of a spreadsheet or notes app. They know volume, estimated 1RM and progressive overload.
They drop apps that treat them like beginners or make logging slow.
Beginners on their first plan
They want a plan chosen for them, and they quit the moment something confuses them.
Designing for their first session drove most of the key decisions.
This is a side project, so there were no formal interviews. The profiles come from my own training and from complaints in fitness app reviews and forums. Peer testing the prototype gave the real evidence, and it changed the product.
Design, test, hand over,
then repeat for every flow
There was no product manager and no second designer. The process had to keep decisions clear, screens consistent and the developer unblocked.
I did three things in order, then repeated the last one for every flow. The developer got working HTML instead of static mockups, so he didn't have to guess how screens behave.
List every screen and define the data
- What I did
- Before designing anything, I listed every screen and the data each one needs. Exercises have a name, muscle group and equipment. Plans have a goal, level, days per week, length, muscles, equipment and a weekly schedule.
- Why
- A screen takes minutes to redo. A wrong data model breaks everything built on it, and the developer finds out last.
- Result
- Screens fit together because they all used the same data. The data model became the spec for both the prototype and the build.
I only half did it. Plans and exercises were well defined, but the weekly schedule wasn't. That gap caused the worst bug in the project.
Build the design system before the features
- What I did
- Built the Traksta design system (tokens and components) in Claude Design before designing any feature screen, and set it up so the developer could build against it directly.
- Why
- Without a system, AI tools create a slightly different button every time you ask. The system keeps generated screens consistent, not just fast.
- Result
- Screens stayed consistent without me checking each one, and the developer had one reference to build from.
Design, peer test, hand over HTML
- What I did
- For each flow, I prototyped it in Claude Design using the system, tested it with peers, revised it, then handed the developer the finished HTML. Later changes went through the same steps.
- Why
- With a static mockup, the developer has to guess how things behave, and guessing causes rework. Working HTML shows the behaviour. It also let me test each flow before using any developer time.
- Result
- He built from a working prototype, not a spec. Rework stayed low, and our disagreements were about product decisions, not what a screen meant.
Hand the developer working HTML built against the shared design system, rather than static screens and a spec.
Static mockups with notes, the usual handoff. I ruled it out because the developer would have to guess every state I hadn't drawn, and with one developer that guessing is expensive. With HTML, the open questions were mine to answer, not his.
Two rounds of testing,
and what they changed
I tested twice: on the prototype before any code was written, then on the built app. The first round changed how Add Exercise works. The second found three bugs a prototype couldn't have shown.
Round one: Add Exercise moved to its own page
Testers couldn't find the exercise they wanted. Add Exercise opened as a bottom sheet over the plan builder, showing only a few rows of a very long list. Adding search and filters inside the sheet left even less room for results, so every fix inside the sheet made it worse. I moved it to its own page with search and filters.
Search and filters squeezed into the sheet leave room for only a few results.
Search, filters and many more results on screen. Fixed before any code was written.
Move Add Exercise onto its own page with search and filters, sized to the actual library.
Keeping the bottom sheet and tidying the list. I ruled it out because the sheet was too small for the content. Bottom sheets suit a short list of options, not searching a large library. I chose the pattern before knowing how much it had to hold.
Round two: three bugs in the built app
Testers used the built app through their first week. Three bugs came up, all in the same kind of place.
A new user's first session was a rest day
Plan schedules were tied to weekdays. A user who started a plan on a Sunday opened the app to a rest day, with nothing to do in their first session.
Plans now start on the day the user starts them, not on a fixed weekday.
Saving a plan gave no confirmation
Tapping Save gave no feedback, so people tapped it twice or thought it had failed.
Save now confirms, then returns to home with the new plan active.
An error message that didn't help
The Workouts tab showed “Couldn't load your data” and a Try again button, with no reason and no other option.
Fixed the loading bug, and rewrote the message to say what went wrong and what to do.
All three were in first-use, confirmation and error states. AI-generated designs handle the main flow well and tend to miss these.
Removing star ratings
that had no data behind them
My plan card designs showed star ratings and save counts, because plan cards usually do. But the app had no users, so there was no rating data.
People trust ratings. Showing one with nothing behind it is a made-up number, and every new plan would need one too.
This is easy to miss with AI tools: the card looks finished whether the data exists or not.
Remove ratings and save counts. Show only real facts: goal, level, days per week, duration, muscles and equipment.
Building a rating system. I ruled it out: it would use our only developer's time, and there were no users to rate anything yet. The cards got simpler and more useful.
I checked every other screen the same way, asking what real data sits behind each element, and removed a few more things. It also saved the developer the time a rating system would have taken.
Releasing in stages,
to small groups first
With two of us, a big launch would bring more feedback than we could act on. Small groups keep it to what one developer can fix. Better to find the next bug like the rest-day one with 20 users than with 5,000.
Closed testing
Running now. Small enough that one developer can act on every piece of feedback.
Beta
Includes 100 early users with a free year of Pro, so they keep using the app past week two, when most testers drop off.
Wider marketing
Paid social, community posts and outreach to fitness coaches, all pointing to the website and from there to both app stores.
Grow the tester group only as fast as we can fix what they find.
A waitlist once the beta reached 500. I dropped it: it creates fake scarcity for an unproven product, and it turns away early users whose feedback we need.
Results,
and what I learned
Traksta isn't in the app stores yet, so there are no usage numbers to share. Here is what got built, and what the process caught before users did.
A full working app, built by one developer in weeks rather than months, because he never waited on a spec.
One design system used by both my prototypes and his build, which answered most of his questions up front.
A staged rollout now running: 20 testers per platform, then a beta of 200 to 500, then wider marketing.
AI-generated designs miss edge cases
The main flows worked. What broke was first use, confirmations and errors, the moments that decide whether someone comes back. I now design those states first.
Check the content before choosing a pattern
Add Exercise started as a bottom sheet because that's the usual pattern. The exercise library was far too big for it.
With one developer, saying no is most of the job
Every feature cost weeks of our only developer's time, and every change after handover cost more than getting it right first.
Only show data you actually have
I added star ratings to plan cards out of habit, with no data to fill them. With AI tools, a screen looks finished whether the data exists or not.
Define all the data before the first screen
I defined plans and exercises but not the schedule. That gap caused the worst bug: new users opening the app to a rest day.
Traksta is in closed testing now. I'm happy to walk through the data model, the HTML handover, or what I chose not to build.
Let's talk.
Get in touchSee also the AI-Assisted Data Mapping case study, where I designed how people review AI suggestions.