ClubSphere
A self-initiated product story about the invisible work behind football: scouting notes, lineup changes, fitness questions, academy context, and the small decisions that shape a team before anyone steps on the pitch.
Context and brief
Football clubs do not only run on tactics. They run on half-remembered scout notes, messages sent between training sessions, injury updates that arrive late, and coaches trying to make good decisions with whatever information is closest at hand.
I designed ClubSphere as a concept for regional and local football organizations, using youth soccer clubs in Central Florida as the grounding context. The challenge was to help small staffs coordinate scouting, readiness, and lineup decisions while preserving the fast, informal rhythm they already work inside.
The question I kept coming back to was simple: what would change if coaches, scouts, and staff could see the same version of the truth before match week started to move?
All player and staff names shown in the concept screens are fictional.
The problem
At the semi-professional and youth-development level, club operations often depend on a patchwork of PDFs, Word docs, spreadsheets, messaging apps, and whiteboards. None of those tools are bad on their own. The problem is what happens between them.
A scout sees potential, but the note lives in one place. A coach is building a lineup, but availability lives somewhere else. Medical risk, performance history, and academy development all matter, but they rarely arrive together at the moment a decision is being made.
That made the design constraint less about storing more data and more about surfacing the right evidence at decision time. The product had to feel calm, move quickly, and remain realistic for a small staff to maintain.
Too many apps to manage
One solution
How I got there
Because this was a self-initiated concept, I grounded the early direction in conversations with two people from a local Orlando club. Their perspectives helped me pressure-test the product from opposite sides of match week: the scout capturing context in short bursts, and the coach trying to act on it later.
Player Scout
The scout is watching players in motion. If capturing a note takes too long, the moment is gone. The workflow needs to be quick enough to disappear between observations.
Head Coach
The coach is preparing a team while the picture keeps changing. The workflow needs to make uncertainty visible before it becomes a match-day surprise.
Journeys
Approach
I started with the moments that repeat every week: checking who is ready, comparing players, preparing a lineup, capturing a scouting report, and sharing context with someone who was not in the room.
With three weeks and no access to live club data, I treated the work as a focused workflow hypothesis, not a finished platform. I stayed close to two connected roles and the decisions that pass between them. Scheduling, messaging, payments, and club administration stayed outside the scope. They could make the product broader, but they would not help answer the central question.
My first instinct was to organize the system entirely around departments. Instead, I used functional areas as stable homes and placed the Squad Hub at the center, allowing readiness, scouting, lineup planning, and analytics to connect without becoming one dense workspace.
Proposed information architecture
The proposed architecture gives each discipline a dependable home without forcing coaches and scouts to reconstruct the player story as they move between tasks. Squad Hub remains the common overview, while reports, status updates, performance summaries, and match records synchronize back into shared player and team context.
Workflow targets
Bring player selection, ratings, observations, and submission into one scouting flow.
Let coaches review availability, fitness, and performance context before building the lineup.
Keep lineup exploration and communication together instead of passing around whiteboard photos and emails.
Show where each status came from and when it changed so staff can judge whether it is current.
Design solution
Each screen centers one practical question. Rather than carrying every data point into every view, I kept the status language consistent and changed the supporting evidence around the decision at hand.
Readiness emphasizes who needs attention. Player profiles explain why. Lineup planning and analytics connect risk to action, while deeper history remains available on demand.
Squad Readiness
Who needs attention, and why can staff trust a player’s availability?
Match Center
Who should start, who needs managed minutes, and how does the change reach the squad?
Match Center follow-up
Once staff confirm the squad, the player receives the roster update before arriving at the stadium.
Scouting
What did the scout see, and how quickly can they record it?
Analytics
How does the system turn fatigue risk into an agreed rotation plan?
Usability check
One player scout tested the iPad prototype during an actual match, using the core scouting flow to track five predefined attributes as play unfolded.
The scout completed the task independently and rated their confidence between four and five out of five across the flow.
The rating interaction stayed quick enough to use one-handed while holding the tablet and watching the match.
Detailed typing competed with live observation, so notes worked better as a post-match activity or a future voice-dictation flow.
“I loved that everything was just a few taps.”
Retrospective
ClubSphere reminded me that the most important design work often lives in the handoff between observation and action. A useful product would not win by adding more data; it would help the right person understand what changed, why it matters, and what decision comes next.
The project also sharpened a belief I keep returning to in enterprise software: clarity is not the opposite of depth. Done well, clarity is how depth becomes usable.
If the work continued, I would resist adding more surface area until the underlying rules were clearer: who can edit medical status, how conflicting observations are resolved, and which decisions need a visible history. In a shared system, trust depends as much on ownership as it does on interface design.
