Embedded Files
0→1 Foundation:
Overview
Overview
When I joined 2U, the company had scaled rapidly — expanding from a startup into a multi-vertical organization serving hundreds of university Partners — but had no formal design system.
Each Partner required fully branded landing pages, ad campaigns, email campaigns, and multimedia assets. Those assets were being created across disconnected tools and siloed storage systems, with no shared infrastructure to support scale.
I co-founded and architected a white-labeled design system in Figma that enabled instant brand application across asset libraries, unified four domain teams, and supported over 300 distinct Partner organizations.
We didn’t just build components.
We built a repeatable brand engine.
Before
Before
Domain teams embedded in multiple disconnected design tools
Brand assets stored across access-limited platforms
Manual recreation of brand styles for each new Partner
Duplicate files and inconsistent brand updates
Limited oversight for accessibility and documentation standards
Rebrands required sweeping manual updates across asset types
Launching a new Partner meant rebuilding.
Executing a rebrand meant retracing that work again.
Scale multiplied friction.
After
After
Centralized Figma ecosystem supporting four domain teams
White-labeled token architecture with static naming + variable values
Library swap enabling instant brand application
Structured brand governance across web, email, ads, and multimedia
Engineering adopted the token structure and naming conventions, aligning implementation patterns with design architecture and reducing ambiguity in handoffs
60%+ reduction in required time to launch a new Partner
Rapid execution of Partner rebrands through token updates
What had been manual recreation became controlled infrastructure.
Brand updates became system updates.
Role & Scope
Role & Scope
Principal Product Designer, Design Systems
Principal Product Designer, Design Systems
When I joined the company, there was no design system in place.
In my original role as a Senior Production Artist, I routinely experienced the inefficiency of not having any centralized systems first-hand. After I identified the gap, I proposed building a design system to leadership. Along with a second design partner, we launched an initial pilot as a side initiative in Adobe XD while maintaining our primary roles. The Degree team adopted it, and we were able to demonstrate clear efficiency gains and brand consistency improvements.
As the value became evident, leadership formally reclassified us into a dedicated Design Systems team (two designers + one design manager). We then rebuilt and expanded the system in Figma to unify tooling across the organization and support long-term scale.
Scope included:
White-labeled token architecture design
Multi-library system structure in Figma
Static naming conventions enabling cross-brand swapping
Migration of four domain teams into Figma
Training, documentation, and change management
Alignment with engineering on token structure and naming conventions
Participation in DAM system selection to centralize brand assets
This was not just implementation work — it was internal product creation and organizational change leadership.
When We Started
When We Started
Design output was strong — but infrastructure was not.
Domain teams were deeply embedded in legacy workflows
Brand updates were inconsistently applied across products
Assets were duplicated across storage systems
Accessibility and documentation practices varied widely
No shared environment for cross-team visibility
Launching a new Partner required rebuilding brand styles manually
The organization was scaling its client base without scalable design infrastructure.
The risk wasn’t quality — it was compounding inefficiency.
The Structural Build
The Structural Build
The shift was moving from file organization to system architecture.
To scale hundreds of brands, we needed repeatable structure — not just templates.
Turned Brand into Infrastructure
Turned Brand into Infrastructure
We designed a layered token system that separated naming from brand values.
The structure included:
A centralized Brand Styles library (token source)
Five white-labeled asset libraries
Static style and token naming across all Partners
Figma’s native library swap to instantly apply new brand values
When a new Partner signed:
Duplicate the project
Update token values in Brand Styles
Swap libraries
Instantly apply the Partner identity across all assets
Because naming conventions remained static, brand transformation became a system action — not manual recreation.
This reduced required launch time for a new Partner by more than 60%.
While technical automation between design and code was not feasible at the time, engineering adopted our token structure and naming conventions to improve parity and simplify handoffs.
We aligned structure — even without direct sync.
Replaced Silos with Shared Tooling
Replaced Silos with Shared Tooling
Degree, Bootcamp, Executive Education, and edX each had deeply embedded workflows and preferred tools.
Migration required:
Cross-team presentations and information sessions
Hands-on training workshops
Embedded documentation
Feedback loops and iteration
Clear contribution standards
Over time, all branded landing pages, ad campaigns, email campaigns, and multimedia work moved into the shared Figma environment.
The system was adopted across:
Design
Marketing
Web development
Email development
This was infrastructure change — not just tool change.
Style Architecture
Style Architecture
Pre-variable token architecture implemented through structured Figma Styles and consistent naming conventions, enabling scalable multi-brand theming.
Additional Figma file architecture and library examples can be shared in a live walkthrough due to partner confidentiality.
Operating the System as Scalable Infrastructure
Operating the System as Scalable Infrastructure
Architecture does not sustain itself.
To support long-term durability, we embedded governance into daily workflows:
Static naming conventions for cross-brand consistency
Clear duplication and library management model
Embedded documentation within files
Alignment between token structure and engineering usage
DAM system selection to centralize asset governance
The objective was not migration.
It was repeatability at scale.
Impact
Impact
The system shifted 2U from reactive brand recreation to predictable brand scaling.
Scale
100+
PARTNER BRANDS SUPPORTED
100+
PARTNER BRANDS SUPPORTED
System used to generate and manage fully branded libraries and assets for over 100 distinct university Partners.
Adoption
4
DOMAIN TEAMS UNIFIED
4
DOMAIN TEAMS UNIFIED
Degree, Bootcamp, Executive Education, and edX fully migrated into a shared Figma ecosystem — adopted across design, marketing, web, and email development.
Velocity
60%+
FASTER PARTNER LAUNCH
60%+
FASTER PARTNER LAUNCH
Reduced required time to launch a new Partner by more than 60% through structured token-based brand application.
System Footprint
System Footprint
116
116
TOTAL TEAMS
IN FIGMA
IN FIGMA
341
341
PUBLISHED
LIBRARIES
LIBRARIES
21.K
21.K
PUBLISHED
COMPONENTS
COMPONENTS
18.8K
18.8K
MANAGED
BRAND TOKENS
BRAND TOKENS
What began as a side initiative became enterprise infrastructure.
What I'd Do Next
What I'd Do Next
With a scalable white-label foundation in place, the next evolution would focus on:
Connecting token sources between design and engineering through automation
Introducing measurable system health metrics (adoption, parity, contribution)
Expanding distributed contribution workflows with governance guardrails
Consolidating library duplication at scale
Deepening enterprise token alignment across verticals
The next step would be orchestration — not just theming.
A multi-brand organization doesn’t scale by duplicating effort — it scales by installing structure that makes change predictable.
Page updated
Google Sites
Report abuse