Deep Dive
Back to Work

Design System That Scaled From 8K to 17K+ Publishers

Building a token-based design system that eliminated the "game of telephone" between design and engineering.

Design SystemsTokensComponentsAccessibility
RoleProduct Designer
TimelineOct 2020 to 2025
LaunchMay 2021
Team3 Designers, ~10-15 Engineers, 3 PMs
100%
Team Adoption

Full adoption across design and engineering within the first month of launch. No one reverted to old patterns.

hover to clink
~$50K+
Est. Annual Savings

Estimated $50K+ in annual cost savings from reduced rework, faster handoff, and eliminated redundant design decisions.

54%
Efficiency Gain

Measured 54.18% improvement in design-to-dev workflow efficiency. Designers spent less time on specs, engineers spent less time interpreting intent.

AA
WCAG Compliance

Every component meets WCAG AA accessibility standards. Changed the brand color from #59C8E5 to #0097B2 to achieve compliant contrast ratios.

We needed a single source of truth that was always up-to-date, matched engineering's code, and could scale with the business as it grew from 8,000 to 17,000+ Publishers.

The Challenge

Three products with diverging UI patterns and no shared source of truth, costing the team an estimated $20-25K per year in rework and miscommunication.

When I joined Mediavine, design and engineering were playing a "game of telephone." Designers handed off static mockups, engineers interpreted them differently, and the final product rarely matched the original intent. There was no design system, no shared component library, and no token architecture. Each of the three products (Dashboard, Trellis, Create) had its own visual language. The same button could look three different ways depending on which product you were in. Every new feature meant rebuilding from scratch, and every handoff introduced drift.

What Publishers Struggled With
01

No Shared Source of Truth

Design and engineering had no common reference point. Designers created mockups in one tool, engineers built in another, and the gap between intent and implementation grew with every sprint.

02

Three Products, Three Visual Languages

Dashboard, Trellis, and Create each evolved independently. The same UI patterns looked and behaved differently across products, confusing publishers who used all three.

03

$20-25K Annual Rework Cost

Without standardized components, every feature required custom builds. Engineering spent significant time interpreting design intent rather than building functionality.

04

Accessibility Gaps

