Building a Scalable Design System for a Live Service Product
Case Study
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 annual releases
Team
10+ designers, engineering partners
Tools
Figma, JSON tokens, proprietary engine, Maya
Scope
Console, PC, mobile
The Problem
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.
The Problem
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.
The System
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.
The System
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.
Tier 1: Primitive Tokens are the raw values. Each game mode has its own highlight color (Teal for MyCAREER, Coral for MyTEAM, Orange for TheW, Yellow for MyNBA).
Tier 2: Semantic Tokens are 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 means designers build a component once and it adapts everywhere. No duplicating work per mode, no hard coded colors breaking when things change.
“Change a primitive, and it cascades through every component.”
For components, 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 shapes but only needed one update when we changed the look, and a reference guide inside the engine so designers and engineers could actually find them.
Component with variations
I designed how components moved and responded to input, not just how they looked.
Three-Tier Token Architecture
The design system uses a three-tier token structure to manage visual consistency across game modes.
Tier 1: Primitive Tokens are the raw values. Each game mode has its own highlight color (Teal for MyCAREER, Coral for MyTEAM, Orange for TheW, Yellow for MyNBA).
Tier 2: Semantic Tokens are 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 means designers build a component once and it adapts everywhere. No duplicating work per mode, no hard coded colors breaking when things change.
“Change a primitive, and it cascades through every component.”
For components, 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 shapes but only needed one update when we changed the look, and a reference guide inside the engine so designers and engineers could actually find them.
Component with variations
I designed how components moved and responded to input, not just how they looked.
Shipping it
I edited color primitives directly in code, but new component types required engine features that didn't yet exist. We ran focused kickoffs: I defined the behavior, engineering built the capability, then I implemented the component. We later built tools to locate and replace legacy components across the codebase without manual hunting.
For 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.
Shipping it
I edited color primitives directly in code, but new component types required engine features that didn't yet exist. We ran focused kickoffs: I defined the behavior, engineering built the capability, then I implemented the component. We later built tools to locate and replace legacy components across the codebase without manual hunting.
For 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.
Impact
Build time went from two weeks to under one day. Build artists could ship screens without formal concepts just by using the asset guide. The product refreshed yearly and the team spent more time on expressive features instead of rebuilding basics.
Same product. Before: competing treatments. After: shared language, room for expression.
Impact
Build time went from two weeks to under one day. Build artists could ship screens without formal concepts just by using the asset guide. The product refreshed yearly and the team spent more time on expressive features instead of rebuilding basics.
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 alongside the components instead of somewhere else.
I was also the sole maintainer. I'd started distributing ownership to other leads but needed more time to get that running properly.
If I were starting this system today I'd build the documentation layer from day one and distribute ownership across leads before the system got big enough to depend on one person. The system itself proved out the approach, the operational side is what I'd rebuild.
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 alongside the components instead of somewhere else.
I was also the sole maintainer. I'd started distributing ownership to other leads but needed more time to get that running properly.
If I were starting this system today I'd build the documentation layer from day one and distribute ownership across leads before the system got big enough to depend on one person. The system itself proved out the approach, the operational side is what I'd rebuild.
© 2026 by Albert Carmona
© 2026 by Albert Carmona
© 2026 by Albert Carmona