Sports Talent Platform
A professional sports team knew they needed a digital scouting tool and had partner funding waiting. What they didn't have was a shared idea of what the tool actually did, who would use it, or what "MVP" meant. I ran a ten-day discovery with two partner organisations and walked out with wireframes that could carry into build.
My Role
// What I personally ownedUX lead and UI designer. I co-ran discovery with the client and their technical partner, facilitated the workshops, and owned everything from flows to final prototype.
The Problem
// Why this needed to existThe brief was loose by necessity: coaches and scouts needed a digital tool to evaluate athletes, but nobody had pinned down who would use it, which decisions it should support, or where the MVP should stop. Two partner organisations were also involved, and each had arrived with a slightly different mental model of what we were building.
The ten-day window made it impossible to chase certainty. The real job was getting enough shared language and shape in place that a developer could credibly start from our output.
Discovery to prototype
Role
Unlocked next-phase investment
Key Design Decisions
// What I tried, what I changed, whyRole-based information architecture
No defined user roles. Scouts, coaches, and admins were treated as a single user type despite fundamentally different jobs and information needs.
Defined clear user roles with different access levels and information surfaces. Same data, different views and permissions — defined in flows before any UI was touched.
Why: Scouts, coaches, and admins spend their day on completely different tasks. Trying to design one shared view would have produced a generic feed that none of them actually used.
Recruitment progression as a linear tracker
No way to track where each candidate was in the pipeline. Stakeholders had to open individual profiles and cross-reference manually.
Visible status rail (New → Contacted → Interview Scheduled → Assessment → Contract) at the top of each athlete profile. Pipeline status visible without opening any sub-page.
Why: The pipeline is the thing people open the app to check. Making it visible on the profile removed the most common navigation step and gave the team something scannable to point at during scouting meetings.
Information density without overwhelm
Athlete profiles needed to show personal details, performance results, season data, role scores, scouting comments, and recruitment status — but no design existed.
Typographic hierarchy, grouping, and collapsible sections to prioritise information visually. Everything visible, nothing overwhelming.
Why: Scouts need a lot of data at a glance. The answer isn't hiding anything — it's stacking it in an order the eye can scan, so the important bits land first.
Outcomes & Validation
// What I can point to- MVP scope landed in a place both partner orgs signed off on
- Wireframes carried straight into the build plan without a second design phase
- Development funding was approved for the next phase on the back of the prototype
- The shared product vocabulary stuck around after discovery ended
Screenshots and client name are withheld under NDA. Visuals available upon request during interview process.