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.
"A lot of people … are intimidated by the varying degrees of skill levels … It would help to pair individuals to play with others who are of similar skill level."
Challenges
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. 16 had stopped playing or played only occasionally. It was clear that their appetite was there but willingness wasn't.
Research
Safety was an unexpected concern
Role
Picking up the role of design
The fall roster initially placed me on app development. As the team shrank partway through the year, we redistributed everything that was left, and the additional responsibility of design landed on me. I was excited to bring my design skills to production as I learned front end code from the developers!
How might we make a game against a stranger feel fair and fun enough to be worth showing up for?
Scope
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. Basketball because it is the sport our team played every week, and it was a popular sport on campus.
Defining the System
Self-reported skill fails in both directions, since beginners lowball themselves and confident players inflate their levels. I gave the skill question an "I'm not sure" option so uncertainty becomes a usable seed instead of a bad guess, then tightened the tier bands so early matches land in a narrow range where being wrong about somebody costs less. Seeding also shows inside each event description before anyone taps join.
Onboarding picking sports.
Responsive and Mobile Thinking
Two progress bars and why
Onboarding got the same treatment. A developer learning Figma built the first pass with a continuous progress bar. Their instinct was right, but the execution hid the one thing people want during onboarding, which is how much is left. 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 you read the control before the label.
Option 1: a continuous bar.
Option 2: segments, so you can count what is left.
Design Approach
I picked Elo already knowing the reasons not to. We had written the case against it before anyone designed a screen. Straight from our brainstorm doc: ratings get unpredictable in team sports, 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 a rating is the only thing that answers "am I about to embarrass myself" before someone commits to a Saturday morning. Base was 1000, borrowed from chess. Then I split the raw number into tiers with roman numerals, because 1214 means nothing to a person who has never played ranked anything, while a badge reads in half a second.
Match results. Both entries have to agree before anything records.
Wireframes and Iterations
Nobody referees a pickup game, so I designed the logging flow so that both players submit the result and nothing records unless the numbers match. Expenses and notes sit underneath, because splitting a can of tennis balls is part of what happens on the court.
Unfortunately, we did not resolve the problem of someone who simply never submits or is uncooperative, and we never fixed that. A sportsmanship rating on the profile or video recap feature would have been the better answer, and I only worked that out after the project ended.
Research and Inspiration
The team built the first version in a working session before the product had a name, with Clash Royale as the reference. 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.
The joke was funnier than what replaced it. I traded a screen people would have screenshotted for a screen that says what the app is, and I would make the same call again, though I do still miss the puddle…
First pass, with Clash Royale as the reference. Four meters, and a loser in a puddle. Avatars are placeholder art.
Rebuilt around the bracket mark once the name landed.
The courier chat I borrowed from, beside what I built. Status line kept, chips missing.
Brand Alignment
Building the messaging flow
The nearest thing to two strangers trying to meet at a specific place at a specific time is a delivery app, so I took the structure of one and kept the match-in-progress status line, which means the thread always says what stage you are at.
I skipped the quick-reply chips, which I later found was the smart solution. "Are you here?" and "I'm waiting outside" should have been included because Bracket needed the same thing staged to the matchup: what time works before, are you here during, GG after, etc.
High-Fidelity Redesign
A library checklist built for engineers
What I built was a component library for engineers to check against: tab bar with five states, selection controls, event cards, rank meters, match components, etc.
We set up the first framework on Flutter in October, then moved to Expo. By December 2024 the front end worked on a device: home feed with search, category rows, filter chips, the map, chat.
I worked with four developers to produce the front end while each worked a separate slice of accounts, scoring, database, ad hosting. I reviewed pull requests to keep the build and the file from drifting apart.
Reflection
I designed over my own work for nine months. I edited old frames instead of duplicating them, so I have the final screens and almost nothing that came before. The reasoning on this page survives because I wrote things down in documents. I've learned to duplicate before I touch anything now, a boring lesson I paid full price for.
Our target market slide described John, 25, an investment banker at JP Morgan who plays basketball and volleyball. 19 of my 26 aged respondents were under 25, most of them UW students. When the findings were real and described somebody else entirely, I also realized I never went back to rewrite the deck.
The frames I still have, and the versions I wrote over.