Built for where we were going, not where we were
Newton Design System
How we replaced fragmented product libraries with one accessible, token-driven system shipping across teams
Team
2 Designer • 2 Engineers
Timeline
2 Years
My Role
Lead Designer • Product Owner
Overview
We didn't just wanted to create better components. We embarked on the journey to create a shared foundation that could bring teams, products, and experiences back into alignment.
“Here’s the simple truth: you can’t innovate on products without first innovating the way you build them"
―Alex Schleifer, Airbnb
My Role
As Product Owner and Lead Designer, I was responsible for defining the strategy, securing alignment, and driving adoption across the organization.
Strategy & Vision
Defined the system's direction, priorities, and roadmap to balance product velocity with long-term scalability.
Audit & Discovery
Led a cross-functional audit to identify gaps, opportunities, and alignment needs.
Stakeholder Alignment
Aligned leadership around the system's vision, value, and long-term investment.
Governance & Adoption
Established the governance model and adoption strategy for sustainable scale.
What was wrong?
As products evolved independently, local decisions gradually created friction across design, development, and customer experiences. The challenge wasn't individual execution, it was the absence of a shared foundation that could scale across teams.
Why anyone should care?
The same root problem surfaced differently depending on where you sat in the organization.
Designers
The same component recreated across teams. Each slightly different, none reusable. Visual inconsistencies slowed every sprint and blocked creative work.
We’re solving the same problem multiple times
Developers
No shared library meant engineers hardcoded values, rebuilt components from scratch, and maintained multiple codebases causing bugs and delayed releases.
Teams were protective of their existing work; tight deadlines meant nobody wanted to "waste time" on design system adoption
Stakeholders
Products didn't feel connected to each other or the brand. One company, dozens of visual identities resulting in broken user experience, trust and loyalty.
Resource Audit
Before jumping straight into defining, I wanted to understand how products were being designed and built across teams. The audit quickly revealed that consistency wasn't the challenge — coordination was.
Three weeks auditing products and codebase all eight teams revealed that teams were often solving the same problems in different ways, resulting in thousands of design assets spread across multiple libraries. While each decision addressed a local need, the absence of a shared foundation had introduced duplication, reduced reusability, and increased complexity for both design and engineering.
8
Teams audited over 3 weeks
12+
Products with duplicate patterns
1,000s
Assets spread across libraries
Pattern
A
B
C
D
E
F
G
H
i
Button
Modal
Inputs
Shared implementation
Modified implementation
Unique implementation
Building with Clear Objective
Before writing a single token, we defined a north star
Create consistency across products
Establish one shared design language that connects experiences across teams and platforms.
Move faster, reduce duplication
Reduce duplication and enable teams to focus on solving user problems, not rebuilding foundations.
Single source of truth
Design and engineering aligned on shared patterns and standards.
Scale without complexity
Create a system teams could seamlessly integrate into existing and future products without adding overhead.
Building Early Support
An audit can uncover inconsistencies, but it doesn't tell you whether people are ready for change.
1
Map the people behind the decision
2
Turn concerns into shared language
3
Create a decision-ready path forward
The final plan was lightweight rollout narrative addressing points which gave leaders enough clarity to support the next phase without slowing the team down.
Reality Check and How it Changed Everything
The audit surfaced something bigger than inconsistent components. The more we zoomed in, the clearer it became that inconsistency was a symptom of a broader coordination challenge emerging across teams, products, and technologies.
Cost of Inconsistency
Independent product evolution resulted in fragmented experiences, duplicated effort, and growing maintenance costs.
Operational Inefficiencies
Teams were repeatedly solving the same problems, often recreating patterns that already existed elsewhere in the ecosystem.
Technical Debt
Multiple frameworks and implementation approaches increased maintenance complexity and slowed future enhancements.
Adoption Risks
Success depended not just on building the system, but on helping teams adopt it without disrupting existing delivery commitments.
Where Design Met Engineering
Scaling a product organization reveals a familiar tension: teams optimize locally, and over time those local decisions compound into a broken experience. Some products were built on Bootstrap, others on MUI, newer ones on Tailwind. Each choice was rational in context. Together, they made consistency expensive to maintain and even more expensive to scale.
Foundation
That foundation was built on three things: reusable components, common patterns, and design tokens. The architecture separated concerns clearly — primitives at the base, semantic decisions in the middle, and components at the surface.
Color System
Primary brand palette included 6 shades which was extended into a product palette, all of it WCAG 2.0 compatible
BRAND PALETTE
Gartner
Blue
Cobalt
Opal
Moon
Crystal
EXTENDED INTO
NEUTRAL SCALE
SEMANTIC STATES
Success
Warning
Error
Info
Grid
Majority of our products are web based and demand responsiveness. We decided to go ahead with the industry standard 12 columns grid.
8 cols
3
3
3
3
Token Architecture
This separation meant design decisions could change at the primitive level and propagate everywhere — without touching a single component.
01
Primitive
Raw Value
02
Semantic
Intent Alias
Used in
03
Component
By Name
Outputs
04
CSS Value
Final Output
PRIMITIVE
Cobalt
#006AC7
GartnerBlue
#002869
White
#FFFFFF
Neutral400
#DDDDE3
SEMANTIC
Button/Primary/Default
→ Cobalt
Button/Primary/Hover
→ GartnerBlue
Button/Primary/Disabled
→ Neutral/400
Text/white
all text
COMPONENT
Default
Hover
Disabled
Automated Pipeline
To make design decisions reliable at scale, we built an automated pipeline connecting Figma, GitHub, and Style Dictionary. Design decisions made in Figma flowed directly into code, eliminating manual translation and ensuring a single source of truth across design and engineering.
As design, engineering, and leadership aligned on the approach, the conversation shifted from what to build to how to successfully roll it out across the organization.
01 : export
Figma
Design tokens defined as Figma Variables
Tokens.json
02: trigger
GitHub
JSON Token files, version controlled
git push main
03: build
Style Dictionary
Tokens transformed into platform outputs
style-dictionary build
04: verify
Storybook
Components render live against real tokens
npm run storybook
05: publish
Products
Design System Package consumed by teams
npm install newton
Designing for Adoption
Building the system was only half the challenge. The bigger question was how to introduce it across all products without disrupting delivery.
Through conversations with product, engineering, and design teams, we identified three primary risks:
Roadmap Impact
Disrupting active product roadmaps.
Delivery Slowdown
Slowing delivery teams during migration.
Fragmented Adoption
Creating fragmented adoption across products.
Recognizing that successful adoption depended on organizational alignment, we evaluated multiple rollout strategies and selected a small set of pilot products to validate the approach.
Teams build ownership. Incremental wins build momentum.
Slower progress. Inconsistency during transition period
The goal was never 100% adoption overnight.
It was creating a path teams could realistically follow.
New Products
Default, not optional
New products adopt the system from day one. No migration to plan. Just the standard starting point.
Existing Products
Migrate on your terms
Teams move when their roadmap allows — readiness and capacity decide the pace, not a deadline.
Governance
Built to outlast any one team
A contribution model keeps the system evolving as more teams build on it, without a central bottleneck.
The success of the system wasn't measured by the number of components we created. It was measured by whether it changed how teams work.
17.5K+
Peak Weekly Usage
86K+
Component Inserts
0.18%
Component Detach Rate
Adoption
As more product teams migrated to Newton, component usage increased steadily across the year. Weekly insertions peaked at 17.5K+, providing a measurable signal that the shared library had become part of everyday design work.
Design and code, in sync
Handoff used to require 2–3 clarification rounds per feature. With shared tokens and components, that dropped to less than one.
ONE SOURCE OF TRUTH
“Button/Primary”: {
“$value”: “{Primary.Cobalt}“,
“$type”: “color”
}
renders to
Design
</> Code
Primary
background:
var(--button-primary);
Phased Rollout
Rather than migrating every product simultaneously, we prioritized teams based on readiness and engineering alignment. Each rollout phase incorporated feedback from the previous one, reducing migration risk while improving components, and implementation guidance.
The design system became the operating layer for how the organization builds product — not a library teams pull from occasionally, but the shared language design and engineering use to make decisions together, faster and with less rework than before.
Governance
Building the system was only half the problem. The harder question was how to keep it consistent as teams grew and new patterns emerged.
The answer wasn't central control — that would have created the same bottleneck the system was designed to remove. Instead we established a lightweight contribution model built on shared accountability.
Any team could propose a new component, pattern, or token. Every proposal followed one path before entering the library.
step 1
Proposal
Any Team can request
• Use Case
• Gap Analysis
• Token Mapping
step 2
Review
Team reviews the request
• Fit Check
• Consistency
• Complexity
step 3
Validation
Real Product
• Live Context
• Edge Cases
step 4
Approval
System team approves the request
• Changelog
• Version Bump
• Comms Rollout Plan
step 5
Publish
Updates are published to production
• Figma Library
• Storybook
• npm package
Teams contribute to something they co-own,
not consume from something handed down.
Learnings
Looking back, the hardest problems were never about components.
Consistency is a coordination outcome
You can't design your way to consistency without solving how teams decide together. Visual inconsistency was the symptom. Coordination was the cause.
Adoption needs value, not compliance
Teams adopt when the system works for them — not because they're told to. Enforcement creates resistance. Value creates pull.
Scale reveals coordination gaps
Local decisions compound into organisational friction at scale. The problem isn't the decision — it's the absence of a shared framework for making it.
Sustainable systems need ownership
Governance and shared accountability keep a system healthy long after the build. Without them, entropy wins — slowly, then all at once.