Frostbite · EA
A design system that existed in name, not in practice
The Frostbite engine powers some of EA's most iconic titles - FC, Madden, NHL - and the teams building with it are spread across studios globally. When I joined, the Frostbite Design System (FDS) existed in name, but not in practice. Components were inconsistently implemented, documentation was sparse or absent, and the gap between what lived in Figma and what shipped in production was wide enough to cause real authoring errors and production rework.
My job was to turn the FDS from a library into a product - something teams would actually adopt, trust, and build on top of.
"The question wasn't 'how do we build more components?' It was 'why aren't teams using the ones we have?'"
Workarounds are the most honest signal of where a system is failing
The core challenge wasn't a lack of components. It was a lack of confidence in the system. Designers were detaching components to work around undocumented edge cases. Engineers were making implementation decisions that drifted from design intent because specs didn't address real production constraints.
I started by auditing every component, every workaround, and every place teams had gone off-system - because workarounds are the most honest signal of where a system is failing.
Most components lacked documented edge cases and interaction states - designers had no choice but to make up their own rules.
The gap between design intent and production reality was highest in complex, stateful components - no shared language existed between design and engineering on component APIs or token semantics.
Anyone could add variants without review. The system had no contribution standards, no versioning strategy, and no adoption measurement - so drift was invisible until it became a production problem.
Real product cases first - not theoretical ideals
With a clear picture of what was broken and what mattered most, I restructured the component architecture around a philosophy of real product cases first. Every component was rebuilt to address the actual use cases teams encountered - not an ideal theoretical version.
For a component like the Textbox, that meant fully specifying all interaction states: Default, Mouse Over, On Click, Read Only, Disabled, Keyboard Focus, and Error States - across every meaningful variant (Single Line, Multiline, etc). Nothing was left for engineers to interpret.
The token architecture was designed to bridge design and engineering vocabulary - semantic naming that made sense in both Figma and code, with WCAG compliance baked into the token layer so accessibility was structural rather than a checklist item.
The part most systems get wrong
Components are the visible part of a design system. Governance is the invisible part that determines whether it actually survives contact with real teams. I established a governance framework built around four pillars:
No component variant or addition was merged into the system without going through a structured review process. Designers could propose new variants, but they were brought to design critique with engineering visibility - forcing intentionality about what actually needed to exist in the system versus what was a one-off product need.
I updated the team's design template to include a dedicated section for any proposed system additions or changes. This created a natural forcing function: if you wanted to extend the system, you had to show your work and get feedback before it became canonical.
I implemented versioning and a documentation strategy that used AI-assisted tooling to keep specs current across a large and fast-moving codebase - so documentation wasn't a manual bottleneck that fell behind the moment the system shipped.
Rather than requiring teams to look up system guidance, I embedded design system guidance into in-tool guardrails, templates, and workflows - delivering guidance in-context, inside the actual tools teams were using.
Adoption is the metric that actually matters
Adoption requires a measurement strategy, not just a launch. I worked closely with engineers to set up quality processes that captured adoption naturally - before and after system updates:
Tracked component and token usage after each system update, giving real-time visibility into adoption vs. drift across all 50+ studio repos.
Across studio codebases to identify which teams were lagging and surface the reason - usually undocumented edge cases or migration friction we could address proactively.
During implementation phases to verify that what shipped matched the spec, closing the feedback loop between system intent and production reality.
Measured outcomes
The anti-pattern I see in design systems work is over-indexing on the volume of components and under-investing in the invisible parts: how to use the system, when to evolve it, and why it matters to the teams building on top of it. The FDS succeeded not because we built more components - it succeeded because we built the right components, documented them for real production constraints, and created a governance structure that made the system a living product rather than a static library.