TribalScale | Oct–Jan 2025
INTRO
I joined as the sole designer specifically for this project at TribalScale, a software agency based in Toronto that ships 0→1 products for Fortune 500 companies and high-growth startups.
My client was two founders who'd spent 20 years as NFL scouts and contributed to multiple Super Bowl-winning teams. They had a mission: reinvent the scouting profession that hadn't meaningfully changed its tools since the 2000s.
ROLE
Product Designer
TEAM
Product Manager
3 Software Engineers
QA Engineer
TYPE
Mobile Design
Product Thinking
0→1
TOOLS
NFL Scouting workflows hadn't changed in over a decade.
Manual reporting couldn't keep up with the growing player pool.
Data got lost at every handoff between scouts and managers.
Voice-to-text let scouts capture notes hands-free, mid-game.
A 3-step flow matched the scouting framework.
A role-based dashboard closed the loop from field to front office.
Reporting time dropped from an hour to 15 minutes in testing.
Generated 30+ pre-launch demo requests from contractors and management agencies.
Faster capture and easier review improved reporting confidence.
Process
SETTING THE CONTEXT
Scouts we interviewed watch over 500 hours of game footage per season but said more than 70% of their time goes to administrative work rather than the actual evaluation of talent.
Our client already knew they wanted to build a transcription app, since they’d lived this problem as scouts for 20 years. What they needed from us was to validate that hypothesis and figure out if it actually held up once we looked closely at how scouts worked.
Over 12 weeks, my role was to lead design from discovery through MVP and take ownership of UX decisions that nobody else on the team (of mainly developers) was necessarily going to fight for.
THE CHALLENGE
In traditional scouting departments, a front office can process an average of 500 total prospects in a draft cycle resulting in thousands of individual files (source: Bleacher Report).
We conducted structured 1:1 interviews with NFL scouts at different experience levels and an operations manager, to understand how scouting actually happens day to day.
UNDERSTANDING USERS
Working with the founders, we defined our core personas to keep every design decision grounded in real people. This became a rough litmus test to run my user flows through.
THE VETERAN
“I can spot talent in 3 plays, but it takes me 3 hours to explain why.”
Historically has struggled with complex UI despite decades of experience.
OPERATIONS MANAGER
“We lose too much information between scouts and analysts.”
Takes on a more administrative role, significant to information synthesis.
ROOKIE SCOUT
“I live on my phone so if it’s not quick, it slows me down.”
Tech-savvy and mobile-native but still building up evaluation expertise.
INTERVIEW FINDINGS
Conceptually, a scout’s job broke down into a simple 3-step framework.
On the field, scouts would film players and scribble into notebooks or notes app. They’d manually transfer all of it into Excel spreadsheets that stretched into hundreds of columns and multiple pages. These are emailed to an operations manager who compiled everything into Easy Scout Professional, a CRM platform built in 2007.
Over the course of a week, each handoff was a place where information got lost or delayed. These findings informed my artifacts below.
Visual samples of these spreadsheets (actual files ran hundreds of rows across multiple pages).
Mapping every touchpoint where information got lost.
Structuring the touchpoints into one continuous flow.
ITERATIONS
I started with bare wireframes to work out the foundations, so I wouldn't end up building on a weak concept. I ran bi-weekly reviews where I'd bring my design explorations into a shared workspace for non-design teammates to catch misalignment before it turned into rework.
My home screen iterations are the clearest example of this. I'd designed it early on without really testing it against how scouts worked and it didn't hold up once we got feedback.
Scouts didn't want a landing page at all, they just wanted to jump straight into their workflow.
Solution
HOME SCREEN
The original design leaned heavily on a homepage-first structure with activity feeds, but that didn’t reflect how scouts actually use apps and do daily work. Most of the time, they were trying to get straight into a specific team or player to take notes.
I designed around a Teams → Players flow instead to match the 3-step framework that was already established in manual workflow.
PRODUCT DECISION
The original product requirements called for keeping the recording overlay on screen while a scout was capturing notes for branding purposes. In practice, users couldn't see exactly what was being recorded and added to the anxiety of missing details mid-play.
I made the case to remove it as it would defeat the point of the feature which was to fix the errors and missed details that came from manual note-taking.
Before
After
FILTERING
To manage the sheer amount of players scouts work with, I built filtering and sorting (sorting bar shown previously) into a core part of the app.
NFL and NCAA scouts weren't filtering for the same things. NFL scouts care about pro-level metrics and draft stock, NCAA scouts look at a completely different set of criteria tied to college eligibility and conference play.
CROSS PLATFORM LAUNCH
A week of the project was dedicated to a web admin dashboard to let managers review reports and manage rosters to make decisions at scale, basically the back office to the app.
Access worked like a funnel: scouts could only see their own reports > operations managers could see all their scouts and reports > founders had visibility across everything.
Results
RESULTS
Although the MVP shipped after my contract ended, I was able to use the TestFlight prototype with two scouts through the same reporting workflow we'd mapped out before. What used to take about an hour to fully report on a player reduced to around 15 minutes.
If I was there post-launch, some of the metrics I'd want to track:
Time from watching a play to a finished report on actual games
How often scouts fell back to their notebook or phone notes
Transcription accuracy
Drop-off during completed player reports
How much operations managers actually used the compiled reports
If scouts used filtering differently once it was live
LEARNINGS
There was no other designer on the project to check my instincts against, so I had to get comfortable making calls and defending them. That pushed me to actually understand the reasoning behind a design decision well enough to argue for it.
Instead of using diagrams and prototypes solely to present final ideas, I found that I was using them to uncover hidden trade-offs. Building early models helped stress-test assumptions and weed out flawed concepts before development costs piled up.
I didn’t have time to validate everything, so I had to decide which assumptions were risky enough to actually test (like the homepage) and which ones I could move forward on based on research alone. I learned to be aware where I’m spending my limited time.
