Competition Management Platform for a Padel League
The new feature was the right excuse. The problem was the app around it.
Why it matters — an assistant inside an app that's hard to navigate doesn't fix the problem. It gives it a second door.
Product Designer, end-to-end on the player app proposal · AppX
Navigable prototype with real scroll and expansion
Proposal, not built
The decision I'd defend — the interface answers what's predictable; the assistant answers what's variable.
An app that answers before anyone asks
The proposal was designed screen by screen, with states and a navigable prototype — real scroll and expansion, not simulated.
What the design established was a hierarchy: four fixed destinations, the league as explicit context, and an assistant that only enters where the interface doesn't reach on its own.
What I don't know is how many questions are left for it. If the assistant gets heavy use for things that are two taps away, the navigation still isn't solved. That's the first thing I'd look at.
Thanks to the AppX team and to PadelBox, who argued about every screen instead of approving them.
The Problem
PadelBox runs social doubles leagues — fifteen regional leagues, going since 2013. Pairs enrol in an edition, receive a draw, and then arrange the date and court of each match between themselves. The organisation sets the rules and the calendar; the players handle the rest.
That makes the app a specific thing. It isn't a booking marketplace or a social network. It's the infrastructure of a competition people run among themselves. Nobody opens it daily — they open it when there's a match to arrange, a result to enter, or a standing to check.
Everything lives inside the context of a league — schedule, standings, enrolment — and a player can be in more than one at a time, plus the history of past editions.
The ask was a feature. The work was architecture. An AI assistant answers questions. In an app that's hard to navigate, most of the questions it receives are questions the interface should have answered on its own — where the next round is, who I'm playing, what position I'm in. A chat that exists because navigation failed isn't a feature. It's a patch.
The real competitor isn't Playtomic. It's the WhatsApp group. That's where the pair arranges the match when the app is effort, and where the information disappears. We matched WhatsApp on nothing — it's unbeatable at arranging — and differentiated on what it can't do: what position am I in, who's left to play, how long do I have to book.
My Role
Product Designer for this proposal, end-to-end: navigation architecture, screen and state model, high-fidelity interface, and a prototype with real scroll and expansion rather than simulated ones.
Not a blank page. The app exists, has users, and had a season running. Every new screen needed an equivalent in what was already there — or an explicit reason not to.
The structural decision — removing the side menu for a fixed bottom bar — was discussed and decided with the team. I brought the alternatives and the recommendation. It's also the decision that caused the biggest problem in the project, which is in Learnings.
The System
The league is a context, not a menu item. Everything in the app is scoped to the league you're in, and a player holds several at once plus history.
The side menu was doing two things at the same time. It navigated between sections, and it switched the active league. Because they lived in the same place, they looked like the same function. They aren't: one takes you somewhere else, the other changes the meaning of everywhere.
The app is used in bursts, not sessions. Someone enters with an objective and leaves. Navigation that requires opening a menu charges a tap on every entry — and most entries are two or three taps long.
Decisions
Four fixed destinations, always visible. The tasks are few, they repeat, and visits are short. A side menu charges a tap before anything happens, hides the options, and doesn't say where you are. A fixed bar shows the whole map and marks your position with no tap at all. When there are four destinations and all of them are frequent, hiding navigation only adds work.
The league became a place, not a menu option. Active enrolments at the top, then Upcoming leagues and Past leagues, each with its count visible. You know how many there are before opening.
Cards that expand, not modals. Each block opens in place and pushes the rest down. A modal covers what's behind it and forces you to close it to compare — and comparing is exactly what you're doing when you look at upcoming leagues while one is running.
History treated with the same care as the present. Opening a past edition shows that edition's standings and matches, with the player's own row highlighted and each result visible. It's the part of the app people return to without needing anything.
The assistant answers what's left. Regulations, exceptions, badly-formed questions, and anything requiring a cross-reference — the calendar against the opponent, the standings against what's still to play. AI enters where navigation doesn't reach. Not on top of it.
Trade-offs
Risks named during the decision, and what I'd watch in implementation.
Alternative — keep the side menu, which already supported everything.
Decision — a bottom bar with four fixed destinations.
What it costs — four is a ceiling, and the app will grow.
What I'd monitor — whether the first new feature triggers a request for a fifth icon. If it does, the answer is revisiting the hierarchy, not adding an icon.
Alternative — the assistant as the way into the app.
Decision — interface for the predictable, AI for the variable.
What it costs — the new feature is less visible than the investment in it would suggest.
What I'd monitor — whether assistant conversations are about things the interface couldn't have answered.
Alternative — modals, which solve the space problem.
Decision — cards that expand in place.
What it costs — the page gets long, and older editions fall under the floating bar.
What I'd monitor — whether the list grows to the point where expanding stops beating a dedicated place.
Alternative — keep every statistics column from the old app.
Decision — four visible columns, the rest on horizontal scroll.
What it costs — anyone wanting full stats has to discover there are more.
What I'd monitor — whether standings still read at a glance, which is what the screen is opened for.
Testing & Metrics
To test whether the redesigned navigation could answer predictable questions without relying on the assistant, I ran a usability test with five padel players — two with previous league experience, three who had never played a league — on the interactive prototype, remotely, across four tasks.
1 · Finding the next match
Task — you've just been paired in a new league. Find who you play next and when.
Result — 5/5 succeeded, average 2.2 taps. No one opened the assistant.
The expected information was found where it should be — directly in the interface, not through the AI layer. This supported the core decision behind the redesign: the interface answers what's predictable; the assistant handles what's variable.
2 · Switching leagues
Task — you're in two leagues. Switch to the other one and see your position.
Result — this was the task with the most friction. 3/5 completed it without help; 2/5 understood they needed to change league but initially looked for the second league inside the current league's content, rather than treating the league itself as context. Both who struggled had never played in a league before.
This exposed the remaining weakness in the architecture: the league was behaving correctly as a context in the system, but the interface didn't make that mental model obvious enough.
3 · Finding a past league
Task — find the league you played last winter and see where you finished.
Result — 5/5 succeeded, average 3.6 taps. Participants consistently went through the leagues area and distinguished active from past editions. History wasn't treated as a hidden archive — it was recognised as part of the product.
4 · Finding an answer about an unavailable partner
Task — you have a question about what happens if your partner can't play. Where would you go?
Result — 5/5 opened the assistant. This was exactly the intended boundary: not something participants expected to find as a persistent destination in the navigation, and nobody tried to force the interface to answer it.
What changed because of it
The test supported the main navigation principle but exposed a structural issue in league switching. The bottom bar itself wasn't the problem — the league selector was still competing with the idea of the league as a destination. I'd keep the four fixed destinations, but make the active league more explicit and persistent within the league area before implementation.
The important result wasn't that every task worked. It was that the predictable information stayed in the interface, while the assistant remained reserved for questions the interface couldn't reasonably answer.
What I'd still instrument
Hypothesis — the redesign moved predictable answers into the interface, in production, at scale.
Test — classify assistant conversations by whether the answer was two taps away.
Metric — percentage of conversations about things already two taps away. This is the counter-metric: above roughly a third, navigation is still failing and the chat is covering for it. The moderated test showed 0/5 doing this for task 1 — production traffic is the real test.
Hypothesis — matches move from WhatsApp into the app.
Test — match-arrangement events in-app against self-reported arrangements.
Metric — share of matches arranged inside the app.
Neither is running yet. Five moderated sessions show the navigation is legible on first contact; they don't show what happens once the app carries a live season's traffic.
Learnings
A new feature is a good reason to look at the whole house. The client already had that instinct and it was right — but for a different reason than aesthetics. Adding an assistant to navigation that fails doesn't modernise anything: it institutionalises the failure and gives it a chat window.
Removing something is harder than replacing it. The side menu did two jobs and I only noticed the second after taking it out: switching the active league had disappeared and nothing in the new screens replaced it. The fix took three attempts — blocks inside the screen, then a dropdown, then a dedicated screen with expanding cards. The mistake wasn't removing the menu. It was treating one element as if it had one function.
The decision that most needed testing is the one I tested, and it was the one that struggled. The four-destination bar itself held up — 5/5 on finding a match, 5/5 on finding history — but league switching was exactly where the two players new to the format got stuck. Validating with the team and client first told me the model was coherent; testing with players told me where it wasn't legible yet.
What's still open
The four-destination ceiling is untested against real growth. It's a structural bet made on a product with an active roadmap, and five short sessions don't test what happens as features accumulate.
The league-switching fix hasn't been tested — only the problem it fixes has been confirmed. I know the current design loses 2 of 5 first-time players; I don't yet know if a more explicit, persistent league indicator resolves it.
The assistant's scope is defined by exclusion, and that only holds if the interface actually covers the predictable. The moderated test supports that it does, for these four tasks; production traffic is the real test.
