What is playvs?
PlayVS - official scholastic esports for middle and high schools
PlayVS is North America’s largest scholastic esports platform. We help middle school and high school programs run organized esports seasons in E and T rated titles.
Schools use PlayVS to schedule matches, manage leagues, and track standings, so students can compete, connect, and build real teamwork and leadership skills through gaming.
Schools use PlayVS to schedule matches, manage leagues, and track standings, so students can compete, connect, and build real teamwork and leadership skills through gaming.
Brand architecture
PlayVS includes our core Scholastic product (high school & middle school), Stadium (amateur competition), Live Events, and our internal league setup tool, Checkpoint.
PlayVS by the numbers
Impact at a glance
MY ROLE
What I own at PlayVS
I wore a lot of hats at PlayVS. I split my time between system-level work and shipping core esports experiences – from our Nexus design system that powers our UI to the flows coaches and players rely on every week.
My main focus areas were:
Competitive Experience – League, schedule, standings, enrollment and match flows for coaches and players.
Design System – Owning Nexus for web: tokens, components, and documentation.
Illustration & Icons – On-brand, reusable visuals that scale across product surfaces.
Publisher Experience – Translating publisher requirements into clear display rules in product – how games, logos, and marks are shown so we stay compliant and still feel cohesive.
Awards & Recognition – Designing player and team award experiences (player profiles, certificates, badges, end-of-season moments) that celebrate achievement and make competition feel meaningful.
Sponsorship – Designing sponsor moments (dashboard, match experience, and navigation) that feel additive, not intrusive, to the competitive experience.
IMPACT
Platform-wide product impact
- 25% Team creation increase
- In tandem with match assistant feature participation increased by 67%
- Forfeits reduced by 74%
- Support Tickets reduced by 36%
- 97% Checkins in 2024 (only 62% in 2023)
- 1.5M Chats in 2024
- In tandem with match assistant feature participation increased by 67%
- Forfeits reduced by 74%
- Support Tickets reduced by 36%
- 97% Checkins in 2024 (only 62% in 2023)
- 1.5M Chats in 2024
WHO WE DESIGN FOR
Teacher-coaches & competitive esports players
Coaches are full-time teachers first and part-time esports coaches with very limited time, often not gamers at all.
Players care about fairness and progress – they want to know if results are updated, where they stand in the league, and how they’re improving over the season.
Players care about fairness and progress – they want to know if results are updated, where they stand in the league, and how they’re improving over the season.
pROBLEMs & context
Constraints across the company
User problems
Coaches need one place to figure out how their season works – what’s coming up, what’s due this week, and how to keep their teams on track.
Players just want to clearly see who they’re playing, how they’re doing in the league, and whether their results actually count.
Business / ops constraints
Had to respect lots of real-world rules – state associations, NFHS, publishers – while still giving schools one simple way to run a season.
Shift ops away from “are we in the playoff?” tickets toward the high-touch work that really needs humans – reschedule negotiations, eligibility questions, and match disputes.
Technical constraints
We were layering new league experiences on top of an existing data model for matches, weeks, and scores – no freedom to “re-architect the season” from scratch.
Engineering bandwidth was shared across multiple product bets, so every design choice had to minimize new logic, reuse patterns, and be realistic to ship.
Design system constraints
We were building the league experience and the Nexus design system in parallel, so each pattern had to ship as a feature and hold up as a reusable component.
With design system work sharing sprints with feature work, we had to prioritize which elements to fully systematize (tokens, variants, docs) and which could stay as interim solutions.
core concepts - preview
One league model, many surfaces
We anchored every experience around a single season hierarchy: Esports → League → Season → Match.
Coaches think in this order, so the data model and UI follow the same structure.
before
League pages existed, but no one felt “at home”
No context: Coaches landed on a bare league page and still couldn’t answer basic questions.
Fragmented: Players had no clear place to see where they stood in the season — the experience felt boxed in, not like a clear, “limitless” path through competition.
Framing question: If a league is the home of a season, what should a coach see in the first 10 seconds?
ESPORTs LOOK & FEEL
Esports branding: making each title feel like its own arena
Gave each esport its own hero treatment on the league page – key art, logo, and title-specific color blocking so Rocket League doesn’t feel the same as VALORANT or League of Legends.
Used color-backed banners and cards for leagues and seasons, so coaches and players can tell “which game / which league” at a glance, before reading any text.
CORE EXPERIENCEs
Framing the league: one template for very different leagues
Turned messy league docs into a standard season config: start/end, deadlines, roster lock, match day, team size.
Mapped that config into fixed UI blocks on the overview (key dates, my teams, resources).
Ops now spins up new leagues in the internal tool, and coaches always see a familiar layout with league-specific details filled in.
CORE EXPERIENCEs
Matches: “Who’s playing who in this league?”
Matches tab shows all fixtures in this league & season – not just your team – so coaches and players can see how the bracket is unfolding and who’s played whom.
The same match card + status system (scheduled, final, forfeited, bye, no-show, dispute, etc.) makes it easy to scan which games are locked in and which are still in flux.
Schedule remains the place for “my team’s upcoming matches”; Matches gives the league-level context, helping with scouting, fairness, and understanding the full competitive picture.
CORE EXPERIENCEs
The biggest challenge: clarifying match states
We expanded from just “pending/final” to explicit states like bye, forfeited, double forfeited, no show, disputed, rescheduled, each with a consistent visual pattern so coaches and players can instantly see who actually won and which games are still in flux.
CORE EXPERIENCEs
Standings & results: “Are we in the playoffs? Where are we in the league?”
Standings roll up all match results for this league and season into a single, scannable table.
Clear seeding and status tags (clinched) help coaches, players, and parents see where they stand and when results are final.
Applied the same esports visual language (colors, icons, team styling) while keeping the layout accessible and easy to read.
CORE EXPERIENCEs
Playoffs & brackets: Path to championship
Turned a dense playoff tree into a scannable bracket so coaches, players, and parents can instantly see who advances next.
Wove in esport-specific branding – league colors, game art, and hover states – so the bracket feels like a live tournament experience, not just a generic table.
REUSING THE SYSTEM
From league standings to live event brackets
We started with a standings + playoff bracket pattern for scholastic leagues – the same data model feeding rank, seeding, and progression.
When PlayVS Live launched for in-person tournaments, we reused and extended this bracket component instead of designing a one-off UI for events.
For the team, it proved the value of thinking in systems: one well-designed bracket pattern powered multiple products, cut build time, and kept the competitive story consistent end-to-end.
CONSTRAINTS & TRADEOFFS
Designing a league page that works in the real world
Season progress bar – Coaches wanted a simple “how far are we?”, but league formats, bye weeks, and make-ups all differ by state and publisher. One pattern would either be wrong often or explode into variants, so we didn’t ship it here and instead used it later in PlayVS Stadium where we control the schedule.
Publisher requirements – Nintendo required ESRB and platform badges on every surface using their assets. Instead of bolting logos on page by page, we created a reusable “compliance band” pattern and applied it across leagues.
Design system vs. delivery – Components like the match schedule deserved full design-system treatment, but with tight timelines and limited engineering bandwidth, I sometimes prioritized shipping the league experience on time and parked deeper systemization work for a later.
REUSING THE SYSTEM
PlayVS Stadium: Building on the same league model
Stadium events reuse the same esport → event → match model from scholastic, so we didn’t start from a blank page.
We adapted the league hub template into an event hub for amateur esports competitions – same structure (overview, schedule, standings/bracket), different context.
This let us spin up Stadium within weeks quickly while keeping the experience familiar for coaches and players, and proved the value of designing reusable patterns instead of one-off pages.
internal management tool
Designing Checkpoint, PlayVS control room
While designing the league experience for coaches and players, I also shaped Checkpoint, our internal tool that powers users, teams, schools, leagues, and matches behind the scenes.
Translated the same esport → league → season → match model into admin-friendly flows: creating seasons, configuring rules and key dates, seeding brackets, resolving match issues.
Focused on safety and scalability – clear defaults, validation, and guardrails so ops can manage dozens of leagues without breaking data, and the public UI always reflects a reliable source of truth.
DESIGN SYSTEM
Common components that tie the experience together
Pulled recurring UI from feature work into Nexus components – league cards, key-date blocks, match rows, tags/chips, status banners, and hub layouts.
Defined clear props and states (season state, enrollment state, match state) so the same components could be reused across product interfaces.
Documented usage, do/don’t, and accessibility notes in Figma and Storybook so designers and engineers could adopt components without a 1:1 walkthrough.
This reduced one-off UI and made launching new leagues/titles mostly a configuration problem instead of a redesign.
DESIGN SYSTEM IN PRACTICE
Doing system work inside feature sprints
Treated design system as part of feature delivery, not a side project – whenever a pattern appeared twice, I split out a DS ticket (component, variant, token, asset rule) alongside the feature story.
Worked with PMs to pair feature stories with small DS stories that unlocked multiple surfaces (e.g., one match component powering league, team, and event views), framing it as future velocity and fewer one-off bugs.
Tracked DS progress in Jira with a simple flow – designed → documented → built → adopted – so the team knew which pieces were safe to reuse and which were still “feature-only.”
Built the esports asset library the same way: as we shipped new titles and leagues, we standardized logos, ESRB/platform badges, and publisher rules into a reusable pattern instead of re-solving them for each release.
reflection
What I’d change if I did it again today
Go mobile-first for the core flows:
Start with small-screen versions of league hub, schedule, and match reporting, then scale up to desktop – closer to how coaches actually check details and fix issues.
Companion app:
Push harder for a lightweight companion app focused on weekly matches and notifications – coaches are already on their phones between classes, but we never got past desktop-first due to limited engineering bandwidth.
Integrate ops workflow into the UX:
Bring more of ops reality (reschedules, no-shows, disputes) into the earliest flows instead of layering them on later, so the system feels robust from the first release.
Design system first, not after:
Pull match rows, key-date blocks, and status pills into the design system as they’re being defined, instead of after launch, so new leagues/titles automatically benefit from the systemized version.
Get closer to the numbers, earlier:
Our work on leagues was very design-led, and PMs mostly owned the metrics. If I did it again, I’d be more proactive about defining a small set of league health signals up front – missed deadlines, reschedule rate, dispute volume, “where do I find…?” tickets – and ask for regular visibility, so we can use data to steer second and third iterations, not just qualitative feedback.
