Case Study
Building a Scalable Design System for a Live Service Product
What happens when 10+ designers are building the same product with no shared language, no shared components, and no shared rules?
Design Systems Architecture
Cross Platform Component Design
Token Systems
Engineering Collaboration
Team Governance


500+ → ~40
components consolidated
500+ → ~40
components consolidated
2wks → <1day
build time reduction
2wks → <1day
build time reduction
~80%
screens on system components
~80%
screens on system components
10+
designers, one source
10+
designers, one source
My Role
Design Lead, sole system owner
Timeline
Multiple years, 6 releases with the system
Team
10+ designers, engineering partners
Tools
Figma, JSON tokens, proprietary engine, Maya
Scope
Console, PC, mobile
01 - The Problem
No shared language, no shared rules
When I started on NBA 2K, every screen was overloaded. Years of feature additions with no unified style, designers using whatever fonts and colors looked good to them, and similar components rebuilt from scratch dozens of times because nobody knew what already existed. The product needed a design system, and more than that, it needed someone willing to enforce it.
01 - The Problem
No shared language, no shared rules
When I started on NBA 2K, every screen was overloaded. Years of feature additions with no unified style, designers using whatever fonts and colors looked good to them, and similar components rebuilt from scratch dozens of times because nobody knew what already existed. The product needed a design system, and more than that, it needed someone willing to enforce it.
02 - The System
Constraints that forced clarity
I limited screens to three font variations. It was a tough sell on dense menus, but the constraint forced prioritization. When everything is loud, nothing is loud.
3 Font Variations
Constraint

Slice of the StyleGuide: sample showing all possible font variations
For color, I gave each product area its own accent for navigation and stripped everything else back. Panels got quieter, but on screens where navigation wasn't the main event I let them breathe. I wasn't going for minimalism, I just wanted color doing a job instead of filling space.

Before color standardization. Every screen made its own choices.
Three Tier Token Architecture
The design system uses a three tier token structure to manage visual consistency across game modes. Designers build a component once and it adapts everywhere. No duplicating work per mode, no hard coded colors breaking when things change.
Tier 1: Primitive Tokens
The raw values. Each game mode has its own highlight color. Designed in Figma and set in a JSON file.
MyCAREER
#00FFCC
MyNBA
#F2FB00
MyTEAM
#41FDFE
MyWNBA
#FF6B3B
Tier 2: Semantic Tokens
Dynamic references that resolve to the correct primitive based on context. A single token like highlight-gamemode.color automatically maps to the right color depending on which mode the user is in.
Tier 3: Component Tokens
Apply semantic tokens to specific UI elements. A settings button's selected state pulls from the semantic token, so the same component works across all modes without any manual overrides. This also works in full screen motion pieces and backgrounds.

Change a primitive, and it cascades through every component.
02 - The System
Constraints that forced clarity
I limited screens to three font variations. It was a tough sell on dense menus, but the constraint forced prioritization. When everything is loud, nothing is loud.
3 Font Variations
Constraint

Slice of the StyleGuide: sample showing all possible font variations
For color, I gave each product area its own accent for navigation and stripped everything else back. Panels got quieter, but on screens where navigation wasn't the main event I let them breathe. I wasn't going for minimalism, I just wanted color doing a job instead of filling space.

Before color standardization. Every screen made its own choices.
Three Tier Token Architecture
The design system uses a three tier token structure to manage visual consistency across game modes. Designers build a component once and it adapts everywhere. No duplicating work per mode, no hard coded colors breaking when things change.
Tier 1: Primitive Tokens
The raw values. Each game mode has its own highlight color. Designed in Figma and set in a JSON file.
MyCAREER
#00FFCC
MyNBA
#F2FB00
MyTEAM
#41FDFE
MyWNBA
#FF6B3B
Tier 2: Semantic Tokens
Dynamic references that resolve to the correct primitive based on context. A single token like highlight-gamemode.color automatically maps to the right color depending on which mode the user is in.
Tier 3: Component Tokens
Apply semantic tokens to specific UI elements. A settings button's selected state pulls from the semantic token, so the same component works across all modes without any manual overrides. This also works in full screen motion pieces and backgrounds.

