About
About
Work/Traction Design System
Design SystemsEnterpriseGovernance

Traction Design System

How I built a token-driven design system in 4 weeks for America's largest independent tire dealer — unifying 16+ workstreams and cutting design support requests by half.

Role

Design Systems Lead

  • Lead Architect — Strategy, governance & token maintenance
  • Mentor — Onboarding & guiding product teams

Team

3 designers +

1 engineer

  • Core systems pod — design-led with engineering partnership

Tools

FigmaDesign & tokens
SupernovaDocs
StorybookDev

Timeline

4 wks → 2 yr scale

W1W46mo2yr
AuditTokensMVP BuildDocs & UnifyGovernance
Designed for
desktop
tablet
mobile

TL;DR — The Outcome

What shipped

  • Token-driven design system — single source of truth for Discount Tire's digital org
  • Powers discounttire.com, enterprise tools, and 16+ concurrent workstreams
  • Supernova-hosted docs cut ad-hoc design inquiries by ~50%

My role

  • Design Systems Lead, core team of 4 (3 designers + 1 FE engineer)
  • Federated contribution from product designers across the org
  • Owned system strategy, token architecture, governance, docs, and onboarding

Timeline

  • Phase 1 (MVP): 4-week sprint timed to Q3 kick-off
  • Phase 2 (Scale): 2-year continuous delivery roadmap
  • Quarterly sentiment check-ins
~55%Lighter Figma librariesvs. per-component builds — via advanced properties & token consolidation
16+Workstreams on one systemConsumer, enterprise & internal tools
~50%Fewer ad-hoc design requestsSelf-service docs via Supernova
3→18Active system contributorsDesigners across teams now co-own the system

Next case study

Product Card Redesign

Vamsi Karuturi

Senior UX Designer

© 2026 Vamsi Karuturi. Crafted with intention.

01Phase_One

Audit &
Strategy

“Deconstructing the Silos”

Audited 500+ legacy symbols. Secured stakeholder buy-in for the Figma migration. Architected the ‘Foundations/Semantic’ token layers.

Context

How I got the brief

There was no design systems specialist on the team. I’d worked with multiple design systems at previous companies, so when the gap became obvious I volunteered for the lead role — three months into joining Discount Tire, still ramping on the product surface, mid Sketch–to–Figma migration. This wasn’t handed to me as a mandate. Every architectural call in what follows is mine to own or to flag as a miss.

Volunteered, not assigned3 months into the companyNo DS specialist on teamMid Sketch → Figma migration

The Challenge:
Concurrent Execution

The Constraint

Four challenges, running in parallel.

01

Build

A system from scratch — no tokens, governance, or playbook to inherit.

02

Coverage

Multiple product lines — consumer site, B2B ordering tools, internal store apps.

03

Lockstep

Design and engineering moving at different velocities on the same contract.

04

Migration

A company-wide Sketch → Figma transition absorbed into the rollout.

All inside a rigid 4-week window before the Q3 engineering roadmap began. Traditional waterfall (audit → design → build) was impossible.

The Strategy

“I implemented a concurrent migration strategy. Instead of waiting for a perfect system, we built the aircraft while flying it — auditing legacy Sketch files and architecting the new Figma components in parallel. This allowed us to ship the ‘Traction’ MVP precisely when engineering needed it.”

Interactive_Simulation

Timeline_Dynamics

Q3_Launch_Deadline
Week 1Week 2Week 3Week 4Week 5
Audit
Legacy Sketch Review
Design
Token Architecture
Build
Component Library

Efficiency_Report

Failure ⚠

Linear execution exceeds the mandatory Q3 roadmap entry. Traditional handoffs create a 2-week bottleneck, pushing launch into late August.

Strategic_Outcome

System delivery: 0% at deadline

System_Mandates

Object: Infrastructure_System

Class: Design_Engineering

Core_LibTraction
Status: Operational

Strategic
Objectives

1

Unify the Tooling (Migration)

Eliminate tool fragmentation by migrating the entire organization from Sketch to Figma, establishing a single source of truth for 16+ workstreams.

2

Architect the Foundation

Establish a scalable governance model and documentation site to reduce onboarding time and enforce UI consistency across the enterprise.

3

Engineer for Scale (Tokenization)

Bridge the design-engineering gap by implementing a multi-tiered token architecture (Primitives vs. Semantic), ensuring code parity and future-proofing for dark mode/theming.

Stakeholder_Alignment

Selling the System

A design system only succeeds with executive sponsorship. I framed the investment around three pillars that resonated with leadership at Discount Tire.

Sprint_VelocityBefore → After
UI Build
QA Review
Handoff
~60%avg. reduction

Speed to Market

Pre-built, tested components eliminate redundant UI work. Teams stop rebuilding buttons and start shipping features. At enterprise scale, this compounds — 16 workstreams all pulling from one library instead of inventing their own.

Visual_Consistency
Before
After
1 Sourceof truth

Consistency at Scale

Without a system, every team interprets the brand differently. Customers moving between the e-commerce site, in-store iPads, and internal tools experienced a fractured brand. A shared library means one visual language across every touchpoint.

