WBD Sports Design System
Stadium
Knicks107
Spurs106One shared set of components. Documented, co-owned by design and engineering, and built on by every WBD Sports product.
01 — Overview
One system behind every WBD Sports brand. Multiple identities. Built once.
Stadium is the design system for WBD Sports. One shared set of components, documented and co-owned by design and engineering, that sports products across the organization build from.
Sports runs on shared conventions, a score, a standings table, a live game state, a bracket. The shape of those is largely settled, easy to share and expensive to reinvent for every brand that needs them.
So Stadium shares the hard parts, the structure and the logic, and keeps separate only what should differ, the look and feel. Each product keeps its own brand while drawing from the same parts underneath. The organization solves a hard problem once instead of redrawing the same score card in a fifth brand's colors.
Stadium by the numbers
- 78%
- fewer components — from more than 250 down to roughly 55, built to flex instead of multiply.
- 7
- product designers building with it, across two design teams.
- 6
- products live on it — the Bleacher Report and March Madness Live apps on iOS and Android, plus bleacherreport.com and NCAA.com.
That is where it ended up. It started somewhere a lot smaller, inside one app.
02 — Opportunity
A new app, a blank slate underneath it, and the perfect moment.
This starts with an all new Bleacher Report. We were replatforming the app, B/R 2.0, and I was art directing a completely new UI for it. There was a prior design system, but it was not sophisticated, modern, or complete, and the new interface made it irrelevant anyway. We needed something built for where we were headed, not where we had been.
The real opportunity was not just to redesign an app. It was to create the solid foundation underneath it.
03 — Role & Scope
From a problem everyone agreed on to a system that shipped and stuck.
My job was to take this from a problem people agreed on to a system that shipped, held up, and kept evolving after launch.
That meant working at every level. Making the strategic case to stakeholders. Setting the philosophy and the architecture. Picking the right designers and pointing them at the right parts. And standing up the operating model that would let the system grow once launch was behind us.
I led the team that decided what we were building, why it was worth it, and how we would keep it alive.
- Role
- Design lead — strategy, architecture, governance
- Scope
- WBD Sports — 6 products, 2 brands
- Team
- 7 designers across 2 teams, co-owned with engineering
- Year
- 2024–2025
04 — Making the Case
Components are easy, process is hard.
The components are the easy part. The hard part is organizational will. You can design the best system in the world and it still dies if the people funding it and the people meant to use it do not want the same thing.
So I started there. I took the idea to the stakeholders who could move it, the ones with pull over resourcing and direction, and I sold it before I built it. I listened for what they were worried about and what they wanted out of it, and I set goals we could actually hit. By the time the work started, the support was real and the expectations were honest.
That groundwork is why the system shipped instead of stalling.
05 — Token Foundation
Define every value once. Change it everywhere.
The architecture call I cared most about was tokens. I set the system on a token foundation (a bolder move in 2023 than now), every color, space, and type size defined once as a named value, then referenced everywhere instead of hardcoded, and had the designers build it out from there.
That choice cost time up front. It is more to set up and more to think through before anything visible exists. But it bought two things worth far more than the cost.
The first is reach. A token system stretches to new platforms and new products without being rebuilt, because the values live in one place and every surface just points at them. Change the token, change everything downstream. That same structure is what lets AI-assisted workflows plug in, since they need named, structured values to work against.
The second is a shared language. Design and engineering ended up naming the same things the same way, down to a one-to-one mapping between design tokens and code variables. A token is not a design word or an engineering word. It is both. So the handoff stops being a translation.
06 — Governance
The real risk shows up six months after launch.
The biggest risk to a design system is not launch day. It is six months later, when new patterns start showing up outside the system and nobody planned for how they get in.
So I made governance part of the deliverable, not a thing we promised to sort out later. I wanted a clear contribution path in place from the start, a defined way for a new component to get proposed, reviewed, and merged, with the documentation and channels to support it. The system had to absorb new work instead of being routed around.
- Understand request
- Assess implications
- Update or add component
- Review with team
- Write documentation
- Publish to library
- Update spec file
- Verify requirements
- Break down work
- Estimate effort
- Ticket the work
- Implement in code
- Test and ship
A system you cannot add to becomes a museum. People stop contributing and start working around it. I wanted the opposite. Something that keeps growing without losing its shape.
07 — Built to Flex
Fewer components, more give.
We chose to build fewer components and make them bend, instead of trying to cover every case on day one.
A giant library looks impressive and ages badly. Every component in it is something to maintain, and the ones nobody uses still rot. So we built a smaller set with more give. Enough range that a designer can stretch a component to a new situation, and enough discipline that an engineer can trust it to behave.
Fewer parts, more reach. That held up better than completeness would have. The cut from more than two hundred and fifty components to roughly fifty-five is that decision, measured.
3LAL145
3GSW144One score-card component, three contexts — a compact strip cell, a full scores-page card, a gamecast scoreboard. Same parts, reflowed.
08 — Building with the Team
The people who built it became its champions.
I made a point of not building this alone, even where I could have moved faster solo.
The team ideated, built, and presented the system. Their input shaped the real decisions, not the cosmetic ones. That was deliberate, and it was about adoption as much as quality.
People reach for a system they helped shape. They work around one that lands on their desk finished. So the team that built Stadium became the people who championed it after, without my asking, because by then it was theirs too.
09 — Many Faces
Shared foundation, unique design.
The opener promised that every product keeps its own brand. This is how.
The shared layer is structure and behavior. The component itself, how it is built, how it responds, what it is made of. The themed layer is identity. Color, type, the feel of the thing. Because everything resolves through tokens, a brand is mostly a set of token values, not a fork of the system. Point a match card at one set and it reads as Bleacher Report. Point the same card at another and it reads as NCAA. Same structure underneath, a different look on top.
UNC-2.5
NCSTO/U 145UNC(0-0)————65NC STATE(0-0)————62UNCNC STATEOne gamecast screen, two brands, light and dark — every variant assembled from the same Stadium components. Switch the brand and the tokens carry the rest.
That split, shared structure and themed identity, is the whole trick. It is what lets one system serve brands that don't look alike. It is also the call I cared most about getting right, where I had to decide what stayed common so the system held together, and what stayed free so the brands kept being themselves.
10 — What Changed
Faster to high fidelity, less time lost in translation.
After it shipped, the day-to-day work got faster and cleaner in ways you could see.
Designers reached high fidelity quicker, because the pieces were already there and already right. Engineers spent less time guessing what a design meant, because the system said it plainly. And with one shared set of components instead of hundreds, the patterns that used to drift apart across products stayed in line.
There was a quieter change too. Once designers were thinking in systems, they could move between products and platforms without relearning the basics each time. That freed them for the harder problems, the ones worth a designer's attention, instead of redrawing the same button.
11 — Beyond B/R
The real test came with expansion.
In April 2025, the NCAA and March Madness product design teams came under my leadership. That is when Stadium got its real test. It was time to stop being a Bleacher Report system and start becoming a WBD Sports one. New brands, new products, new people building on the same parts. The jump from one app to many could have been where the system would crack.
A feature built once can then be added to any brand or platform with no rebuild, and no second design pass. The shared system means a new capability is available everywhere.
But it held, because the earlier calls were made for exactly this. Tokens meant a new brand was a set of values, not a rebuild. Governance meant new teams had a way in instead of a reason to fork. And the split between shared structure and themed identity meant the system could carry brands as different as the NCAA and Bleacher Report without pulling them toward each other.
The bet was that the foundation would outlast the app it was built for. It did.
12 — Why It Matters
Speed was the obvious win. Culture was the bigger one.
The efficiency and the reach were the obvious wins. The bigger one was cultural.
The way the team worked across functions changed. Designers got deliberate about pattern decisions instead of making them one screen at a time. Engineering got visibility early, while choices were still cheap to change. And everyone had a shared language for the work, which simply did not exist before.
The token foundation is a quiet part of why this lasts. Because the system is built on named, structured values, it can keep taking on new platforms and new tools, AI-assisted ones included, without being torn down and rebuilt.
The reach is the headline. The part I care about is quieter. A team that shares a language it did not have before, and a way of working that holds up no matter which product someone opens next.