Change a primitive, and it cascades through every component.
03 - Components
The ~40 building blocks
I consolidated the library from 500+ down to about 40 over multiple releases. Started with high frequency stuff like buttons and panels, then cleanup passes after each release. I built flexible components that could transform into different configurations but only needed one update when we changed the look.
Panel Component A - Generic Panel

Team Color (dynamic)
Stroke
Pattern
Bar Right
Bar Left
Bar Top
Bar Bottom
Inner Shadow Bottom
Inner Shadow Top

Team Colored
Stroke
Pattern
Bar Right
Bar Left
Bar Top
Bar Bottom
Inner Shadow Bottom
Inner Shadow Top
Panel Component B - Decorative Panel

Game Mode (dynamic)
Stroke
Pattern
Bar Right
Bar Left
Bar Top
Bar Bottom
Inner Shadow Bottom
Inner Shadow Top

Game Mode (dynamic)
Stroke
Pattern
Bar Right
Bar Left
Bar Top
Bar Bottom
Inner Shadow Bottom
Inner Shadow Top
Panel System
Primary and secondary containers with configurable shadows, strokes, pattern textures, and team color overlays.
Foundation
MyTEAM Trading Cards
A layered card system where producers and artists could swap images, textures, and effects to build their own trading cards. Designed to feel premium, like you could pull them out of the screen and touch them. Made the pack market more attractive and drove engagement with card collecting.
Composite

Navigation Tabs
Two state component. Solid fill for selected, transparent for deselected. Combined with controller prompts, users cycle views with a single input.
Atom

One component, multiple configurations through exposed properties
03 - Components
The ~40 building blocks
I consolidated the library from 500+ down to about 40 over multiple releases. Started with high frequency stuff like buttons and panels, then cleanup passes after each release. I built flexible components that could transform into different configurations but only needed one update when we changed the look.
Panel Component A - Generic Panel

Team Color (dynamic)
Stroke
Pattern
Bar Right
Bar Left
Bar Top
Bar Bottom
Inner Shadow Bottom
Inner Shadow Top

Team Colored
Stroke
Pattern
Bar Right
Bar Left
Bar Top
Bar Bottom
Inner Shadow Bottom
Inner Shadow Top
Panel Component B - Decorative Panel

Game Mode (dynamic)
Stroke
Pattern
Bar Right
Bar Left
Bar Top
Bar Bottom
Inner Shadow Bottom
Inner Shadow Top

Game Mode (dynamic)
Stroke
Pattern
Bar Right
Bar Left
Bar Top
Bar Bottom
Inner Shadow Bottom
Inner Shadow Top
Panel System
Primary and secondary containers with configurable shadows, strokes, pattern textures, and team color overlays.
Foundation
MyTEAM Trading Cards
A layered card system where producers and artists could swap images, textures, and effects to build their own trading cards. Designed to feel premium, like you could pull them out of the screen and touch them. Made the pack market more attractive and drove engagement with card collecting.
Composite

Navigation Tabs
Two state component. Solid fill for selected, transparent for deselected. Combined with controller prompts, users cycle views with a single input.
Atom

One component, multiple configurations through exposed properties
04 - States
Every element declares its state
I designed how components moved and responded to input, not just how they looked. The accent color changes per game mode, but the rules stay consistent. When a button triggers an action or navigates to another screen, it highlights in the mode's accent color. When something is just selected or toggled, like a tab or a menu option, it highlights in white. That separation made the UI readable across every mode without anyone having to think about which color to use where.
Beyond color, components carried animation and effects as part of their design. Transitions, particle layers, and motion behaviors were built into the components themselves so the system didn't just look consistent, it felt consistent in motion.