Debt_Eliminated
Rogue Color Values
370
Duplicated Components
830
Undocumented Patterns
1200
240+issues resolved

Reduced Design Debt

Years of ad-hoc design had created a sprawling inventory of rogue values, duplicated components, and undocumented patterns. The system audit gave leadership a concrete numberto quantify the problem — and a clear path to zero.

Token_Layer_01

Foundations:
Primitive
Color Scales

The Root Cause

37 reds emerged from designers working in silos — each sampling color from whatever non-standardized source was closest at hand: print assets, competitor sites, one-off hover states. Legitimate local choices, none coordinated.

The Build Order

01

Foundations First

The standardized baseline. Stepped scales 50–900 for Primary, Secondary, and Neutral — all anchored to WCAG AA.

02

Semantic Tokens On Top

Built only after Foundations were locked. Never reference a raw hex — only a Foundation.

“No opinion on usage — just mathematically consistent values that the semantic layer references.”

Mathematical_Framework

Foundations:
Mathematical Typography

The Problem: “Eyeballed” Hierarchy

The legacy audit revealed a chaotic mix of font sizes — designers were manually picking values like 13px, 15px, and 17px based on personal preference. This broke vertical rhythm and made maintaining responsive behavior a nightmare across 16 workstreams.

AaAaAaAaAaAa— inconsistent

The Solution

1

1.125 Major Second Scale

Replaced manual guesswork with a strict Modular Scale anchored at 16px base. Every size in the system is mathematically derived from a single ratio.

2

Algorithmic Harmony

Every heading level relates proportionally to body text. No more visual guessing — the math guarantees consistent vertical rhythm across every screen.

3

Responsive Tokens

A “Fluid Type” strategy where tokens like Heading-XL automatically map to different rem values across Desktop, Tablet, and Mobile. A headline on a 4K monitor scales down perfectly for an associate’s iPad in-store.

Asset_Standardization

Foundations:
Icon
Library

400+Custom assets
rebuilt from scratch

Optical standardization across the full asset library. Every icon was rebuilt on a unified master grid with a consistent stroke weight.

Technical Grid

24px

Master grid

2px

Stroke weight

Domain Sets

B2C WebsiteInternal ApplicationB2B Fleet

The Search Taxonomy

Navigate
also surfaces on
mapdirectionslocationGPSpin

Alternates baked into every component’s Figma description. Find by intent, not file name.

02Phase_Two

Architecture &
MVP

“The 4-Week Sprint”

Establishing a friction-free pipeline between Design and Engineering.

MVP_Core_Pillars

Three Pillars

The 4-week sprint was structured around three non-negotiable deliverables that engineering needed to begin consuming the system.

MVP_Core
Figma_Design
JSON_Tokens

Tokenization

We mapped Figma Variables directly to codebase JSON/CSS tokens. This automated the handoff, ensuring that a color change in design propagated to the development environment without manual translation errors.

Architecture_Layer
MVP_Core
80%Usage_KPI
Storybook_Synced

Developer Adoption

Adoption fails when it requires effort. We integrated the system directly into the engineering workflow (Storybook), setting a KPI of 80% component usage within the first quarter to measure success.

Architecture_Layer
MVP_Core
Component_Preview: Button
<Button variant="primary" />
WCAG_AA_Pass

Documentation

Docs scaled with audience. At day one, they lived where the users already were — Figma component descriptions for designers, Storybook with inline prop docs for engineering. Supernova came later, giving business analysts and leadership a single canonical reference, while still surfacing live dev components for technical teams. DM support requests dropped ~50%.

Architecture_Layer
Variable Collections — Color Stylesv1.0
Production · Intent Collections
Text11
Brand5
Icon10
Border9
Exploration · Extended PalettesNot for Prod
Blue5
Green5
Gold4
Grey10
Grey-B4
Traction / Semantic Variables60 color styles

Token_Strategy

Token
Configuration
Strategy

Bridging design and code with a semantic variable architecture.

1. Data-Driven Migration

Audited the codebase, mapped primitives to existing UI patterns — 95% coverage of production use cases in the first sprint. No guesswork.

2. Semantic Aliasing

Named by intent, not appearance — $color-text-subtle, not Grey-600. Decisions decouple from hex codes.

3. Scoped Collections

Semantic tokens grouped by intent — Text, Border, Icon, Brand. Search “text” and see only the ~10 approved options, not the full Foundations palette. The collection pre-filters the decision.

4. Extended Palettes (Exploration Only)

Blue, Green, Gold, Grey scales stay in the panel as an escape hatch for spikes, prototypes, and illustration work. Production must come from the intent collections, and this rule is documented directly on the Variables in Figma. Exploration gets flexibility; production gets discipline.

The Pushback · Before Variables shipped
Asymmetric_Bet

I hand-authored the token layer before Figma Variables existed.

Variables was still in beta when we kicked off. Engineering’s ask: skip tokens, hardcode values, tokenize later.Reasonable on a 4-week timeline. I pushed back because the cost of being wrong was asymmetric — if we skipped tokens and Variables shipped, we’d spend months refactoring out of hardcoded values. If we built a token layer and Variables never landed, we’d pay coordination overhead and keep all the upside.

