← Back to work

Fanatics Collectibles · 2024–2025

Building Easel:
A Scalable
Design System

Unifying seven apps under one foundation while preserving brand authenticity across every IP.

Role
Design Systems Lead
Duration
15 months
Year
2024–2025
Status
Ongoing ·

I joined Fanatics Collectibles as Design System Manager with a specific mandate: own Easel from the ground up. Not manage designers, but build the system itself as a product that designers and engineers could rely on.

Working embedded within the product design team, I was responsible for every architectural decision: the atomic structure, the token taxonomy, the Figma library, the component API, and the engineering handoff process. Easel now powers seven production apps sharing a single codebase, with themes driven through tokens rather than bespoke rebuilds per IP.

My Collaborators Product Design Manager · 2 UI Designers · 4 Frontend Engineers · 1 Content Producer per IP
S
Situation

Seven Apps. Seven Systems. Zero Shared Foundation.

When I came in, what was called a "design system" was really seven independent Figma files with overlapping components, inconsistent naming, and no token structure. Every app was its own island.

Every Change Multiplied by Seven
Updating a UI pattern meant touching seven Figma files, briefing seven engineers separately, and running QA seven times. One change cost the team weeks.
IP Theming Was Fully Manual
Shipping a new IP meant rebuilding screens from scratch. There was no shared template, no token layer, no way to swap a theme without redesigning the whole thing.
What I saw that others hadn't framed yet
"The seven apps had the same structure, the same gameplay, the same UX patterns. The only real difference was the IP skin on top. That meant one system could serve all of them, as long as I built the right abstraction layer."
missionPanel skeleton
Master skeleton
missionPanel · Disney
Disney missionPanel
Content Block Library
A single master component, missionPanel, drives every mission, quest, and trade row across all seven IPs. Engineers bind one interface; designers skin it per brand.

"Same structure, zero duplication. Swap the token set and the component transforms completely: layout, hierarchy, and behavior stay identical."

T
Task

Own the System. Define the Architecture.

My mandate wasn't to manage designers. It was to make design infrastructure a competitive advantage. I had to propose, validate, and build an architecture that engineers could implement once and designers could theme endlessly.

What we were responsible for
  • Defining the atomic architecture and token taxonomy
  • Building the entire Figma library from scratch
  • Partnering with engineering on the shared codebase
  • Establishing the global vs. local system boundary
  • Evangelizing adoption across seven product teams
The bar I set for myself
  • A designer should be able to theme a new IP in days, not weeks
  • Engineers ship one component, not six variants
  • QA runs once, not per app
  • The system grows without breaking existing products
One skeleton → seven IPs
1 / 8
A
Action

How We Architected Easel

We chose Brad Frost's Atomic Design as the methodological backbone. It gave engineers and designers a shared vocabulary and made the boundary between global and local crystal clear.

0:00
01
We Ran the Audit Before Writing a Single Component
Before opening Figma, we mapped reality: every component, every deviation, every pattern across all seven apps. We needed to know what was truly IP-specific before deciding what could be universal.
The structural question
Which components are purely layout and behavior, the kind that could be fully standardized without any IP ever noticing?
The IP-specific question
Which components are so brand-expressive that tokens alone can't carry them and need a dedicated local override?
02
We Designed the Token Taxonomy from Zero
The token structure was the most critical decision we made on this project. Get it wrong and every IP theme becomes a nightmare to maintain. We designed a three-tier system: primitive tokens at the base, semantic tokens in the middle, and component-level tokens at the surface, so IP themes only ever touch the semantic layer.
Primitive tokens: raw values, never used directly
Semantic tokens: meaning-based, IP-swappable
Spacing scale, radius, elevation, motion
Typography system with per-IP variant slots
The decision that changed everything
"We introduced the Content Block Library: reusable UI patterns built around how content actually lives in the app, not just how atomic components are named. That's what made Easel feel like a product, not a Figma file."
03
We Built the Template Layer So IPs Ship in Days
Every page type became an intentionally unstyled skeleton: layout, hierarchy, scroll behavior, zero brand. Applying a new IP means swapping the token set, not redesigning the page. We owned the spec together: design led the architecture, engineering owned the build.
Skeleton
Bunt
NBA
Disney
Marvel
Star Wars

What Easel Delivered

Seven production apps. One codebase. One Figma library. New IPs themed in days instead of weeks. This is what shipping a real design system looks like. Not a style guide, not a Storybook nobody reads.

0
IPs covered
0
Base components
0
Component variants
0
Icon variants
0
Design tokens
One fix ships to all seven apps
The shared codebase means a UI change deploys simultaneously across every IP, with no parallel implementations and no per-app QA cycles.
New IPs theme in days
The token layer means a new IP can be fully themed without touching a single layout file. Just swap the semantic token set.
Designers work from one library
The entire product design team works from a single Figma library, with no drift, no out-of-sync files, no guessing which component is current.
A shared language across disciplines
Atomic naming gave designers and engineers a common vocabulary. Handoff conversations shifted from "what did you mean?" to "which variant?" for the first time.
Switch IP Theme
Master (Default)
Bunt
Disney
Marvel
NBA
NFL
SLAM
Star Wars
Master