Current State
The existing tool captured basic scoring.
The iPad scorekeeper helped operators update points during live games, but it did not capture the deeper athlete-level data that could make BallerTV’s footage and game experience more valuable.
2019–2020
Scorekeeper App
Aligning Product Direction Through Research
The Scorekeeper App focused on improving the workflow used to capture live sports data during games. Through extensive field research, usability testing, and in-context observation, I worked to understand how scorekeepers operated under real-world conditions where speed and accuracy were critical. The project included stakeholder alignment across teams, iterative testing of competing solutions, and the development of a functional prototype that allowed us to validate workflows before engineering investment. The result was a clear product direction supported by both users and stakeholders.
Context
BallerTV wanted to turn scorekeeping into richer live game data.
BallerTV already used an iPad-based scorekeeper at events to control basic points during live games. The next opportunity was to capture more detailed athlete and game data — the kind of information AAU tournaments and other events often tracked through paper score sheets.
Business Need
Richer data could unlock more value.
More detailed scoring could support athlete stats, better game context, improved viewing experiences, and future product opportunities around player performance.
Design Challenge
Live scoring leaves little room for friction.
Any new interface had to work in a fast, distracting event environment where scorekeepers needed to follow the game and enter data quickly.
Opportunity
The opportunity was not to digitize paper — it was to understand what made scorekeeping work.
Because detailed scorekeeping already existed on paper, the obvious direction was to recreate that workflow on an iPad. The deeper product opportunity was to separate the behavior from the artifact: what parts of paper scorekeeping needed to be preserved, and what parts could be improved through a digital interface?
Capture more than the score
The product needed to move beyond points and support richer athlete and game data without overwhelming the person operating the scorekeeper.
Preserve speed under pressure
Scorekeeping happens while the game is moving. The interface needed to support fast recognition, quick entry, and easy correction.
Choose the right interaction model
Before committing to Apple Pencil, touch input, or a paper-like layout, the team needed to understand how scorekeepers actually behaved with an iPad in hand.
Workflow Research
Existing paper score sheets helped reveal what detailed scorekeeping required.
Basketball and volleyball score sheets showed how trained scorekeepers captured player actions, fouls, scoring, rotations, periods, and game flow. The research helped clarify the information architecture behind scorekeeping before moving into interface design.
Workflow Research
Basketball scoring sheet
Basketball scorekeeping showed how player activity, fouls, scoring, periods, and game flow were captured in a dense but familiar paper format.
Workflow Research
Volleyball scoring sheet
Volleyball scoring introduced a different set of conventions, reinforcing that live data capture needed to account for sport-specific workflows.
Testing the Assumption
The Apple Pencil concept exposed the limits of recreating paper on a screen.
- 01
Nobody picked up the Apple Pencil
Even when the stylus was available, scorekeepers used their fingers instead. Touch input felt more immediate during live scoring.
- 02
Handwriting made the data hard to read
Whether users wrote with a finger or Pencil, the output could still become messy and inconsistent. Athlete data needed to be readable after the game, not just recorded in the moment.
- 03
The paper layout became too cramped
Trying to fit every scoring field into one paper-like screen made the interface dense and difficult to scan while following live play.
Field User Testing
The second field test explored how scorekeepers should enter points and athlete data.
After the Apple Pencil direction proved too messy and overwhelming, the next round tested different touch-first scoring models. The goal was to understand whether scorekeepers should add the overall score first, record athlete-level data first, or use more direct point-entry controls.
Design A
Overall score first
Tested whether scorekeepers would add the overall team points first, then assign athlete data afterward. The point adder stayed near the top of the score to keep the main game state visible.
Design B
Athlete data first
Tested a model where each athlete and their scoring input came first, without a separate overall-score button. This explored whether team score could be built directly from player-level actions.
Design C
Direct +2 / +3 inputs
Replaced a generic add button with specific +2 and +3 controls for each athlete, testing whether more explicit scoring actions could reduce extra steps and decision-making.
Design D
Keyboard-supported input
Added a keyboard interaction after the first Apple Pencil test showed that users expected one to appear and that entering all data through a paper-like interface would feel overwhelming.
Result
Design C became the strongest direction because it matched how scorekeepers thought about scoring.
The test showed that users did not think about team points and athlete data as separate sequential steps. They understood scoring as one connected action: who scored, and how many points did they add?
Keyboard input performed the worst
The keyboard pulled scorekeepers out of the live scoring flow and made the experience feel slower, heavier, and more manual.
Athlete and score were intrinsically linked
Users did not think of adding points first and assigning athlete data later. The scoring action and the athlete action needed to happen together.
Surfaced +2 and +3 buttons were preferred
Design C was the favorite because the scoring actions were visible at the athlete level, reducing extra steps and making the flow easier to understand during live play.
Internal Testing
Internal testing compared speed against input accuracy.
When the event schedule slowed down during back-to-school season, testing continued internally with a semi-working UXPin prototype. Participants were asked to scorekeep from a five-minute game clip so the team could compare how different input models performed during simulated live play.
Prototype A
All actions surfaced
Prototype A placed all scoring actions directly on the screen without additional modals or pop-ups. This made the actions visible, but the number of controls created smaller tap targets and a higher risk of input mistakes.
Prototype B
Category add buttons with modal
Prototype B placed a plus button next to each athlete category, then opened a modal to select the addition. This made the interface feel cleaner, but added extra taps to complete a scoring action.
Result
70% of users preferred Prototype B, but the result revealed a tradeoff.
Prototype B felt cleaner and easier to understand because it reduced the number of visible controls on the screen. However, the extra modal step slowed down the scoring flow, while Prototype A’s surfaced actions were faster but harder to tap accurately.
Prototype A was faster but visually crowded
Surfacing every action reduced extra steps, but the button sizes became too small to reliably tap during scorekeeping.
Prototype B felt cleaner and more controlled
Most users preferred the modal-based version because it reduced visual density and made the screen easier to process.
The next direction needed to balance both
The strongest path was not simply A or B. The design needed the clarity of Prototype B without making users work through too many extra taps.
Final Prototype
The final test evaluated substitution tracking and the final scoring direction.
A scorekeeper built for the pace of the game.
The second round of internal testing focused on substitution because the previous test revealed uncertainty around how athletes should move in and out of active play. The final prototype also replaced the modal-based point entry with an overlay button layout, making athlete scoring actions more immediate.
Final Direction
The first version focused on fast scoring over complete athlete tracking.
After multiple rounds of testing, the team used the research findings to define a more practical first version of the scorekeeping app. The goal was to capture richer data than the existing scorekeeper without adding workflows that would slow scorekeepers down during live games.
- 01
Athlete names were deprioritized
Scorekeepers did not always have time to collect full athlete names from coaches before or during an event. Jersey numbers became a more realistic way to identify players in the first version.
- 02
Overall score still needed a fast path
Scorekeepers sometimes needed to quickly add points to the team score without assigning them to a specific athlete. The design needed to support that fallback to reduce scoring delays, even if it introduced some room for error.
- 03
Substitution tracking was removed from the first version
Subbing patterns varied too much across teams and events. Instead of requiring scorekeepers to sub players in and out, the direction shifted toward a long athlete list that could be rearranged as needed.
Outcome
The research helped define a realistic first version of the scorekeeping app.
The final direction moved away from recreating paper scorekeeping and toward a practical live scoring tool. By testing assumptions early, the team clarified which data was essential, which interactions slowed users down, and which features should be simplified for version one.
Research
Invalidated the Apple Pencil direction.
Testing showed that scorekeepers did not use the stylus and that handwriting created readability and density problems.
Product
Reduced scope for the first version.
The team deprioritized athlete names and substitution tracking so the app could support real event conditions without overloading scorekeepers.
Design
Prioritized speed and flexibility.
The final direction supported quick team scoring, jersey-number-based athlete tracking, and a rearrangeable athlete list.
Reflection
The biggest design decision was knowing what not to build yet.
This project reinforced that strong product design is not just about solving every problem at once. Athlete names, substitution tracking, and full paper-scorekeeping parity all sounded valuable, but testing showed they could slow down the core workflow. The better first version focused on speed, jersey numbers, flexible athlete lists, and a scoring model that fit the pace of live games.