Club Atwater needed a scalable box ladder system that could manage skill-based competition, disputes, and monthly promotions across multiple racquet sports while minimizing administrative overhead.
Designing the Box Ladder for a Racquet Sports
Club AtWater
2024
B2C
Sports Community
Mobile App
Back to Work
The Challenge
The Challenge
No direct client access.
Compressed delivery timeline.
No existing competition workflow documentation.
The challenge was to create a ladder experience that could:
Constraints
Recreational sports leagues sit on a fragile balance. Players want fair, competitive matches. But these leagues are volunteer-run scheduling is chaotic, drop-outs break the structure, and disputes fall on whoever's running the WhatsApp group. The box ladder format can fix this, but only if the interface makes the rules impossible to misread.
Who I was designing for
The brief never named user roles. I derived four from the competition logic itself and scoped this project to the two that interact with the system daily.
All matches within a box must be played before month end. Unplayed matches default to a forfeit after a 24-hour reschedule window.
Both players enter scores independently. Mutual confirmation creates the audit trail before any dispute can be raised.
Admin arbitration is the final step in disputes not the first. The system is designed to handle everything before escalation.
Promotion and relegation are determined by win/loss record. Tiebreakers use points differential, then head-to-head.
Product Assumptions & System Rules
Stakeholder access was unavailable, every assumption was documented and treated as a temporary business rule. This allowed the system to move forward while keeping future validation visible.
Players are grouped into boxes of 4–6 by admin-assigned skill rating at the start of each month.
What I explored, what I rejected, and why
What I explored, what I rejected, and why
I explored multiple approaches for ladder visibility and dispute resolution, evaluating each against player clarity, competitive fairness, and operational scalability. The final designs were chosen based on their ability to reduce friction for players while minimizing administrative effort.
I explored multiple approaches for ladder visibility and dispute resolution, evaluating each against player clarity, competitive fairness, and operational scalability. The final designs were chosen based on their ability to reduce friction for players while minimizing administrative effort.
How players understand their position within the ladder?
How players understand their position within the ladder?
How disputes are resolved without overwhelming admins?
How disputes are resolved without overwhelming admins?
Exploration 01 - Ladder view layout
Checking your standing mid-season
Concept #1
Concept #2
Single scrollable view
One long screen showing your position, all matches, and the full ladder beneath it.
Worked fine for players in the middle of a box. Broke completely for players at the bottom their most important information was buried below the fold. Context switching between personal and global was disorienting.
DESIGN DECISION
I chose concept #2 My Box and All Boxes are tabs, not separate nav destinations. Players constantly switch between personal progress and competitive awareness co-locating them removes the friction of navigating back and forth. Keeping them as separate screens would have added two taps to every context switch, every session.
Dispute resolution flow
Exploration 02
Concept #1
Concept #2
Concept #3
Any score mismatch goes straight to admin for resolution. Fast to design, easy to explain. But it made admin the default referee for every minor disagreement including ones players could resolve themselves. In a volunteer-run league, that's unsustainable the moment the ladder scales past 20 players.
Admin-first escalation
DESIGN DECISION
A dispute can only be raised if scores don't match. Players can't flag a result they've already confirmed. This single constraint eliminates the majority of bad-faith attempts without adding any friction to genuine ones. Admin enters the picture only as a last resort.
The Final Screens
The ladder view and dispute resolution flow were covered in full during the exploration section including the rejected directions and the reasoning behind each choice. What follows are the remaining screens in the player journey.
SCORE ENTRY - REPORTING A RESULT
Self-reported scores are where trust breaks down in recreational leagues. The design makes accurate entry frictionless while building an audit trail that makes disputes rare not just resolvable.
Self-reported scores are where trust breaks down in recreational leagues. The design makes accurate entry frictionless while building an audit trail that makes disputes rare not just resolvable.
Confirmation screen immediately sets expectations. "Opposite player will be notified within 24 hours. The loop is closed before the player leaves the screen.
DESIGN DECISION
Both players enter scores independently. Mutual confirmation eliminates single-player errors and creates a natural audit trail before any dispute mechanism is needed.
INCOMPLETE MATCH - WHEN IT COULDN'T FINISH
Injuries. Court time running out. A player retiring mid-set. These situations don't fit the standard score entry flow and without a dedicated path, every one becomes a manual admin task. This state was designed specifically to capture incomplete matches without forcing a winner or triggering a dispute.
DESIGN DECISION
Giving incomplete matches their own state means they never pollute the score entry flow or the dispute flow. Admin sees a clean flag, not a half-filled score form with a note in the comments. Edge cases deserve first-class treatment not an afterthought tucked into the happy path.
AFTER THE MATCH - CLOSING THE LOOP
Once both players confirm, the result locks. Small moment but emotionally one of the most important in the entire flow. Three things need to land instantly: the match is done, the points are banked, and here is exactly where the player now stands.
Position change is shown as a before and after state. Moving up in the standings is worth a moment of recognition. A plain notification conveys the information. The before/after makes the player feel it and that emotional beat is what keeps them coming back next month.
DESIGN DECISION
MONTH END CYCLE - THREE OUTCOMES, THREE REGISTERS
This is the climax of the entire system. Every match played, every score entered, every dispute resolved, it all leads here. The design challenge wasn't showing the result. It was making each outcome feel the way it should feel.
DESIGN DECISION
Each outcome has its own color palette and copy tone not just different text on the same template. Promotion feels like a win. Relegation doesn't pretend otherwise. Staying is acknowledged, not ignored. All three are built from a single underlying component so the emotional variation never creates maintenance overhead.
What I learned, what comes next
This project ran under a compressed timeline with no live client access, a brief that left more questions than answers, and zero room for discovery rounds. What it forced was a discipline I'd carry into every project after it declare your assumptions early, design against them explicitly, and treat every constraint as a creative input rather than an excuse.
What I learned
What I learned
CONTRAINTS ARE A BRIEF IN DISGUISE
CONTRAINTS ARE A BRIEF IN DISGUISE
No client access felt like a blocker at first. It turned out to be the most clarifying constraint of the project. It forced every ambiguity into a written assumption which meant every design decision had a documented reason behind it. That rationale became the project's backbone.
THE REJECTION IS WHERE THE THINKING LIVES
The peer voting system looked compelling on paper. Walking it through a real scenario a player who wasn't at the match being asked to cast a deciding vote exposed the failure mode in under five minutes. The best design decisions in this project came directly from understanding why the previous direction broke, not from starting fresh.
EMOTIONAL DESIGN ISN'T DECORATION - IT'S RETENTION
The month-end outcome screens were the last thing designed and nearly the most important. A player who feels genuinely celebrated for promotion, or honestly acknowledged for relegation, is far more likely to come back next month. That emotional beat is what converts a competition mechanic into a community habit.
If I had more time
If I had more time
Design the admin-side flow end to end, Test the score entry flow with real players, Map the full notification system, Build out the component library properly.
End-to-end systems thinking · Constraint-led design · Assumption declaration · Edge case handling · Emotional design · Iterative decision-making · Solo sprint execution
Club Atwater wanted a single community app to serve three racquet sports with a box ladder competition system as its center piece. The brief described the mechanic at a surface level: players compete within boxes, winners move up, losers drop down at the end of each month.
Club Atwater wanted a single community app to serve three racquet sports with a box ladder competition system as its center piece. The brief described the mechanic at a surface level: players compete within boxes, winners move up, losers drop down at the end of each month.
The Brief
The Brief
2024
B2C
Sports Community
Mobile App
Designing the Box Ladder for a Racquet Sports
Club AtWater
Back to Work
Club Atwater needed a scalable box ladder system that could manage skill-based competition, disputes, and monthly promotions across multiple racquet sports while minimizing administrative overhead.
The challenge was to create a ladder experience that could:
Ensure fair competition between players of different skill levels.
Reduce administrative effort for league organizers.
Handle score disputes and no-shows consistently.
Keep players engaged through monthly progression.
Support Pickleball, Badminton, and Squash
Support Pickleball, Badminton, and Squash
Ensure fair competition between players of different skill levels.
Reduce administrative effort for league organizers.
Handle score disputes and no-shows consistently.
Keep players engaged through monthly progression.
Constraints
Compressed delivery timeline.
No direct client access.
No existing competition workflow documentation.
Recreational sports leagues sit on a fragile balance. Players want fair, competitive matches. But these leagues are volunteer-run scheduling is chaotic, drop-outs break the structure, and disputes fall on whoever's running the WhatsApp group. The box ladder format can fix this, but only if the interface makes the rules impossible to misread.
What the system had to solve
Skill Disparity
New and experienced players mixing in the same ladder kills motivation on both ends.
What the system had to solve
No-show chaos
Without clear forfeit rules, organizers spend hours chasing players and re-seeding manually.
Score disputes
Self-reported scores break down without a structured confirmation and arbitration path.
Who I was designing for
The brief never named user roles. I derived four from the competition logic itself and scoped this project to the two that interact with the system daily.
Player
Checks standing, schedules matches, enters scores. Primary focus of this case study.
Admin
Sets up the ladder, resolves disputes, handles edge cases. Designed to stay out of the way.
Club Owner
Manages multiple sport ladders and member access. Out of scope.
Product Assumptions & System Rules
Stakeholder access was unavailable, every assumption was documented and treated as a temporary business rule. This allowed the system to move forward while keeping future validation visible.
Players are grouped into boxes of 4–6 by admin-assigned skill rating at the start of each month.
Both players enter scores independently. Mutual confirmation creates the audit trail before any dispute can be raised.
Admin arbitration is the final step in disputes not the first. The system is designed to handle everything before escalation.
Promotion and relegation are determined by win/loss record. Tiebreakers use points differential, then head-to-head.
Checking your standing mid-season
Exploration 01 - Ladder view layout
Concept #1
Concept #2
One long screen showing your position, all matches, and the full ladder beneath it.
Single scrollable view
Worked fine for players in the middle of a box. Broke completely for players at the bottom their most important information was buried below the fold. Context switching between personal and global was disorienting.
DESIGN DECISION
Dispute resolution flow
Exploration 02
Concept #1
Concept #3
Concept #2
Any score mismatch goes straight to admin for resolution. Fast to design, easy to explain. But it made admin the default referee for every minor disagreement including ones players could resolve themselves. In a volunteer-run league, that's unsustainable the moment the ladder scales past 20 players.
Admin-first escalation
DESIGN DECISION
The Final Screens
The ladder view and dispute resolution flow were covered in full during the exploration section including the rejected directions and the reasoning behind each choice. What follows are the remaining screens in the player journey.
SCORE ENTRY - REPORTING A RESULT
Self-reported scores are where trust breaks down in recreational leagues. The design makes accurate entry frictionless while building an audit trail that makes disputes rare not just resolvable.
Self-reported scores are where trust breaks down in recreational leagues. The design makes accurate entry frictionless while building an audit trail that makes disputes rare not just resolvable.
DESIGN DECISION
INCOMPLETE MATCH - WHEN IT COULDN'T FINISH
DESIGN DECISION
Giving incomplete matches their own state means they never pollute the score entry flow or the dispute flow. Admin sees a clean flag, not a half-filled score form with a note in the comments. Edge cases deserve first-class treatment not an afterthought tucked into the happy path.
Once both players confirm, the result locks. Small moment but emotionally one of the most important in the entire flow. Three things need to land instantly: the match is done, the points are banked, and here is exactly where the player now stands.
DESIGN DECISION
Position change is shown as a before and after state. Moving up in the standings is worth a moment of recognition. A plain notification conveys the information. The before/after makes the player feel it and that emotional beat is what keeps them coming back next month.
This is the climax of the entire system. Every match played, every score entered, every dispute resolved, it all leads here. The design challenge wasn't showing the result. It was making each outcome feel the way it should feel.
DESIGN DECISION
What I learned, what comes next
THE REJECTION IS WHERE THE THINKING LIVES
The peer voting system looked compelling on paper. Walking it through a real scenario a player who wasn't at the match being asked to cast a deciding vote exposed the failure mode in under five minutes. The best design decisions in this project came directly from understanding why the previous direction broke, not from starting fresh.
EMOTIONAL DESIGN ISN'T DECORATION - IT'S RETENTION
The month-end outcome screens were the last thing designed and nearly the most important. A player who feels genuinely celebrated for promotion, or honestly acknowledged for relegation, is far more likely to come back next month. That emotional beat is what converts a competition mechanic into a community habit.
SKILLS DEMOSTRATED
All matches within a box must be played before month end. Unplayed matches default to a forfeit after a 24-hour reschedule window.
I chose concept #2 My Box and All Boxes are tabs, not separate nav destinations. Players constantly switch between personal progress and competitive awareness co-locating them removes the friction of navigating back and forth. Keeping them as separate screens would have added two taps to every context switch, every session.
A dispute can only be raised if scores don't match. Players can't flag a result they've already confirmed. This single constraint eliminates the majority of bad-faith attempts without adding any friction to genuine ones. Admin enters the picture only as a last resort.
Confirmation screen immediately sets expectations. "Opposite player will be notified within 24 hours. The loop is closed before the player leaves the screen.
Both players enter scores independently. Mutual confirmation eliminates single-player errors and creates a natural audit trail before any dispute mechanism is needed.
Injuries. Court time running out. A player retiring mid-set. These situations don't fit the standard score entry flow and without a dedicated path, every one becomes a manual admin task. This state was designed specifically to capture incomplete matches without forcing a winner or triggering a dispute.
AFTER THE MATCH - CLOSING THE LOOP
MONTH END CYCLE - THREE OUTCOMES, THREE REGISTERS
Each outcome has its own color palette and copy tone not just different text on the same template. Promotion feels like a win. Relegation doesn't pretend otherwise. Staying is acknowledged, not ignored. All three are built from a single underlying component so the emotional variation never creates maintenance overhead.
This project ran under a compressed timeline with no live client access, a brief that left more questions than answers, and zero room for discovery rounds. What it forced was a discipline I'd carry into every project after it declare your assumptions early, design against them explicitly, and treat every constraint as a creative input rather than an excuse.
No client access felt like a blocker at first. It turned out to be the most clarifying constraint of the project. It forced every ambiguity into a written assumption which meant every design decision had a documented reason behind it. That rationale became the project's backbone.
Design the admin-side flow end to end, Test the score entry flow with real players, Map the full notification system, Build out the component library properly.
End-to-end systems thinking · Constraint-led design · Assumption declaration · Edge case handling · Emotional design · Iterative decision-making · Solo sprint execution
SKILLS DEMOSTRATED
