Leading the design of Bracket, a social sports app helping people coordinate games and stay active.
Role
Bracket, Lead Product Designer
Teammates
Chaitanya Sekhar
Gaurang Pendharkar
Ian Chiu
Inchara Chetan
Tools
Timeline
Outcome
Scope
Concept
Our winning concept pitch
A social sports app for organizing ranked pickup games, built with Rho Innovate at UW across the 2024 to 2025 school year. My team pitched the idea, and the three of us took it to the final round against two other concepts, winning the project we would pursue for the year.
The survey insights our team gathered
Our pitch deck initially described a potential user as a 25-year-old investment banker in a city. Then we ran a survey, and 19 of 27 people told us they only play with friends or family, while 16 had stopped playing or played only occasionally. It was clear that their desire was there but willingness wasn't.
70%
play recreational sports only with friends/family
59%
had stopped playing or played only occasionally
41%
mentioned safety unprompted in a free-response question
Safety was an unexpected concern
Picking up the role of design
Ranking
The first onboarding prototype
Self-reported skill fails in two ways, since beginners lowball themselves and confident players inflate their levels. I gave the skill question an "I'm not sure" option so uncertainty is accounted for into the system instead of a bad guess, while I tightened the tier ranges so early matches are fairer skill-level wise. Ranked user seeding also shows inside each event description.
User-centered tweaks
Onboarding got the same treatment. A developer learning Figma built the first prototype with a continuous progress bar. Their instinct was right, but the execution hid how much was left in onboarding.
So I moved it to segments with the same signal but countable, and standardized the selection controls: squares for pick-many, circles for pick-one, left-aligned so users read the selection options before the label.
Cutting eight sports to two
After discussing ranking calculations, a risk that came up was that team ratings are unreliable and calibration is worst for a new platform where few matches get played. More sports meant more rating pools, each too thin to rank anybody efficiently.
We cut to basketball and tennis before development started. Tennis because 1v1 Elo behaves the way chess trained everyone to expect and basketball because it is a popular sport on the UW campus!
Weighing the pros and cons of the ranking system
I picked Elo already knowing the problems I would run into, since the team had written the case against it even before a screen was designed. From our brainstorm doc: calibration breaks for new players, the system puts pressure on people, and communities form rating bubbles by only ever playing each other.
I took it anyway, because the benefits provided a holistic and unique approach to gamification. By splitting the Elo into tiers with roman numerals, I prioritized intuitiveness here for users who may be more familiar with numbered levels.
Pros:
Dynamic skill assessment
Matchmaking balance
Encourages competition
Scalable across all levels
Cons:
Outliers
Initial rating calibration issues
Potential for cheating the system
Formation of Elo bubbles
Craft
The players are also the referees in a pickup game, so I designed the logging flow so that both players must submit matching score results for progression. Expenses and notes sit underneath, because players may split a new can of tennis balls or log their statistics.
Unfortunately, we did not resolve the problem of someone who simply never submits or is uncooperative, and we never fixed that. A sportsmanship rating, video recap feature, or an underdog bonus would have been the better answer, and I only worked that out after the project ended.
The celebration screen was the product's biggest moment.
The team built the first version in a working session before the product had a name. We listed what a celebration screen traditionally contains and then put in all of it: a stamina bar, an Elo bar, an experience bar, achievement unlocks, a crowned avatar, and a second character face-down in a puddle that a teammate dropped in as a joke.
Once we landed on Bracket as the name, the result became the identity. I rebuilt the screen around the mark: set scores on the left, the bracket resolving right, a crown on the winner, with two progress meters. Even though the original joke was more humorous, I traded a screen people may have screenshotted for a screen that solidifies brand identity.
Building the messaging flow
One of the nearest things to two strangers trying to meet at a specific place at a specific time is a delivery app, so I took the structure of Uber Eats and kept the match-in-progress status line, which means the thread always states what stage the user is at.
I skipped the quick-reply chips, which I later found was the smart solution. "Are you here?" and "I'm waiting outside" should also have been included because Bracket needed the same thing staged to the matchup: what time works before, are you here during, GG after, etc.
Build
Decisions the UI missed
Home showed a personalized feed and Explore's Join tab showed the same events with a map, so users were browsing the same interface twice. I built both because we wanted one entry point built around what a user follows and another around discovering something new. The developers noticed the overlap before I did, changing the Explore's icon to Host instead, so browsing stayed on Home.
The legacy Explore filters still show Poker, 2v2, and Team, and the host form still says "Football, basketball, etc." as placeholder text, both leftover from before we cut the scope down to basketball and tennis.
Functional in-code prototyping
Reflection
Nine months in, I designed over my own work, editing old frames instead of duplicating them, so I only have the final screens. The design thinking on this case study survives because I documented my processes. I've learned to duplicate before I touch anything now.
Moving fast enough to ship meant I sometimes skipped the step of pinning things down before building on top of them. The team found it difficult to resolve the specific audience Bracket was for. The pitch described one kind of user, the survey described another, and even at the end the target audience carried real ambiguity we hadn't cleared up.
Elo is another clear example. I designed tier badges, seeding, and a whole rank system for a calculation that was reasoned through out loud and incomplete. It looked finished because the screens were finished. I've learned to slow down on exactly the parts that feel most tempting to skip.
