One app covering every operation a youth sports nonprofit runs — events, membership, challenges, volunteers, fundraising
Youth Sports Platform
Snapshot
A regional youth sports organization ran six things that had never been in one place: events with capacity and waitlists, membership with recurring annual billing, a youth challenge programme with live leaderboards, volunteer registration and approval, a golf fundraiser with multi-ticket purchase, and donations. I designed one cross-platform application covering all of it — built around a family account, four separate admin roles, and privacy scoped tight enough for an app used by children. The client reported registrations up 43% after launch.
MY ROLE:
Product Designer — UX/UI, design only
TIMELINE:
3 months · Q4 2024 – Q1 2025
TEAM:
PM, BA, project lead, devs, testers
SCOPE:
6 operational areas · 7 user classes · iOS + Android
OWNERSHIP:
Product Designer — UX/UI, design only
STATUS:
Product Designer — UX/UI, design only
The problem
Six operational areas, seven user classes, and a hard rule that children cannot act without a parent approving it.
The organization had never had a single system, and migration from anything that came before was explicitly out of scope — so the new app had to stand up as the one system on day one rather than easing people across.
Three things made it hard beyond its size. Seven user classes, four of them administrative — Super Admin, Members Admin, Clinics Admin and Volunteers Admin each see a different organization. Children cannot act alone — youth can register themselves, but participation requires approval from their registered parent, which is a two-person workflow rather than a permission flag. And admin access is restricted to four designated organizational email addresses, with role determined by which address logs in and no self-service admin creation at all.
3 months
Timeline
Cross-platform delivery as the only designer.
7 roles
User classes
Four admin roles plus volunteers, adults and youth.
2 platforms
Delivery
iOS and Android from one React Native codebase.
4 admins
Access model
Fixed organization email identities, no self-service.
Research
I interviewed 12 parents and 6 admins separately. Parents converged on one sentence: "I need to see all my kids' schedules and payment status in one place." Rather than ask admins how long event setup took, I sat with them and timed it.
The insight that shaped the architecture: operationally different workflows were structurally identical. Submitting a catch, signing up to volunteer and registering for the fundraiser are the same four beats — a form, a review state, an approval, a confirmation. The organization experienced them as unrelated processes because each had grown up separately. As interface, they were one pattern carrying different content.
That is the finding that made the scope reachable in three months with one designer.
How I worked
Six operational areas, seven user classes, two platforms, three months, one designer. Designing screen by screen would not have finished, so the first stretch produced no screens at all.
I mapped every workflow side by side and found the structural repetition above — a small set of layouts covered most of the application once I stopped organizing by feature and started organizing by shape. The seven user classes became variants on those layouts rather than parallel designs. After that, most new screens were a composition decision rather than a design one, and the real effort concentrated on the handful that genuinely resisted the pattern: the live leaderboard, the parent-approval handoff, the waitlist cascade, and the fundraiser's multi-ticket purchase.
I used Claude to synthesize the 18 interview transcripts into an insight map — about two hours of work instead of the two days it takes by hand. What came back was a clean thematic clustering and it was wrong about weighting: it treated every mentioned pain point as roughly equal, which flattened the thing that actually mattered. Three parents described switching between systems as the entire problem and eleven mentioned it in passing, and that read as a minor theme. I kept the clustering, rebuilt the priority order by hand from the transcripts, and the family-as-primary-object decision came out of that correction rather than out of the synthesis.
The honest cost: pattern-first design makes exceptions invisible until late. The multi-ticket fundraiser registration did not fit the layouts I had built, and I found that out in build rather than in design.
Decision 1 — The family is the account, not the person
One login showing every family member, all upcoming events in one feed, consolidated membership status, and children attached to the adult responsible for them.
What I rejected: individual accounts with a linking layer. That is the standard pattern and the inherited data model was shaped for it. I passed because the parent interviews described the problem as switching, and a linking layer preserves the switching. More importantly, parental approval is a legal requirement here, not a convenience — modelling the child as an independent account with a pointer to a parent makes the approval an afterthought. Making the family the primary object makes it structural.
What it cost: a data model redesign, negotiated against a schema the team had already started building.
Decision 2 — Four admin roles, each with its own product
Rather than one admin console gated by permissions, each of the four admin identities gets a dashboard built around what that person actually does: memberships, clinics, volunteers, or everything.
What I rejected: a single admin interface with role-based visibility — the obvious build, and considerably less design work. I passed because the four roles are not tiers of the same job, they are four different jobs. A Volunteers Admin approving signups and a Members Admin reconciling recurring billing share almost no screens. A permission-gated console would have shown each of them an interface mostly full of things they would never touch, and with only four fixed accounts in the entire system there was no scale argument for generalizing.
What it cost: four surfaces to design and maintain instead of one.
Decision 3 — Location scoped to the person and the organizer
Challenge submissions include a map showing where a catch was recorded. That map is visible only to the submitting user and the event admin — never to other participants, never on a leaderboard, never public.
What I rejected: showing locations on shared leaderboards, which is what the challenge format naturally suggests and what makes the competition more engaging. In an app whose users include children, a feature that publishes where a child was standing is not a feature. The engagement value does not survive the question what happens if this is wrong for one kid.
What it cost: the social and competitive dimension of the challenge programme is thinner than it could be.
Beyond the three decisions
Three areas that do not appear in the headline but took real design work.
Recurring membership billing across four fixed tiers — free, adult, youth and family — with prices that do not vary, and a purchased ticket that keeps its price even if the price changes later.
The challenge submission form, which is considerably more than a photo upload: species from a challenge-filtered list, length, weight, lure name, lure weight, lure colour, water temperature and photo evidence — filled in outdoors, often by a child, often one-handed.
Waitlists and capacity, where an event fills, someone drops out, and the next person has to be moved up and told without an admin doing it by hand.
Validation
Event setup was timed with 8 admins before and after, and the new flow was substantially faster — the gain came almost entirely from removing fields that duplicated data the system already held.
The family dashboard tested with 10 parents, all of whom preferred it. That is a weak result on its own; they were being shown the fix for a problem they had just finished describing to me. The admin timing is the finding I would defend.
Parental approval and the scoped map were reviewed against the client's family data protection requirements pre-launch.
Influence, and what outlived the project
The migration plan was a gradual cutover. I argued against it on adoption grounds: for as long as two ways of doing things exist, people choose the one they already know, which is how consolidations quietly die. I worked with the database lead on a data-integrity test plan to show that a hard cutoff was survivable — freeze the old way on a date, ship ahead of it, require migration by go-live. It went that way instead, and it removed months of parallel-running overhead from a team that did not have the capacity to carry it.
What outlived the project was the privacy default. Scoping location to the person and the organizer started as a compliance answer and became the thing the organization led with when talking to parents — the position turned out to be worth more than the engagement features it cost.
The second thing that stuck was designing by shape rather than by feature. Once the team could see that a volunteer signup and a challenge submission were the same four beats, new requests stopped arriving as new screens and started arriving as new content in an existing pattern.
Outcomes
Shipped one cross-platform application covering six operational areas and seven user classes, to both app stores from a single React Native codebase.
As reported by the client following release: registrations up 43%, admin event setup materially faster when timed with 8 administrators, and privacy review passed pre-launch with no privacy incidents reported.
Learnings
Consolidation is an organizational intervention wearing a UI. Once the data lived in one place, operations could answer how many active families do we have for the first time. Nobody had asked for that.
Privacy defaults are positioning. Parents are tired of apps that harvest. Defaulting to scoped cost engagement features and bought trust, and trust was the scarcer resource for this audience.
Designing by structure scales; designing by feature does not. A small set of layouts covered most of the app. The exceptions took most of the time, which is the correct ratio.
What I'd do differently
I would bring admins into design iteration in week one instead of testing with them near the end. They surfaced edge cases — multi-location events, scholarship tracking — that I had not anticipated, and the fixes landed in UAT with no room left to absorb them.
And I would distrust the pattern earlier. Designing by shape was the right call, but I treated it as settled once it worked, which is exactly why the fundraiser's multi-ticket flow reached build before anyone noticed it did not fit.