The existing brand color (#59C8E5) failed WCAG AA contrast requirements. Without systematic accessibility checks, compliance was inconsistent and often missed entirely.

Design Approach

I chose alignment over perfection. Using Material UI meant engineers could map design components to code 1:1, reducing learning curve and enable immediate adoption.

The approach prioritized alignment over invention. Rather than building a custom system from scratch, I anchored the design system to Material UI (the framework engineering already used) and layered semantic meaning on top through a two-tier token architecture.

Align with engineering reality

Engineering was already using Material UI. Rather than fighting that or building a competing system, I made Material UI the foundation and customized on top of it. This meant zero migration cost and immediate buy-in.

Tokens over hard-coded values

Every color, spacing, and typography value flows through a two-tier token system: primitive tokens (raw values) and semantic tokens (contextual meaning). This enables theming, dark mode, and product-tier differentiation without touching components.

Accessibility as a foundation, not an afterthought

I changed the brand color to achieve WCAG AA compliance before building a single component. Accessibility was baked into the token layer so every component inherits it automatically.

The Solution

What we built.

The design system was built in layers: tokens first, then components, then documentation. Each layer reinforced the others.

01

Two-Tier Token Architecture

Primitive + Semantic

The foundation is approximately 150 design variables organized into two tiers. Primitive tokens are the raw palette: colors, spacing scales, type sizes. Semantic tokens map those primitives to meaning: "primary action," "surface background," "error state." Components reference semantic tokens, never primitives directly. This means you can swap an entire theme by remapping semantics without touching a single component.

Primitives
blue-500
gray-100
space-16
font-14
Semantics
color.primary
color.surface
spacing.md
text.body
Button
References semantic tokens only
1
~150 design variables
2
Primitives: raw values
3
Semantics: contextual meaning
4
Swap themes without touching components
02

Material UI Alignment

Strategic foundation

Rather than building custom components from scratch, I customized 40-50 Material UI components with our token system. Engineers could use familiar APIs while designers maintained visual control. This eliminated the translation gap: what designers built in Figma mapped directly to what engineers had in code.

Figma
Submit
variantcontained
colorprimary
sizelarge
1:1
Code
<Button
  variant="contained"
  color="primary"
  size="large"
>
  Submit
</Button>
1
Designers build in Figma
2
Engineers build in MUI
3
Same props, same names
4
Zero translation gap
03

Brand Color Evolution

Accessibility-first decision

The original brand color (#59C8E5) failed WCAG AA contrast requirements. I proposed and implemented a shift to #0097B2, which achieved AA compliance while preserving brand recognition. This was a foundational decision that every component inherited automatically through the token system.

Before
#59C8E50.0:1✕ Fail
Button
After
#0097B20.0:1✓ AA Pass
Button
1
Original brand color
2
WCAG AA compliant replacement
3
Preserved brand recognition
4
Every component inherits compliance
04

Multi-Product Theming

Three products, one system

The token architecture enabled product-tier theming: Dashboard, Trellis, and Create each got distinct visual identity while sharing the same component library. Semantic tokens controlled the differentiation. A button component is built once but looks contextually appropriate in each product.

Component Blueprint
Action
Action
Product 1
Action
Product 2
Action
Product 3
1
One component library
2
Semantic tokens control identity
3
Distinct look per product
4
Consistent behavior everywhere
05

Dark Mode and Figma Variables

System evolution

As the system matured, I added dark mode support through token remapping (no component changes needed) and migrated the entire token system to Figma Variables when the feature launched. This kept the design system aligned with modern tooling and enabled real-time theme previewing in Figma.

Settings
Dark mode
Save changes
surface
text
subtle
primary
border
0 component changes
1
Token remapping, not redesign
2
Same components, different palette
3
Migrated to Figma Variables
4
Real-time theme preview in Figma
Impact & Outcomes

The receipts.

Impact was measured through adoption tracking, time studies comparing pre and post design system workflows, cost analysis, and qualitative feedback from designers and engineers.

100%
Team Adoption

Full adoption across design and engineering within the first month. No custom one-off components have been built outside the system since launch.

54.18%
Efficiency Gain

Measured improvement in design-to-development workflow efficiency. Designers spend less time on specs, engineers spend less time interpreting intent, and handoff is predictable.

~$50K+
Est. Annual Savings

Estimated annual cost savings from reduced rework, faster handoff, and eliminated redundant design decisions across all three products.

8K to 17K+
Publisher Scale

The design system supported Mediavine's growth from 8,000 to over 17,000 publishers without requiring proportional design or engineering headcount increases.

AA
WCAG Compliance

Every component in the system meets WCAG AA accessibility standards. The brand color change alone impacted every interactive element across all three products.

~150
Design Variables

Approximately 150 design variables organized into primitive and semantic tiers, powering consistent theming across three products, dark mode, and accessibility compliance.

What Surprised Me

Engineering Buy-In Was Immediate

Because the system aligned with Material UI (what engineering already used), there was zero resistance. Engineers saw immediate value: less interpretation, cleaner handoff, and familiar APIs. The alignment strategy eliminated what is usually the hardest part of design system adoption.

Token Architecture Enabled Unplanned Features

The two-tier token system was built for consistency, but it unexpectedly enabled dark mode and product-tier theming with minimal effort. Because components referenced semantic tokens (not hard-coded values), adding a new theme was a token remapping exercise, not a component rebuild.

The Brand Color Change Built Trust

Proposing a brand color change could have been contentious, but presenting it as an accessibility requirement with visual proof that brand recognition was preserved actually built trust with stakeholders. It demonstrated that the design system team was thinking beyond aesthetics.

Design Iterations

How it evolved.

01

Component Library Expansion

Grew from an initial set of core components to 40-50 customized Material UI components covering all common UI patterns across the three products.

Initial Set
Component Library6 components
Available
Button
Text Field
Select
Checkbox
Card
Dialog
Not yet built
Table
Tabs
Accordion
Chip
Tooltip
Snackbar
Drawer
Menu
Breadcrumb
Pagination
Stepper
Badge
Avatar
Divider
Switch
Radio
Slider
Progress
Full Library
Component Library41 components
Inputs
Button
IconButton
FAB
Toggle
Text Field
Select
Checkbox
Radio
Switch
Slider
Autocomplete
Date Picker
Data Display
Table
Data Grid
List
Card
Chip
Badge
Avatar
Tooltip
Typography
Navigation
Tabs
Breadcrumb
Drawer
Menu
Pagination
Stepper
Link
Bottom Nav
Feedback
Dialog
Snackbar
Alert
Progress
Skeleton
Backdrop
Layout
Accordion
Divider
Grid
Stack
Container
Paper
02

Documentation and Onboarding

Created comprehensive documentation covering token usage, component guidelines, and accessibility requirements. New team members could onboard to the system independently without requiring guided walkthroughs.

Before: Tribal Knowledge
💬How things worked before
Engineer AWhich blue do we use for primary buttons? I found 3 different hex values
Designer BIt's #0097B2... wait, maybe #59C8E5 for the old pages?
Engineer CWhere do I find the spacing specs? Can someone screen-share?
Ask Sarah for token values
Button: 8px 16px padding (I think?)
Check Figma v3... or v5?
~2 weeks to onboard
After: Structured Docs
Docs
Getting Started
Tokens
Colors
Spacing
Components
Button
TextField
Select
Card
Table
Accessibility
Changelog
Button
Buttons allow users to take actions with a single tap.
Contained
Outlined
Text
Usage
import { Button } from '@mediavine/ui';<Button variant="contained" color="primary">
Props
PropTypeDefault
variantstringcontained
colorstringprimary
sizesm | md | lgmd
disabledbooleanfalse
Self-serve onboarding
Feedback

What they said.

A
Director, Stakeholder

KARLYN this is so great. Make sure we save that video demo somewhere. Its a great walkthrough

M
Product Designer, Stakeholder

already won me over. That presentation was awesome!! I think its safe to say you blew all of us away

Z
Product Designer, Stakeholder

Copy/pasting from old designs can turn into a xerox of a xerox of a xerox. This is soooo much better

Y
Product Designer, Stakeholder

I still can't get over how amazing that design system library presentation was!

N
Product Designer, Stakeholder

OOOOOO Noooiiiice!!

Key Learnings

What I took away.

Adoption beats sophistication

A simpler system that the team actually uses is worth more than a complex system that sits unused. Every architectural decision was filtered through "will this make adoption easier or harder?"

Align with engineering, do not compete

Building on Material UI (what engineering already used) eliminated migration friction entirely. The best design system is the one that fits into existing workflows rather than requiring new ones.

Tokens are the real product

Components get the attention, but tokens are what make a design system actually scalable. The two-tier architecture (primitive + semantic) enabled dark mode, product theming, and accessibility compliance without touching a single component.

Accessibility is a foundation, not a feature

Changing the brand color before building components meant every element inherited WCAG AA compliance automatically. Baking accessibility into the token layer is orders of magnitude more effective than auditing components after the fact.

Design systems scale people, not just pixels

The system supported growth from 8K to 17K+ publishers without proportional team growth. The real value was not visual consistency; it was operational efficiency that let a small team punch above its weight.

This design system was never about building the most impressive component library. It was about eliminating the gap between what designers intended and what engineers shipped. By anchoring to engineering reality, building on tokens instead of hard-coded values, and prioritizing adoption over perfection, the system became invisible infrastructure: the team stopped thinking about it because it just worked. That is the highest compliment a design system can receive.

Let's Connect

Interested in working together?

Book a 15-minute chat and let's talk about your next project.