Invite your people.
Bring your friends into the next game and get everyone playing.
PRODUCT DESIGN / SELECTED CASE STUDY 01
Every point.
Smarter.
Where’s the court? When’s the match? Who’s winning? And why is the fixture information in four different WhatsApp threads? MatchPoint brings friends, live scoring, leagues and tournament competition together for tennis and badminton match days.
Explore the live app ↗ Try scoring ↓
PLAY / CONNECT / COMPETEMore than a
More than a
scoreboard.
Invite friends, arrange a match, build a league or set up a tournament. MatchPoint makes competition more social, from the first rally to the final point.
Visit the deployed app ↗Own the table.
Build friendly rivalries through league matches and standings.
Play for the final.
Compete in tournament rounds and keep track of the bracket.
Every point matters.
Keep the match score as the competition unfolds.
Interface artwork is illustrative rather than a verified capture of the deployed application.
01 / DISCOVERYLISTEN · FRAME · MAP
Start with the people.
Not the interface.
Players need the next court and start time. Captains need to organise a team. League organisers need a schedule and table everyone can trust. Those different jobs shaped the questions, user flows and interfaces explored here.
RESEARCH FOCUS
Understand the whole match-day journey.
Follow match day from the moment someone asks “Which court?” to the moment a result is confirmed. That is where a very ordinary question becomes a design requirement.
Example synthesis board — not verbatim participant quotations
Where do I need to be?
Find the venue, assigned court, start time and opponent without chasing separate messages.
CONTEXT · CONFIDENCE
What’s the score?
Record points with minimal interruption and keep the match state easy to understand.
VISIBILITY · FEEDBACK
What happens next?
See team fixtures, recent results, upcoming games and match changes in one place.
PLANNING · COORDINATION
Where do we stand?
Track league rankings, scores, match confirmation and a schedule people can trust.
TRANSPARENCY · CONTROL
02 / CO-DESIGN & WORKSHOPSFRAME THE PROBLEM TOGETHER
From conversation
to clarity.
In a good workshop, several versions of “what on earth is going on?” eventually become one problem the team can solve. This board illustrates how stakeholder mapping, user journeys, pain-point clustering and prioritisation can guide MatchPoint.
01
Listen & map
Capture who is involved and how each person approaches a match day.
Players need court, time and opponent details before leaving home.
Organisers need a dependable view of fixtures and results.
02
Cluster friction
Group repeated questions into themes, then identify root causes.
Fixture details can be fragmented across messages.
Scoring and league standings can become separate admin tasks.
03
Explore ideas
Turn pain points into opportunities and sketch multiple approaches.
One-glance match card with venue, court and time.
Connected scoring feeding results into the league view.
04
Prioritise & test
Sequence the essentials, surface assumptions and define the next test.
First: fixture clarity, score capture and standings.
Then: alerts, availability and advanced league administration.
↳
Process illustration: a worked example of how the discovery and workshop activities fit together. It is not a transcript of completed sessions or a claim about participant numbers.
THE DESIGN CHALLENGE
How might we make every match easy to find, play, track and follow?
The aim is bigger than a digital scoreboard: a match day people can understand from first fixture to final result.
03 / USER FLOWS & INFORMATION ARCHITECTUREINTERACTIVE DIAGRAM
A product that
joins the dots.
Choose a user type to see how the information architecture changes around their needs. Select any step to inspect its purpose, potential friction and the proposed design response.
SERVICE JOURNEY Plan and play a match
→→
CLICK ANY STEP TO EXPLORE THE DESIGN REASONING ↗
Court and time first.
Prioritise the most time-sensitive details at the top of each fixture card.
One task at a time.
Separate match-day actions from league management complexity.
Make state unmistakable.
Clearly distinguish scheduled, live, awaiting confirmation and completed matches.
DESIGN RATIONALE · TRANSLATING NEEDS
From pain point
to product decision.
Each screen should answer a question somebody actually asks. Trace the problem to the feature and the feature to the thing we’d need to test.
Stated user need Proposed design response What to validate
“Which court? What time?”
Players need one reliable place to find the fixture details that affect arriving and being ready to play.
Next-match card with court, start time and opponentValidate: can someone find the court and start time at a glance, outdoors and in a hurry?
“What’s the score now?”
Players want clear scorekeeping without interrupting the game or juggling devices.
One-tap scoring and a shared courtside viewValidate: missed taps, corrections, deuce, game boundaries and visibility on court.
“Did the result save?”
Players and captains want a dependable record without entering the same information repeatedly.
Result summary, confirmation and match historyValidate: ownership of edits, conflict resolution and recovery when offline.
“Where do we stand?”
Captains and organisers need upcoming fixtures and current standings in one place.
League table connected to fixtures and resultsValidate: scoring rules, postponed games, team filtering and accessibility of tables.
THE DESIGN RULE
Surface the next useful action in the context where it matters. These are design decisions to test, not unearned victory laps about research results.
FOLLOW THE USER JOURNEYS ↗01 / The challenge
Designed for the court.
Not the desk.
Scoring should be effortless when your hands are full, your attention is on a match and your phone is somewhere in a kit bag. The MatchPoint concept explores an outdoor-friendly physical display, intuitive mobile scoring, and quick updates from a smartwatch.
The design exploration considers tennis and badminton use cases, how scores are captured, how matches are remembered and how connected devices might reduce interruption during play.
About this case study: This page combines existing product concept material with reconstructed workshop and journey artefacts to illustrate the design approach. No participant counts, verbatim quotes, measured research findings or commercial outcomes are claimed without supporting evidence.
01
Listen to the people who play
Plan interviews and observation with players, captains and organisers to understand the real rhythm of a match day.
02
Map the friction
Explore moments when manual scoring, attention shifts, visibility and keeping a record can interrupt the flow of play.
03
Sketch multiple futures
Contrast courtside display ideas with app-based and smartwatch interactions, including a portable solar-powered hardware direction.
04
Make the idea testable
Use interaction prototypes to explore scoring states, modes and feedback, then identify assumptions for further field validation.
02 / Prototype experience
Go on.
Score a point.
Try the scoring prototype: switch sports, award a point, make a mistake and undo it. It’s an interactive concept, not a live club account, and uses simplified singles rules.
INTERACTIVE MATCH · DEMO
PlayerGamesPoints
CRAIG00
OPPONENT00
SET SCORE 0–0READY TO PLAY
In the moment.
Tap the scorer, just as you might on a phone or watch. See the match update instantly on the courtside display.
Tennis scoring: 0, 15, 30, 40, deuce and advantage. First to six games by two wins a set; a tie-break starts at 6–6.
05 / PRODUCT EXPERIENCEINTERACTIVE CONCEPT · SAMPLE DATA
One home for
match day.
Scoring is only part of the match. The same experience should tell players when and where to turn up, tell captains who’s playing next, and tell the league what the table actually says. Preferably without three phone calls.
Your next match
NEXT FIXTUREROUND 04
YOUR TEAMNorthside
VSOPPOSITIONRiverside
COURT03 · Indoor
START TIME18:30 · Thu
STATUSScheduled
YOUR INFORMATION, FIRST
No hunting through messages.
The essential details are visible in one glance, with the full schedule one click away.
FIXTURES & COURT ALLOCATIONS
What's coming up.
THU · 18:30Northside vs RiversideCourt 03UPCOMING
FRI · 19:00Willow vs EastfieldCourt 01UPCOMING
SAT · 10:00Northside vs WillowCourt 02UPCOMING
SUN · 14:30Riverside vs EastfieldCourt 04UPCOMING
LEAGUE STANDINGS
Example points table showing how a league could keep rankings transparent after results are approved.
| POS | TEAM | P | W | D | PTS |
|---|---|---|---|---|---|
| 01 | Northside YOUR TEAM | 6 | 5 | 0 | 15 |
| 02 | Riverside | 6 | 4 | 1 | 13 |
| 03 | Willow | 6 | 3 | 1 | 10 |
| 04 | Eastfield | 6 | 1 | 0 | 3 |
Illustrative standings using example teams and a simplified three-points-for-a-win model. Scoring and ranking rules would be configurable and validated for each league.
DESIGN OBJECTIVERemove ambiguity before play begins.
PRODUCT ARCHITECTUREA connected loop,
A connected loop,
not isolated screens.
Publish fixture→Check court & time→Record score→Verify result→Update table
06 / From question to concept
Design is a
process of discovery.
Four decisions shape the concept: understand the match day, agree which problem matters, explore different ways to solve it, then test what works on an actual court.
01
Discover
Talk to players, coaches and people close to the sport. Frame the jobs, motivations and practical conditions.
02
Define
Map problem statements, current workarounds and moments where better feedback could improve play.
03
Explore
Sketch across software and physical product directions, balancing outdoor readability and ease of interaction.
04
Prototype
Make scoring states clickable, surface edge cases and build a path to genuine field usability tests.
07 / Connected product concept
The score,
for both sides.
The proposed net-mounted LED display makes the match score visible to both teams, updated from the companion phone app in real time. This is a design concept for a shared courtside experience, not a released hardware product.
Hardware concept only: attachment safety, outdoor readability, battery life, wireless reliability and court regulations would all require testing before real-world use.
Interested in the process?