← Back to work

Fanatics Collectibles · 2025–2026

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
2025–2026
Status
Ongoing ·

As Design System Manager at Fanatics Collectibles, I had a specific mandate: build Easel as a product — not a component library — one system seven teams could actually rely on.

Easel now powers seven production apps from a single codebase, with IP themes driven through tokens rather than bespoke rebuilds.

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.

Missions screen · Before Easel
Same flow. Four completely different implementations.
Bunt Missions
Bunt Baseball
Oversized reward icon Full-width CTA button Progress bar inside card
Disney Missions
Disney
Smaller, denser cards 4-tab nav variant Different font hierarchy
Marvel Missions
Marvel
Accordion grouping Checkmark icon pattern Claim inline in card
Star Wars Missions
Star Wars
Card image left-aligned 3-state CTA (Claim/Skip/Craft) No section headers
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.
The insight that shaped everything
"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 we built the right abstraction layer."

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 — proposing, validating, and building 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 we set
  • A designer should be able to theme a new IP in weeks, not months
  • 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
R
Result

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 ▲

Like what you see?

Let's build something extraordinary together.

Get in touch ↗ ← Back to work