04 - States
Every element declares its state
I designed how components moved and responded to input, not just how they looked. The accent color changes per game mode, but the rules stay consistent. When a button triggers an action or navigates to another screen, it highlights in the mode's accent color. When something is just selected or toggled, like a tab or a menu option, it highlights in white. That separation made the UI readable across every mode without anyone having to think about which color to use where.
Beyond color, components carried animation and effects as part of their design. Transitions, particle layers, and motion behaviors were built into the components themselves so the system didn't just look consistent, it felt consistent in motion.




05 - Theming
One system, many identities
Panels swapped textures per game mode. Text color shifted based on the active theme. The background itself was a big component that changed shape, color, and texture depending on the mode and what that year's visual direction called for. Seasonal content plugged into the same token setup so limited time events could go out without custom builds.
MyCAREER
Teal accent, urban textures, player focused panels. Background shifts to match your neighborhood and season.
PLAYNOW
Yellow accent, clean data heavy layouts. Same panels and components, different personality through tokens.
MyTEAM
Blue accent, card collection aesthetic. The system adapts to a marketplace context while staying on the same component set.
MyWNBA
Orange accent, WNBA focused. Bringing it into the system meant adding its color tokens and textures. The architecture handled the rest.
MyCAREER


MyWNBA


05 - Theming
One system, many identities
Panels swapped textures per game mode. Text color shifted based on the active theme. The background itself was a big component that changed shape, color, and texture depending on the mode and what that year's visual direction called for. Seasonal content plugged into the same token setup so limited time events could go out without custom builds.
MyCAREER
Teal accent, urban textures, player focused panels. Background shifts to match your neighborhood and season.
PLAYNOW
Yellow accent, clean data heavy layouts. Same panels and components, different personality through tokens.
MyTEAM
Blue accent, card collection aesthetic. The system adapts to a marketplace context while staying on the same component set.
MyWNBA
Orange accent, WNBA focused. Bringing it into the system meant adding its color tokens and textures. The architecture handled the rest.
MyCAREER


MyWNBA


06 Architecture
Layered for speed
When we redesigned the Roster Creator for 2K26, the team built it almost entirely from existing components. The player cards, the panel system, tabs, controller prompts, OVR meters, all existed in the library. Only the layout and the filter dropdown were new. What would have taken weeks took days.


Built entirely with one single panel component by adjusting its properties.
06 Architecture
Layered for speed
When we redesigned the Roster Creator for 2K26, the team built it almost entirely from existing components. The player cards, the panel system, tabs, controller prompts, OVR meters, all existed in the library. Only the layout and the filter dropdown were new. What would have taken weeks took days.


