Cognitive Efficiency in Complex Roster Systems

Team Builder needed to operate across two major use cases:

Both groups shared a critical pain point: LeagueApps' core product lacked a fluid, visual interface for bulk moving players between teams, viewing roster capacities, or filtering players by skill, position, or evaluation metrics.

Internally, the project sat at the intersection of several initiatives — registration, evaluations, and member experience — primarily in the soccer space. Soccer is one of LeagueApps' most profitable verticals, and the lack of a roster-building experience was a major source of customer churn.

Admins are making decisions that can trigger registration invitations, cancel existing registrations, invalidate previously sent invites, and affect payments, invoices, and player expectations. The core problem was not "how do we move players" — but how do we give admins speed and flexibility without letting them accidentally cause irreversible outcomes they don't fully understand?

The original roster management workflow had five critical gaps:

This was not a greenfield redesign. The solution had to coexist with significant constraints:

Many "obvious" UX proposals — like a single unified invite manager or universal undo — were intentionally deferred to avoid introducing technical risk or misleading users about what actions were truly reversible.

Defining the key mental models. Through discovery and ongoing feedback, it became clear that admins approach roster building with different mental models — often within the same session:

The system, however, must distinguish between moves (same-program changes), invites (cross-program actions), and draft assignments vs. committed actions. A major design goal was to make the system's interpretation of admin intent visible and predictable — without forcing admins to think in system terms.

Defining the MVP. I collaborated with my product manager and engineering manager to phase the rollout:

Key Design Decisions & Tradeoffs

Invitation Lifecycle & Guardrails. To reduce ambiguity, players in Team Builder clearly surface one of several states:

Collaboration & Implementation. We maintained a cadence of biweekly feedback sessions tailored to different audiences: design, engineering, customer success, and leadership. A key internal debate emerged around the default state of Team Builder: should users start with an empty interface or a populated set of teams?

I facilitated a journey mapping exercise that revealed admins typically created teams before entering Team Builder. This led to the final decision: display the ten most recently created teams by default, giving Rec admin users immediate context without overwhelming them. Club programs only ever created 3–5 teams, so they'd only see what they needed.

Engineering collaboration was close and constant. We conducted "boxing" sessions to create detailed mappings of design elements to backend APIs, annotating every prototype for handoff. Auto-save wasn't feasible for MVP, so I introduced a destructive modal to prevent accidental data loss when navigating away — and proposed auto-save as a fast-follow enhancement.

The final Team Builder experience allows admins to view and filter available players across programs, assign players to teams via drag-and-drop, see immediate status feedback (move vs. invite needed), review pending actions in a dedicated slide-out, send invitations in a controlled and intentional way, and manage sent invitations — resend or revoke — without losing context.

Crucially, it does this without attempting to replace the legacy Invite-to-Join tool, instead carefully defining the boundary between draft planning and finalized execution.

Customer Feedback

Critical feedback surfaced important future work: