Real-time platform · 2024
A live auction floor, without the chaos
A real-time auction and tournament-scorecard platform for sports leagues — live bidding floors, instantly synced scoreboards, and a room full of people looking at the same number at the same time.
Role
Product Designer & Builder — UX/UI to shipped web app
Timeline
2024 · 8 weeks
Team
Solo — design & build
Platform
Web · projector + mobile
Real-time
Bids & scores synced instantly
2 surfaces
Projector floor + organiser console
Solo
Designed and built end to end
01 · Overview
Local sports leagues run player auctions the way they've always been run: a spreadsheet, a loud voice, and arguments about what the last bid actually was. Auction Wizz replaces that with a live bidding floor everyone can see and a scorecard system that stays in sync through the tournament.
I designed and built the platform solo — the auction-floor display, the organiser's console, team budget tracking and the tournament scoreboards that follow.
02 · The Problem
What we were trying to solve
Auction night is high-stakes and fast — but the tools are a projector-ed spreadsheet and someone's memory. Bids get lost, budgets get miscounted, and disputes stall the room. Then the tournament starts and scores fragment across WhatsApp messages.
Pain point 01
No single source of truth in the room
The current bid, the remaining budget and who's on which team lived in different heads — every disagreement stopped the auction.
Pain point 02
Organisers juggle too much live
One person tracked bids, budgets, player lists and the clock simultaneously — mistakes were inevitable and unrecoverable.
Pain point 03
Scores die in chat threads
Once the tournament began, results were photos of paper scorecards in WhatsApp — no standings, no history, no drama.
03 · Research
What the users taught us
I attended league auction nights, interviewed organisers about where evenings went wrong, and studied broadcast sports graphics — the gold standard for making live numbers legible to a room.
The room reads one screen
Everything critical — current bid, player, remaining budgets — had to be legible from the back of a hall on a projector.
The organiser needs a cockpit, not a form
Accepting bids, undoing mistakes and closing sales happens in seconds — the console had to work under pressure with zero ambiguity.
Undo is non-negotiable
Every organiser's worst memory was an entry error they couldn't cleanly reverse in front of a shouting room.
04 · Design Process
From tangled problem to shipped solution
Stage 1 — Problem Identified
Trust breaks when the numbers do
Observing auction nights showed the real product wasn't bidding software — it was shared, undisputed truth. The moment two people saw different numbers, the evening derailed.
Stage 2 — Problem Scoping
Two surfaces, one state
Scoped to a projector-facing floor display and an organiser console driving it, backed by one real-time state. Team-owner mobile views and stats came later; auction night had to be bulletproof first.
- Real-time sync architecture chosen before visual design
- Explicit failure states designed for connection drops
Stage 3 — Solution Shaping
Broadcast-grade legibility
Type scales, contrast and motion were designed for a hall, not a laptop — the current bid is the biggest thing in the room, budget bars are readable at 15 metres, and every change animates so the room sees it happen.
Stage 4 — Impact Testing
Dry runs at full speed
Simulated auctions at real pace stress-tested the console: mis-taps, rapid corrections, connection drops. The undo flow and confirmation states were redesigned twice before an organiser could run a full auction error-free.
- Console tested under time pressure with real organisers
- Recovery paths verified for every destructive action
Stage 5 — Solution Deployed
Live for real auction nights
The platform shipped and ran actual league auctions — the floor display on the projector, the console on the organiser's laptop, and scoreboards carrying the tournament through to the final.
05 · The Solution
The decisions that shaped it
Auction Wizz splits the experience into a floor everyone watches and a cockpit one person drives — both reading from the same live state, so the number on the wall is always the truth.
Decision 01
The floor display
Current player, current bid and team budgets in broadcast-scale type, with every state change animated so a hall full of people tracks the action without anyone announcing it.
Decision 02
The organiser console
Big targets, one-tap bid entry, prominent undo and a clear sold-confirmation flow — designed to be operated under pressure without fear of irreversible mistakes.
Decision 03
Budgets that police themselves
Team budgets update with every sale and the console blocks bids a team can't afford — ending the arithmetic disputes that used to stall the room.
Decision 04
Scoreboards that outlive the night
Match scorecards feed live standings that persist through the tournament — replacing paper-photo threads with a shared, always-current table.
06 · Impact
What changed
The platform runs real league auction nights end to end — and the disputes that used to define them simply stopped.
Live
Running real league auctions
1 state
Floor, console & scores always in sync
8 weeks
Solo, design to deployment
- League auctions run on the platform with the floor display as the room's single source of truth.
- Budget enforcement eliminated the miscount disputes that previously stalled evenings.
- The undo-first console let non-technical organisers run full auctions confidently.
- Tournament scoreboards kept engagement alive between match days.
07 · Learnings
What I'm taking with me
- 01
Real-time products are trust products — the design job was making synchronised state feel undeniable to a skeptical room.
- 02
Designing for a projector at 15 metres breaks every desktop assumption; legibility budgets are as real as latency budgets.
- 03
Building what I designed closed the loop: constraints surfaced in code reshaped the design within hours, not sprints.