Built entirely with one single panel component by adjusting its properties.
07 - Shipping it
From Figma to engine
Working in Code
I edited color values and token definitions directly in code and maintained the config files that controlled how the system showed up across the product. For animation sequencing, camera assignments, and menu organization I worked inside the codebase myself rather than writing specs and hoping someone interpreted them correctly.
New component types usually required engine features that didn't exist yet, so we ran focused kickoffs where I defined the behavior, engineering built the capability, and then I implemented the component on my end. Early on I sat down with engineers to agree on naming conventions so the design system vocabulary matched what was already in code, which cut down on translation errors and made adoption faster. When I needed something more complex, like formula driven animation controls for meter fills, engineering would open up those systems and I'd wire them into the components directly.
AI Auditing at Scale
The component library had years of debt and auditing 500+ assets manually wasn't realistic. So I used AI to write a script that scanned the codebase for every instance of our legacy panel components, surfaced which screens used them, and logged the properties each one had set. Full picture, one pass.
One example: the system had over 20 variations of the same panel, each built slightly differently for different contexts. The script showed me the different values set in those components and I was able to determine that they could be condensed into three core panel types, a global panel, a decorative panel, and an effects panel, each with configurable properties to handle the variation.
Without AI I could have found the duplicates eventually, but seeing every property across every screen at once is what gave me the confidence to cut aggressively.
Find and Replace, System Wide
I worked with engineering to write a second script that translated legacy properties onto the new components and swapped them across the codebase automatically. No one had to go screen by screen. This was my initiative, and combined with the auditing work it meant migrations that could have taken months happened in focused sprints instead.
Governance
I owned core primitives and tokens but trusted contributors could extend within guidelines.
1. Can it Adapt?
Could an existing component evolve instead of creating a new one?
2. Will It Recur?
Is this pattern reusable across multiple screens?
3. If No to Both → Push Back
Protect the system. Redirect energy toward features that truly require custom work.
Leadership alignment made that discipline sustainable and kept the system from drifting. I also started rolling out accessibility improvements, better contrast on selectable items and removing pure black and white body text. Early stage, more to do there.
07 - Shipping it
From Figma to engine
Working in Code
I edited color values and token definitions directly in code and maintained the config files that controlled how the system showed up across the product. For animation sequencing, camera assignments, and menu organization I worked inside the codebase myself rather than writing specs and hoping someone interpreted them correctly.
New component types usually required engine features that didn't exist yet, so we ran focused kickoffs where I defined the behavior, engineering built the capability, and then I implemented the component on my end. Early on I sat down with engineers to agree on naming conventions so the design system vocabulary matched what was already in code, which cut down on translation errors and made adoption faster. When I needed something more complex, like formula driven animation controls for meter fills, engineering would open up those systems and I'd wire them into the components directly.
AI Auditing at Scale
The component library had years of debt and auditing 500+ assets manually wasn't realistic. So I used AI to write a script that scanned the codebase for every instance of our legacy panel components, surfaced which screens used them, and logged the properties each one had set. Full picture, one pass.
One example: the system had over 20 variations of the same panel, each built slightly differently for different contexts. The script showed me the different values set in those components and I was able to determine that they could be condensed into three core panel types, a global panel, a decorative panel, and an effects panel, each with configurable properties to handle the variation.
Without AI I could have found the duplicates eventually, but seeing every property across every screen at once is what gave me the confidence to cut aggressively.
Find and Replace, System Wide
I worked with engineering to write a second script that translated legacy properties onto the new components and swapped them across the codebase automatically. No one had to go screen by screen. This was my initiative, and combined with the auditing work it meant migrations that could have taken months happened in focused sprints instead.
Governance
I owned core primitives and tokens but trusted contributors could extend within guidelines.
1. Can it Adapt?
Could an existing component evolve instead of creating a new one?
2. Will It Recur?
Is this pattern reusable across multiple screens?
3. If No to Both → Push Back
Protect the system. Redirect energy toward features that truly require custom work.
Leadership alignment made that discipline sustainable and kept the system from drifting. I also started rolling out accessibility improvements, better contrast on selectable items and removing pure black and white body text. Early stage, more to do there.
What it did for the team
08 - Impact
Before the System
Build artists didn't have a shared reference point. If someone needed a panel they'd look at a nearby screen, find something close, and copy it. If it wasn't quite right they'd make a new one. Colors were picked manually by eyeballing a concept, not attached to any token, so if something needed to change later someone had to update every screen individually. A lot of time went to rebuilding things that already existed and guessing at design decisions that should have been defined.
After
Builders could ship screens without formal concepts. They'd pull from the component library, snap pieces together, and the result stayed consistent because the rules were built into the components themselves. Build time went from roughly two weeks to under a day. During crunch the system held up because the governance was clear: if a component didn't do what you needed, you requested an extension rather than building around it.
Before the system / early days

After implementation