Downstream benefit

Developers no longer ask, “Which grey do I use?” — the token name answers the question. The codebase was also primed for instant Dark Mode switching from day one.

Cost-of-Being-Wrong
Manual · Weeks 1–12Pre-Variables

Hand-authored palette, mirrored 1:1 with engineering’s variable scheme. Sync work was mine — roughly 15% of my week.

1:1 Swap
Variables ShippedDays, not months

Reference swap to the new Variables. No component changes, no codebase touch. Migration took days.

15%
Weekly overhead
absorbed personally
0
Component changes
at migration
1:1
Naming parity
design ↔ code

The contract we defined was between design and code— not between Figma and anything else. Tools changed. The contract held.

Development_Integration

Engineering
Sync

Coordinating developer adoption across eight distinct workstreams presented a significant challenge. To ensure consistency and efficiency, we aimed for a single source of truth for all development components, regardless of the varied technologies and platforms involved.

Storybook emerged as the preferred solution for our web development teams, with discussions actively continuing for its implementation across other internal tools and platforms.

Storybook_Traction
🔍 Find Component...
Architecture
❯Introduction
❯Design Tokens
❯Changelog
Core_Components
Action_Button
TextInput
CheckBox
SurfaceCard
Action_Button
Active_Variable_Mapping
background: $color-brand-default;
❯_Sync_Terminal_v2.4
Live_Sync
[23:49:35]CMD:npm run tokens:build
[23:49:35]FETCH:$color-border-brand -> Red 80 (#B70E15)
[23:49:35]WARN:Deprecated variable detected: red-light-v2
[23:49:35]BUILD:Compiling 128 semantic variables...
[23:49:35]BUILD:Compiling 128 semantic variables...
[23:49:35]SUCCESS:Tokens injected into 16 workstreams
🔒traction.supernova.io/patterns/alerts
⚙
📖Traction_Docs
Foundations
IntroductionDesign TokensAccessibility
Patterns
AlertsForm ValidationNavigation
Status: StableModified: Feb 12, 2026

Alert
Patterns

Alerts provide contextual feedback messages for typical user actions with the help of status icons and colors.

👁 View_Code
✖
System ErrorYour connection was lost. Please retry.
✔The_Do's
The_Don'ts
Outcome · Post-Rollout
~50%
Ad-hoc inquiries

The “Single Source of Truth” cut ad-hoc design inquiries roughly in half — freeing the team for strategic UX problems, not component Q&A.

Knowledge_Infrastructure

Self-Service
Documentation

Empowering Business Analysts and PMs with a “No-Code” reference

The Problem: Design as a Bottleneck

Traditionally, Product Managers and Business Analysts had to ping designers just to ask, “Do we have a component for this?” or “What are the rules for this alert?” This created a constant support queue that distracted the design team from strategic work.

The Solution: Democratized Access via Supernova

After the core MVP stabilized, we expanded the documentation strategy beyond just designers and engineers. I configured Supernova to serve as a self-service knowledge base for the entire organization.

For PMs: Clear "Do's and Don'ts" for patterns, allowing them to write accurate requirements before a designer even opens Figma.

For Stakeholders: Live previews of components, ensuring that leadership reviews the system, not just static screenshots.

03Phase_Three

Scale &
Governance

“From ‘Policing’ to ‘Federated Contribution’”

Onboarded 16+ workstreams. Implemented the contribution model. Reduced design debt by shifting from “detached instances” to strict library usage.

Adoption_Tracking

Adoption Metrics& Sentiment

Quantifying the developer and designer experience (DX/UX)

The Strategy: Measuring “System Fit”

You can’t improve what you don’t measure. We launched a comprehensive Sentiment Baseline Survey targeting our primary users: Product Designers, Frontend Engineers, and Business Analysts.

The Insights:

Consistency Win: 50% of respondents rated the system "Excellent" for keeping consistency, validating our token architecture.

The Friction Point: The survey revealed that "Finding the right assets" was a friction point (rated only "Good" or "Fair" by some).

The Pivot: This data directly influenced our roadmap. We deprioritized new component creation and prioritized Search Optimization in our Supernova documentation to address the discoverability gap immediately.

83%Agree TDS speeds up workflow
50%Rated consistency "Excellent"
4.17/5
Avg satisfaction score
Traction
Sketch
System Maturity · Year 2

The system earned its trust

How adoption, coverage, and governance held up across 16+ concurrent workstreams— and the numbers behind them.

All figures post-rollout
Reflection

What I carry forward

01

Change management is design work

Trust from eighteen designers mattered more than the token architecture.

02

Ship unified, not fast

Splitting into three Figma files — Tokens, Iconography, Typography — hit the sprint deadline, but cross-library mismatches made me wish I’d shipped unified.

03

Let friction guide the roadmap

Sentiment data said discoverability, not missing components. We pivoted.

04

A design system is a social contract

Every technical decision has a human cost worth accounting for.