No club, no commitment: designing the moment a stranger asks to join your game.

Schedules fill up, people relocate, and the friends you used to play with scatter. Clubs and classes offer a way back in, but they ask for a long-term commitment that not everyone can make. So someone who just wants a game on Sunday has nobody to ask.

I looked through community platforms, Reddit threads and online discussions about recreational sports. This was desk research, not interviews, so the three themes below are informed starting points, not validated findings. Each one went straight into a screen.

The player is someone who has not played in a while, is new to the app, and does not know the host. The table follows that one player. The middle column is the question I assumed they have at each step, which is my design intent and not research. The right column is the call I made to answer it.

Why I chose Browse and Join over creating a game, a feed or booking a court

Four ways to answer the same brief were on the table, and three of them made the player do work before they could play. Court booking was the brief's own example flow, and I still set it aside.

The trade-off is real: Browse and Join gives up everything a host would want, such as creating and managing a session, and it only works if games already exist nearby. I accepted both for one reason. It asks nothing of a player who just opened the app. The security worry went into the request itself, through the note (decision 2).

Nothing was tested with players, so this is a judgement about friction, not a measured result.

Why a request to join carries an optional note, and is never auto-accepted

Joining means asking a host to say yes to a stranger. My first idea was to remove that question: auto-accept anyone verified. I dropped it, because it takes the organiser out of a decision that belongs to them, and a verified user can still be the wrong fit for a specific game.

That left the host deciding on a faceless request. So I borrowed LinkedIn's connect with a note: up to 300 characters, so a request arrives as an introduction. The host reads it, and can open the requester's profile, games played and rating, before accepting.

I considered making the note mandatory and rejected it. A required field costs the most at the moment someone is deciding, which is the drop-off point I least wanted to touch. So the sheet nudges, and Maybe later sits under the primary button as plain text with no visual weight.

The sheet's copy says hosts approve requests with notes 3x faster. That number is a claim written into the concept. I did not measure it, and it would need real data before it belonged in a product. The working mockups show the copy getting there: an early version said only that hosts approve faster with a friendly intro.

After sending, the player waits, which is where a note could feel like it vanished. The pending screen echoes it back, so the player sees exactly what the host received. A Pending host approval chip says nothing is confirmed yet, and Browse more games stops the wait from being a dead end.

What is still unknown is whether hosts read the notes at all, and whether a note raises approval or only adds writing for the player. That is the first thing I would test.

Why the organiser comes before the date, time and place

The research said people are uneasy about who shows up. The alternative was to lead with when and where, the facts needed to decide. I reversed that: if the host does not feel trustworthy, the time and place do not matter, so the player reads the person first.

It also answered the stranger concern inside the flow, without adding a step. The cost is that the practical facts sit one card lower, and the verified badge only signals trust, because real verification was out of scope. I did not test whether players read the card in this order.

Why every card shows an age range and a distance, and no skill level

Matching by skill level was the alternative, and the research pointed somewhere else: people want to play with someone in the same phase of life. Skill cannot be verified. Age can. So each card answers the question people actually ask, is this my kind of crowd?

Distance sits beside it, because a great game 15 km away on a Sunday morning is not practical. The host sets the age range and players cannot change it, which keeps the crowd the host intended.

The trade-off is exclusion. An age range can shut out someone who would have fit the game perfectly, and a mixed-skill game has no skill signal at all. Both rest on desk research, not on players, so they stay assumptions.

Why I took the cost out of the screens

The working HTML mockups from 23 June show a version of the flow with money in it: a rupee-per-head price on the game cards, a cost badge, a price on the Request to join button and a payment reminder on the confirmation. The submitted screens have none of it.

My reasoning, from the project file: casual sports in India are social, not transactional, so cost was removed from the whole UI. If there is a ground fee to split, that happens in the group chat after confirmation.

What I gave up is clarity. A player may want to know what a game costs before asking to join, and pushing the fee into the chat moves an awkward conversation to after the commitment. I made the call to keep the request about people, not payment, and I did not test it. It is the assumption I would be least surprised to see fail.

Everything was sketched on paper before I opened Figma. Two sheets cover the whole flow, and the first one is where the dashboard was still undecided: one concept with a hero banner, one without it and with filter chips instead. The submitted dashboard uses the chips.

The note sheet, the echoed note on Request Sent and the accepted screen are all already on sheet 2, so the core layout of the request flow was settled on paper. Figma adjusted it, it did not redesign it.

Between the sketches and the submitted screens there are three working HTML mockups of the flow and a colour reference. These are the iterations I can show from files that exist today. Their file dates are 23 June 2026, and I treat the order as Mockup 1 to 3.

The journey above shows the order. These are the calls inside each screen, at the top and scrolled.

These are design assumptions, not validated findings. The project file does not include user testing that confirms them.

GameON was never launched and nothing below was measured. These are hypotheses I would want to test, each tied to a decision above.

The decisions I would defend most are about where to add friction and where to remove it. Creating a game, auto-accepting and a mandatory note each moved effort or control to the wrong place.

What I would test first, in this order: whether hosts read the notes at all, whether the age range excludes people a host would have welcomed, and whether players want to see a price before they ask to join. The first checks the 3x claim, the second checks decision 4, and the third checks the assumption I would be least surprised to see fail.