January 2025 – April 2025
Overview
Ultimate Statsheet is a mobile app concept for recording Ultimate Frisbee statistics from the sideline. I used research with players and coaches to prioritize quick entry, map the user flows, and design a high-fidelity prototype.
Player actions, recent entries, and undo share one recording screen; its density still needs live-game testing.
My role
My work connected the scorekeeper’s needs to the product scope, onboarding, team management, and live-entry interactions. The prototype focuses on recording and correcting actions while the game continues.
Problem
I play Ultimate, so I knew how easily stats could be missed from the sideline. I wanted to understand what a phone-based tool would need to do for the person responsible for tracking the game.
I surveyed 24 potential users through the UF Ultimate Frisbee Discord and Gainesville Ultimate Frisbee GroupMe, reaching college players and adult club-level coaches. I also reviewed more than nine secondary sources.
The opportunity
Respondents preferred one-tap entry to presets or manual typing. That preference became the basis for a design target of one or two taps per play.
Entry-method preference
Research with 24 players and coaches informed the one-to-two-tap entry target.
Priorities
I gave post-game analytics and detailed player profiles lower priority. Those features could add value later, but the first version needed to support one person keeping stats on the sideline.
Repeated actions, a recent-actions record, and undo support the immediate task of entering a useful record.
Onboarding and team management prepare the roster before live entry. Richer analytics should not drive the core recording flow.
Live recording comes first, with roster preparation supporting it and deeper analytics deferred.
Prepare once, record during play
Onboarding and roster setup lead into a live-entry loop with a route for correction.
Interaction decisions
I mapped onboarding, team management, and live stat entry, then carried the quick-entry priority into the interface. I used real scores and rosters, including Florida Warm Up 2025, to work through the prototype.
The repeated row structure lets the scorekeeper record a player’s action on the current screen. The tradeoff is density: reducing navigation creates a crowded interface.
Player actions within reach
Record a goal and undo it from the same player row.
Recent actions and undo share the recording screen, so an entry can be checked and corrected without opening another view.
New entries appear in recent history, and undo removes the latest one without changing views.
End Game and Next Point use distinct labels and red and green outlines. Live testing still needs to establish whether these controls are easy to target while following a match.
Two distinct game actions
Next Point advances recording; End Game leads to the game summary.
Iteration
I developed the recording layout from an early wireframe into a high-fidelity screen, keeping player actions and recent history together while adding game context and distinct controls.
Original wireframe
Player rows, repeated actions, and recent history establish the recording model.
Finished recording screen
The prototype preserves that model and adds game context and distinct controls.
These original artifacts show design progression. They do not establish faster live-game entry.
Outcome
The result is a high-fidelity prototype with player actions, history, and undo on one screen. The one-to-two-tap goal remains a design target; live-game performance is untested.
I would test the prototype with a scorekeeper during a tournament, tracking missed plays, interruptions to watching, targeting errors, and correction attempts. Those observations would help establish whether the dense layout supports recording or needs fewer visible actions.
Roster preparation
Team management prepares the player list before recording begins.
Start the game
Game setup connects preparation to the live recording experience.
Reflection
Let the core task set the scope.
Quick entry gave the concept a clear priority and helped me decide which features should come later.
A shorter flow can still create a harder screen.
Keeping actions visible reduces navigation, but the resulting density needs evaluation in the context where people will use it.
Product demo
The original Ultimate Statsheet walkthrough shows the prototype’s flows and interface. It demonstrates the concept, rather than live-game performance.
Next project
Transit you can predict ↗