Scaling a Hockey-First Platform into a Multi-Sport Management System
Role
Senior Product Designer
Context
B2B SaaS • League Management
Period
2022 – 2026
SportNinja platform, 2026
“Absolute joke of an app.”
App Store review, 2023
I joined SportNinja as its first designer. The product was already losing user trust. The mobile app mirrored a hockey only web portal, with no design system, no documentation, and inconsistent UI patterns. Reactive engineering decisions had accumulated for years with no design ownership. My mandate was to fix what was breaking, then build the infrastructure to stop it from breaking again.
Impact and Key Stats
120K+ Total Downloads, 63K Active Users
iOS and Android combined. Up from 9K users and under 10K downloads at the start of 2022.
~91% Fewer Support Tickets
Login and sign-in tickets specifically (235 to approximately 20), tracked via support ticketing categories following the login flow redesign.
~$250,000 USD
Transaction volume from a single competition’s registration, on the new Registration tool.
60+ Minutes Average Mobile Session
Public estimates place typical B2B SaaS sessions around 10 to 30 minutes. Sports platforms differ structurally, since users often leave live-scoring or streaming screens open through an entire match.
9 of 10 Clients
Preferred the V2 navigation structure over V1.5, in directional validation before full engineering commitment.
2.0 star to 3.7 star
App Store rating, 2023 to 2024.
One league operator told us they ran their competition with 3 staff, where comparable platforms typically required 10 to 20. A client statement, not a platform-wide measurement.
Responsibilities
Led navigation and IA redesign, from flat structure to role based hierarchy
Built SportNinja’s design system from scratch: tokens, components, and multi platform libraries
Owned end to end product design across web and mobile, as the platform’s first and only designer
Diagnosed product debt using Firebase and GA audits, plus a 2,500+ user NPS survey
Redesigned the Registration flow, unlocking new subscription tier revenue
Directed SportNinja’s brand refresh: color, typography, iconography, motion
Established design and engineering workflow: component libraries, Dev Mode handoff, weekly Consistency Calls
Led the shift from a hockey only, ad supported app to a 4 tier subscription product across 20+ sports and 15+ leagues
Expanded mobile scope beyond scorekeepers and players to admins and league staff
Ran competitive analysis against 20+ platforms, including TeamSnap, SportsEngine, and LeagueApps
The problem
Built for one sport, and one business model
SportNinja was built specifically for hockey and hockey adjacent sports, with a free, ad supported model. Every screen, term, and workflow assumed hockey. There was no path to expand into other sports or to a paid tier without rebuilding the product’s foundations.
Original hockey specific UI, web and mobile
Mobile served scorekeepers and players, no one else
The mobile app was scoped narrowly to live scorekeeping and player views. Admins and league staff had no dedicated mobile experience, and had to rely on the web platform for anything operational, even while away from a desk.
Original mobile scope, scorekeeper and player views only
No role based access logic
By default, every admin account followed every team across every organization, sub organization, and competition in the league, with no filtering by relevance. There was no way to separate teams an admin managed from teams they simply followed as a fan.
Original permission model, no role distinction, 2022
Search that didn’t work
Searching for a specific team returned every season that team had ever competed in. Looking for the Blue team in one competition surfaced every Blue team across the league’s entire history. Admins scrolled manually through dozens of results to find what they needed.
[Upload screenshot]
Search results, unfiltered by context
Flat navigation, no room to grow
The original navigation, Profile, Games, Teams, Competitions, Organizations, Feed, was a flat horizontal bar with no hierarchy and no permission logic. As the platform’s destination count grew, horizontal space became the limit, and on smaller screens tabs compressed or overflowed.
Original flat navigation, 2022
There was also no shared design system between web and mobile. Components, iconography, and spacing were built ad hoc, screen by screen, by whichever engineer touched that part of the product.
How I diagnosed the problem
Users knows more even when they don't know
I pulled from several disconnected sources: Firebase and Google Analytics usage data across mobile and web, a 2,500+ respondent NPS survey with open ended responses, and direct interview notes. I used Claude to synthesize the open ended survey responses into frequency ranked themes, which surfaced improve user interface and navigation as the single most common request, ahead of scheduling access, bugs, and communication. I also used Claude to cross reference usage drop off patterns from Firebase against reported pain points. This synthesis turned a pile of disconnected complaints into a prioritized case for where design effort should go first.
NPS Survey: Top Requested Improvements
Improve user interface and navigation
23
Make it easier to access schedules
19
Fix bugs and glitches
17
Easier communication and chat
15
Simplify the app
14
NPS Result
-50.36
Population
2,600
Margin of Error
5.56%
Detractors
60.43%
Neutrals
29.5%
Promoters
10.07%
Neutral
Hard league/team management
Neutral
Specific to certain sports
NPS theme synthesis and usage pattern review
Design system
Building the design system
Alongside the platform redesign, I led SportNinja’s full rebrand and design system, built for both web and mobile. This covered color foundations, including semantic and neutral scales, typography for headings and body text, a shared component library including buttons, forms, inputs, and tabs, elevation and blur effects, an icon set built on Material Icons, and UX writing rules for how dates and times display across the product. I used AI tools to accelerate early token and component generation, then refined, tested, and validated everything against accessibility standards, including WCAG contrast ratios, 44 by 44 pixel touch targets, and support for Cyrillic script for international clients, before anything shipped.
[Upload: design system component grid, web and mobile]
Design system components, web and mobile
[Upload: color and typography foundations]
Color and typography foundations
Building credibility through speed
“Right now, every feature requires custom UI work. With standardized components, we can ship 70% faster. More sales ammunition.”
As the sole designer at a fast moving startup, I had to prove design could move the business forward, not only improve the interface. I replaced assumptions with data. I audited Firebase and GA flows, launched an NPS survey with 2,500+ users, and ran interviews that exposed operational bottlenecks. When I pitched the design system to the CTO, I framed it around speed, not visual consistency. That framing accelerated engineering buy in. I set up weekly Consistency Calls and bi weekly design walkthroughs, and changed how Sales worked with design.
[Upload: component library screenshot]
Component library, shared across web and mobile
What I learned
Design has to move the business
UX improvements only matter when they unlock revenue, efficiency, or retention. The design system was approved because I showed it would accelerate revenue driving features, not because it was the right thing to do on principle. Framing initiatives around measurable outcomes secured buy in faster than aesthetics did.
Small wins build the trust for bigger bets
I could have spent six months building a perfect design system. Instead I shipped quick wins within weeks to build credibility, then invested in infrastructure. That early momentum gave me the political capital for longer term bets. Without a team to manage, I still had to lead by making myself useful. Rebuilding sales decks, creating tutorial videos, and embedding in dev sprints made me a collaborator, not a gatekeeper.
If I did this again, I would push for the role based Operations and Dashboard split a full year earlier. We treated it as a v2 refinement, when the underlying permission logic should have shaped the IA from day one.
