UNILEAGUE · SPARKT · DESIGNING THROUGH AMBIGUITY
My Role
Product Designer: Product structure, UX, interaction design and post-selection experience
Engagement
Client / Agency
Surfaces
Participant platform + Admin console
Timeline To Build This Module
3 Days
Context
UniLeague is a client cricket-league platform spanning a participant-facing product and admin console.
While I was designing it, the product converted from a university-based competition to a city/state-based tournament with eight teams. The participant journey was taking shape, but one key question remained unresolved:
How does a selected player actually become part of a team?
This decision affected team formation, squads, player states, and parts of the admin experience. I didn’t own the business decision; I owned how the product would behave while it was still open.
The challenge was to design around uncertainty.
Ongoing — In development
Surfaces designed: participant platform (website) + admin console
Live business directions kept buildable at once
Real business reversal absorbed after review
Manual design rework the reversal required
Not to validate a final experience with users, but to give stakeholders enough confidence to keep moving, without over-investing in a workflow they might scrap. The deliverable was an assurance build.
MY FOCUS
Build for both possibilities
Keep the product structure stable, represent both team-selection options, and give stakeholders a realistic prototype to move forward with.
LATER
Validate usability
Test task success, player understanding, and interaction flows once the team-selection model is confirmed.
The assurance build and a living homepage.
The build stakeholders reviewed to keep deciding
UniLeague originated with the client. My agency helped shape the product, design the experience, build the platform and support its evolution.
It began as a university competition, then shifted mid-project to a city and state tournament of eight teams. Since team formation depended on the final structure, I split the product into two categories.
Stable
Registration and candidate data
Stage 1 screening and Stage 2 trials
Selection and the selected-player record
Player information
Core admin structure
Supporting league infrastructure
Unstable
Who forms the teams
Who has authority to select a player
Whether selection happens inside or outside the console
How assignment becomes an official squad relationship
The call was the stakeholders’ and this would shape how the league runs. My job was to let the product progress without locking in either model, so I drew a boundary around the undecided part.
Direction A · Console User assigns
An operator places selected players into teams from the admin console.
Direction B · Team picks
A team owner selects a player directly; the console records the resulting state.
Everything up to the pool is stable. The mechanism inside the dashed boundary is the only part that changes with the business decision.
I owned the product structure, UX, interaction design, information architecture and experience across the participant and admin surfaces.
The client owned the league model, team-formation rules, selection mechanics and commercial/operational decisions. That distinction mattered. I could design around the uncertainty, but I shouldn't turn an unresolved business decision into a design assumption.
I owned
✓
Product structure and information architecture
✓
UX and interaction design
✓
The participant journey and admin console structure
✓
States and flows across both surfaces
✓
The flexible layer around the unresolved decision
✓
Translating decisions into buildable product structure
Stakeholders owned
–
The final league model
–
The university vs city / state direction
–
The team-formation model
–
Team ownership and selection mechanics
–
Commercial and operational rules
I studied ISPL, IPL and ISL to understand what makes a league work, not to copy their models, but to identify principles that would hold as UniLeague evolved.
ISPL
Observation
Player selection happens separately from squad formation, with teams acquiring their players.
Implication
Selection and team assignment are different stages with different owners.
Design consequence
The Player Pool became an independent state, with team assignment kept as a separate layer.
IPL
Observation
A player's record persists across retentions, trades and releases, beyond any single team relationship.
Implication
Player records must remain stable, regardless of team association.
Design consequence
A single, persistent player record became the foundation of the system.
ISL
Observation
Player status and eligibility need central tracking, even when teams operate independently.
Implication
The platform needs one reliable source of truth for player status.
Design consequence
The Player Pool made states explicit: selected, assigned or picked, and still available.
One requirement would survive any pivot: every selected player needs one reliable record between selection and squad formation. That invariant became the Player Pool.
I weighed the options against one thing: Reversibility. Three plausible builds. I scored them on what mattered while it stayed open.
A and B looked more finished but locked in an unmade decision. All three needed the same record so I built C and left the mechanism as a layer. The only reversible option.
Not the final team-selection experience, but the stable handoff between selection and squad formation. Every element earns its place against the invariant.
1
Selection score carried forward
Preserves the context earned in the previous stage.
2
A single source of selected players
Both assignment models require the same underlying record.
3
Explicit status
Selected, assigned or picked, and still open are different states, never collapsed.
4
Search and filters
Keep the pool operable as the number of selected players grows.
5
Assignment as a conditional layer
Controls can attach here if console-assignment is the approved direction.
6
Count and remaining
Makes operational readiness visible at a glance.
With the record and the mechanism separated, the business can pick either direction without disturbing the product around it. Take any direction, the Player Pool doesn’t change.
With the Player Pool fixed, the rest of the post-selection experience could be built around it as clean system layers, not a pile of screens.
Competition operations
01
Match Centre (Web Page)
Live scores and every fixture in one view.
02
Points Table (Admin Console)
Standings with manual-override handling.
Team management
01
Teams & Squads (Web Page)
A team’s home and its confirmed XI plus bench.
02
Player Profiles (Admin Console)
Player record and performance history within a team.
Participant and audience experience
01
My League (Web Page)
A participant’s registration timeline and status.
02
Standings (Admin Console)
The eight teams ranked with net run-rate and form.
The post-selection area was intentionally lightweight to build because its underlying business direction was still unsettled.
I didn't want to spend disproportionate design time manually producing a large set of potentially disposable screens.
These logos were used as dummy fillers to represent each teams.
After stakeholder reviews, UniLeague returned to its original university-based model, moving away from the city and state tournament format. The structure I had designed already accounted for this possibility.
Since the core structure remained intact and AI-assisted workflows helped speed up implementation, the change required only a few prompts instead of a complete redesign. Both the participant product and admin console were updated with minimal rework.
Decision ownership
Recognising which decisions belong to design and which belong to the business.
Systems thinking
Isolating a volatile business rule from a stable product architecture.
Product judgement
Moving the product forward without manufacturing false certainty.
Operational UX
Records, states and workflows that can support real league operations.
The business changed its decision. The product didn’t have to change with it. I turn unresolved business decisions into contained, reversible product structures.