Same product. Before: competing treatments. After: shared language, room for expression.
What I'd Do Differently
Documentation was the gap. The style guide lived in Figma and in engine, but usage docs were buried in a separate tool. New build artists got confused on complex screens because instructions were hard to find. I'd build a unified doc layer earlier, something right next to the components instead of somewhere else.
I was also the sole maintainer. I'd started handing ownership to other leads but needed more time to get that running properly.
Starting Fresh Today
If I were starting a system today I'd feed the existing component inventory through an LLM on day one to get a draft architecture going, then iterate from there instead of building from scratch. Documentation would live alongside the components from the start. I'd use AI for the granular stuff that otherwise eats weeks: cataloging variants, flagging inconsistencies, drafting usage guidelines. I'd also want it to be as plug and play as possible, maybe a dashboard where the team can adjust tokens and see changes cascade in real time, something I could vibe code into a working prototype pretty quickly.
What it did for the team
08 - Impact
Before the System
Build artists didn't have a shared reference point. If someone needed a panel they'd look at a nearby screen, find something close, and copy it. If it wasn't quite right they'd make a new one. Colors were picked manually by eyeballing a concept, not attached to any token, so if something needed to change later someone had to update every screen individually. A lot of time went to rebuilding things that already existed and guessing at design decisions that should have been defined.
After
Builders could ship screens without formal concepts. They'd pull from the component library, snap pieces together, and the result stayed consistent because the rules were built into the components themselves. Build time went from roughly two weeks to under a day. During crunch the system held up because the governance was clear: if a component didn't do what you needed, you requested an extension rather than building around it.
Before the system / early days

After implementation

Same product. Before: competing treatments. After: shared language, room for expression.
What I'd Do Differently
Documentation was the gap. The style guide lived in Figma and in engine, but usage docs were buried in a separate tool. New build artists got confused on complex screens because instructions were hard to find. I'd build a unified doc layer earlier, something right next to the components instead of somewhere else.
I was also the sole maintainer. I'd started handing ownership to other leads but needed more time to get that running properly.
Starting Fresh Today
If I were starting a system today I'd feed the existing component inventory through an LLM on day one to get a draft architecture going, then iterate from there instead of building from scratch. Documentation would live alongside the components from the start. I'd use AI for the granular stuff that otherwise eats weeks: cataloging variants, flagging inconsistencies, drafting usage guidelines. I'd also want it to be as plug and play as possible, maybe a dashboard where the team can adjust tokens and see changes cascade in real time, something I could vibe code into a working prototype pretty quickly.
What it did for the team
08 - Impact
Before the System
Build artists didn't have a shared reference point. If someone needed a panel they'd look at a nearby screen, find something close, and copy it. If it wasn't quite right they'd make a new one. Colors were picked manually by eyeballing a concept, not attached to any token, so if something needed to change later someone had to update every screen individually. A lot of time went to rebuilding things that already existed and guessing at design decisions that should have been defined.
After
Builders could ship screens without formal concepts. They'd pull from the component library, snap pieces together, and the result stayed consistent because the rules were built into the components themselves. Build time went from roughly two weeks to under a day. During crunch the system held up because the governance was clear: if a component didn't do what you needed, you requested an extension rather than building around it.
Before the system / early days

After implementation

Same product. Before: competing treatments. After: shared language, room for expression.
What I'd Do Differently
Documentation was the gap. The style guide lived in Figma and in engine, but usage docs were buried in a separate tool. New build artists got confused on complex screens because instructions were hard to find. I'd build a unified doc layer earlier, something right next to the components instead of somewhere else.
I was also the sole maintainer. I'd started handing ownership to other leads but needed more time to get that running properly.
Starting Fresh Today
If I were starting a system today I'd feed the existing component inventory through an LLM on day one to get a draft architecture going, then iterate from there instead of building from scratch. Documentation would live alongside the components from the start. I'd use AI for the granular stuff that otherwise eats weeks: cataloging variants, flagging inconsistencies, drafting usage guidelines. I'd also want it to be as plug and play as possible, maybe a dashboard where the team can adjust tokens and see changes cascade in real time, something I could vibe code into a working prototype pretty quickly.
© 2026 by Albert Carmona
© 2026 by Albert Carmona
© 2026 by Albert Carmona












