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. I led design for over a year, from the first release to full rollout.
MY ROLE:
Sole Product Designer — UX/UI
TIMELINE:
3 months · Q4 2024 – Q1 2025
TEAM:
PM, BA, project lead, devs, testers
SCOPE:
6 operational areas · 7 user classes · iOS + Android
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.
The Constraints
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 parents and 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 on anonymized interview notes to build 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. A few parents described switching between systems as the entire problem and most others mentioned it in passing, and that read as a minor theme. I kept the clustering, rebuilt the priority order by hand from the notes, 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.
How I used AI
Wireframes: I generated early layout options with Figma AI, UX Pilot and kept the strongest 2–3 for review.
Design system: I used AI to scaffold tokens (colour, type, spacing) and base components. I then set the rules, variants and states myself.
What AI didn't do: product decisions, trade-offs and final UI. Those stayed human.
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.
Design system
I built a mobile component system for this project: tokens for colour, type (Poppins) and spacing, plus core components with variants and states (stat tiles, event cards, challenge cards, leaderboard rows). AI scaffolded the first pass, and I defined the variants for each user role and the documentation the developers built from.
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: a multi-field outdoor submission with measurements 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
I timed event setup with 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 well with parents. 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.
After launch, I guided a junior designer through follow-up screens such as inner pages and pop-ups, and reviewed each one against the shared components.
Outcomes
Shipped one cross-platform application covering six operational areas and seven user classes, to both app stores from a single React Native codebase, and stayed on as lead designer for over a year after the first release.
Families now see every child, event and payment in one place, and admins set up events through a flow that reuses data the system already holds. Parental approval and location privacy were reviewed against the client's family data protection requirements before launch. Client performance metrics are confidential.
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.