Establish how teams will work together
Naming, onboarding and contribution guidance deserved as much attention as the components. I would establish these agreements early.
Traction · The complete case study · 2022-2024
Behind the library.
How I led a fragmented Sketch library into a reusable Figma system: the four-week core release, the decisions shared with engineering, and the work that supported adoption over two years.
Shared foundations
primary/brand_redMapped to color.red.500- My role
- Design systems leadStrategy, architecture, naming & adoption
- Core team
- 3 designers · 1 front-end engineerDesign and engineering built the shared foundation together
- Scope
- Consumer, enterprise & internalShared styles, components and guidance across product teams
Tools across the project
- Figma
- Supernova
- Storybook
4weeks
From audit to core library
Reusable styles and components; docs followed.
16+
Workstreams supported
Consumer, enterprise and internal tools.
~40%
Lower Figma library memory
Component properties and token refinement.
~50%
Fewer ad-hoc design requests
First month after docs vs. after MVP.
Context and discovery / Week 1
The cost of fragmented foundations.
Years of independent product work had left Discount Tire's consumer, fleet, in-store and enterprise products with inconsistent foundations and repeated component decisions. In my first month, I volunteered to lead the move from Sketch to Traction. I owned strategy, architecture and adoption, working with a core team of three designers and one front-end engineer.
What the audit exposed
- Legacy Sketch symbols
- 500+
- Versions of brand red
- 37
- Competing body sizes
- 13 / 15 / 17px
Audit scope and leadership alignment
Discount Tire operates 1,100+ US stores. The audit covered active and dormant symbols, colors, typography, spacing and variants across consumer and enterprise products. The original project record describes interviews with eight designers and four engineers.
I made the case for reducing repeated UI work, inconsistent branding and undocumented patterns. Leadership backed a four-week MVP ahead of the Q3 engineering roadmap. I involved engineering early to align the library structure with production.
Strategy and sequencing
A focused MVP, built alongside the audit.
The next engineering roadmap needed a usable core in four weeks. I ran the audit and build in parallel, scoping the MVP around reusable Figma styles and components. Engineering helped shape the architecture; documentation followed release. This gave teams a working library sooner, with refinement continuing after launch.
Delivery strategy
Why work in parallel?
Start4-week targetLater
Overlapping work, earlier feedback.
The chosen approach4weeksA usable core, ready for the team.
Delivery decision
Deliver the core in four weeks.
Audit Sketch and build Figma together. Deliver the core in four weeks; refine gaps after release.
From first release to ongoing use.
- 4 weeks
Release the core
Reusable styles and components, aligned with engineering.
- First month of use
Refine the behavior
Resolve bugs and specify missing interaction states.
- Beyond the MVP
Support ongoing adoption
Expand essentials, document usage and establish shared review.
The tradeoff: parallel files, then consolidation
Separate Tokens, Iconography and Typography files supported parallel work. The original project record describes consolidating these into Traction Global to simplify navigation and publishing dependencies.
The MVP shipped in four weeks. Adoption, refinement, documentation and governance continued over the two-year project.
Color, typography and iconography
Standardizing color, type and iconography.
Shared palettes, a Lato type scale and icon families replaced individual choices with repeatable standards. We named colors by their purpose, so a designer could choose a text or border role rather than a new hex value. We targeted WCAG AA and assessed contrast within each interface.
01 / Color values
From values to semantic roles.
Choose a foundation color to see how a semantic role defines its use.
Semantic role
$color-text-brandAlias: Red 60Role applied to textReady for the next step.
Shared values, applied through semantic roles.
$color-text-brandBrand red → $color-text-brand
02 / Typography
1.125Major SecondA consistent type hierarchy.
Traction / Typography specificationLive specimen
Made for real work.
Lato · Heading L · 28px · Weight 700Desktop headings
View original specificationsTypography reference
| Role | Font | Size | Weight | Context |
|---|---|---|---|---|
| Heading XL | Lato | 36px | 900 | 4K monitors and large hero |
| Heading L | Lato | 28px | 700 | Desktop section titles |
| Heading M | Lato | 22px | 700 | Tablet headers |
| Body default | Lato | 16px | 400 | Global body copy |
| Caption | Lato | 12px | 500 | Associate iPad tools |
03 / Iconography
400+Custom iconsFind by intent.
Traction / Iconography specificationLive examples
Actual size / 1×
Find a location
24px example in an interface24px master · 2px strokeConstruction reference / 4×
Navigate / 24px selected
Interactive examples are reconstructed. The original CVM and WOM sheets show the project's icon drawings and optical adjustments.
Icon families across products
Original Figma artifactsCVM icon library
CVM icon library, 1 of 2
Full palette, type scale and icon search rules
Primary
Red 50
#FCD9DARed 500
#E6121ARed 700
#B70E15Black
#121213White
#FFFFFFSecondary
Blue 50
#D5E5F8Blue 500
#3483DEBlue 700
#1D62B1Green 50
#E2F2DEGreen 500
#52A240Green 700
#407D32Gold 50
#FFF0D9Gold 500
#FFA10DGold 700
#C87A00Neutral
Grey 50
#F8F8F8Grey 100
#EFEFF0Grey 200
#DDDDDFGrey 300
#C3C3C6Grey 400
#A9A9AEGrey 500
#98989DGrey 600
#75757CGrey 700
#545459Grey 800
#333336Grey 900
#1A1A1CNeutral-B
Grey-B 50
#F1F2F5Grey-B 100
#DDE1E7Grey-B 500
#667792Grey-B 600
#515F74| Role | Font | Size | Weight | Context |
|---|---|---|---|---|
| Heading XL | Lato | 36px | 900 | 4K monitors and large hero |
| Heading L | Lato | 28px | 700 | Desktop section titles |
| Heading M | Lato | 22px | 700 | Tablet headers |
| Body default | Lato | 16px | 400 | Global body copy |
| Caption | Lato | 12px | 500 | Associate iPad tools |
The original type scale used a 16px base and a 1.125 Major Second ratio, with roles for desktop, tablet, mobile and associate iPads. Palettes used 50-900 steps; semantic aliases referenced them rather than adding independent hex values.
Icon variants included optical compensation and covered consumer, internal and fleet products. Intent-based search connected Navigate to map, directions, location, GPS and pin. A token alone does not establish contrast compliance; foreground, background, size and use matter.
Architecture and naming
Mapping design conventions to engineering needs.
Designers wanted browsable Figma names; engineers needed names that fit the codebase. I mapped the two structures instead of imposing one convention. Follow the red example below: a foundation provides the value, a semantic role names its purpose, and a component uses it. Figma Variables were unavailable, so the MVP carried this structure through color and text styles.
Illustrative live preview
Made for real work.
Shared styles. Consistent intent.
Same primitive, applied to the button.
ValueRoleComponent
Project naming reference
Figma color style
primary/brand_redEngineering primitive
color.red.500Semantic roles in the original library
Original Figma artifactsSemantic text tokens
Semantic text tokens, 1 of 3
Semantic styles defined usage; foundation palettes supplied the values.
All 27 semantic examples, category counts and spacing rules
| Semantic token | Foundation alias | Hex value |
|---|---|---|
$color-text-default | Brand Black | #121213 |
$color-text-subtle | Gray 80 | #333336 |
$color-text-subtler | Gray 70 | #545459 |
$color-text-subtlest | Gray 60 | #75757C |
$color-text-disabled | Gray 50 | #98989D |
$color-text-inverse | White | #FFFFFF |
$color-text-interactive | Blue 80 | #1D62B1 |
$color-text-success | Green 80 | #407D32 |
$color-text-danger | Red 90 | #A50000 |
$color-text-brand | Red 60 | #E6121A |
$color-icon-default | Brand Black | #121213 |
$color-icon-subtle | Gray 90 | #1A1A1C |
$color-icon-subtler | Gray 70 | #545459 |
$color-icon-disabled | Gray 50 | #98989D |
$color-icon-inverse | White | #FFFFFF |
$color-icon-brand | Red 80 | #B70E15 |
$color-icon-interactive | Blue 80 | #1D62B1 |
$color-icon-success | Green 80 | #407D32 |
$color-icon-warning | Gold 80 | #C87A00 |
$color-border-default | Gray 70 | #545459 |
$color-border-subtle | Gray 60 | #75757C |
$color-border-subtler | Gray 40 | #A9A9AE |
$color-border-bold | Gray 90 | #333336 |
$color-border-disabled | Gray 50 | #98989D |
$color-border-focused | Blue 60 | #3483DE |
$color-border-brand | Red 80 | #B70E15 |
$color-border-success | Green 80 | #407D32 |
Production groups were Text (11), Brand (5), Icon (10) and Border (9). Exploratory palettes were Blue (5), Green (5), Gold (4), Grey (10) and Grey-B (4), used for prototypes and illustration. These category counts total 63; the original graphic's separate 60 styles label is inconsistent.
Text roles included default, subtle, subtler, subtlest, disabled, inverse, interactive, success, danger and brand. Icon roles included default, subtle, subtler, disabled, inverse, brand, interactive, success and warning. Border roles included default, subtle, subtler, bold, disabled, focused, brand and success.
Spacing followed the same primitive-to-intent distinction: $spacing-16 mapped to $spacing-inline-md. The naming agreement connected conventions; it did not require Variables in the MVP.
Design and development integration
Carry the shared decisions into implementation.
The naming agreement gave the teams a common reference; connecting Figma components to Storybook carried it into implementation. Designers and engineers could review the same variants and intended states. The reconstructed example below changes both representations together.
One component, two connected references
Connected examplesA shared component reference.
FigmaComponent reference
VariantPrimaryStaterestLabelView options
StorybookComponent story
Illustrative story args
variant: "primary"
state: "rest"
color: "red"
icon: trueOriginal red-primary mapping
button/primary/red/defaultbutton.primary.background.defaultShared reviewVariantsIntended statesToken usage
Reconstructed Figma and Storybook previews share controls with the component playground.
Engineering checks and the scope of the workflow examples
The archived engineering narrative describes coordination across eight workstreams with different technologies. Storybook was the preferred reference for web teams; extending it to other internal tools and platforms remained under discussion. This is distinct from the system's eventual reach across 16+ workstreams.
The original record describes Storybook components mapped to Figma, visual regression checks, token linting and PR review checklists for hardcoded colors or spacing.
The terminal commands, 128-variable build and live-sync panels illustrate the workflow. The MVP itself used structured Figma styles, before Variables were available.
Release and refinement
Real use exposed the behavior still missing.
We released to designers first, keeping analysts, researchers and leadership involved. The MVP made 95% of required components available, but some interaction states still needed definition. In the first month, we resolved bugs and specified secondary button focus and inactive behavior, so engineers could build without pausing for clarification.
95%Components available at MVP
80%Initial usage target, not a result
Component variants and states
Define the behavior of every state.
States refined after launch
Live preview · Try the button
Choose a state or interact with the preview.
<Button variant="primary" state="rest" icon />Reconstructed component example. Original Figma artifacts are available alongside it.
Post-launch library refinement~40%Lower Figma library memory
We used Boolean, instance-swap and text properties to reduce separate variants. Alongside token consolidation, these refinements lowered library memory by approximately 40% while we expanded essential components.
Refinement across component families
Original Figma artifactsProduct card supporting components
Product card supporting components, 1 of 2
Post-MVP / Documentation and unification
Organizing documentation around familiar workflows.
After the MVP, we developed documentation for design, engineering and product teams. It covered usage, implementation, patterns and contributions, giving people a reference beyond the component itself. The request counts below compare the first month after documentation with the first month after MVP launch.
~50%Fewer ad-hoc design requests
Counted in the first month after documentation versus the first month after MVP launch.
Library structure / Foundations
Choose by intent
Use the Text, Icon, Border and Brand groups for production work. The shared naming structure connects the design styles to their code references.
Familiar categories
Navigation concept illustrating the shared structure and audience-specific guidance.
- Getting Started
- Foundations
- Components
- Patterns
- Help Guides
- Contact
Role-specific guidance, publishing and onboarding
We tailored guidance to each role: implementation and code snippets for engineers, usage and customization for designers, pattern guidance for PMs, plain-language references for BAs and previews for stakeholders. Alerts and validation included examples, status icons, colors and usage guidance.
During months two through six, the split foundations files became Traction Global, simplifying navigation and publishing. Getting Started, changelogs and migration guidance supported releases. The original record reports onboarding under two hours, without a reproduced measurement basis.
The request reduction comes from counts in two one-month periods. It is separate from the survey ratings and does not measure asset discovery time.
Feedback and response
Positive feedback, with clear priorities for refinement.
Five of six designers said reuse sped up their work. All six rated accessible design and token use Good or better; five gave consistency the same positive rating. These findings affirmed the foundations while showing where contribution and discovery guidance could improve.
5/6
agreed reusing components sped up their workflow.
Reuse / agreement question
3Strongly agree2Agree1Neutral
Designer experience
Six responses · Mean /5 · Good or better /6| Area | Poor | Fair | Good | Very Good | Excellent | Mean /5 | Good or better |
|---|---|---|---|---|---|---|---|
| Consistency | 4.00 /5 | 5/6Good or better | |||||
| Accessible design | 4.17 /5 | 6/6Good or better | |||||
| Token use | 3.83 /5 | 6/6Good or better | |||||
| Asset discovery | 3.83 /5 | 6/6Good or better | |||||
| Contribution | 3.50 /5 | 4/6Good or better | |||||
| Requesting changes | 3.83 /5 | 5/6Good or better | |||||
| Overall experience | 3.83 /5 | 5/6Good or better | |||||
| Design efficiency | 3.17 /5 | 4/6Good or better |
Six designer responses per question. Self-reported ratings; not timed delivery data.
What we took forwardKeep the foundations.
Keep the foundations.
Improve the path to using them.
Reuse and the shared foundations were working. Contribution and discovery feedback helped identify where guidance needed to be clearer.
We reorganized Supernova to mirror Figma and clarified contribution guidance, building on the value designers already saw in the library.
Full response distributions and measurement context
The survey included 22 people: 14 designers, five developers and three UX product analysts. These experience questions had six designer responses. Overall Traction experience averaged 3.83/5 (n=6), versus Sketch at 3.25/5 (n=4). Different respondent counts; not a paired speed comparison.
| Question | Poor | Fair | Good | Very Good | Excellent | Mean /5 |
|---|---|---|---|---|---|---|
| Overall experience | 0 | 1 | 1 | 2 | 2 | 3.83 |
| Keeping consistency | 0 | 1 | 1 | 1 | 3 | 4.00 |
| Creating accessible designs | 0 | 0 | 2 | 1 | 3 | 4.17 |
| Contributing to the library | 1 | 1 | 1 | 0 | 3 | 3.50 |
| Requesting modifications | 0 | 1 | 1 | 2 | 2 | 3.83 |
| Finding the right assets | 0 | 0 | 3 | 1 | 2 | 3.83 |
| Utilizing tokens | 0 | 0 | 3 | 1 | 2 | 3.83 |
Reuse: three strongly agreed, two agreed and one was neutral. Design efficiency: two Fair, two Good, one Very Good and one Excellent. Asset discovery: three Good, one Very Good and two Excellent. Contribution: one Poor, one Fair, one Good and three Excellent.
The separate familiarity question had 12 designer responses: Traction averaged 4.17/5 and Sketch 2.83/5. Familiarity and overall experience are different measures; individual questions had different response counts.
Detachment frequency had six responses: two very rarely, one rarely and three occasionally. This cannot establish an instance-level detachment percentage.
Scale and governance / Years 1-2
Let teams extend. Keep the library coherent.
Across 16+ workstreams, teams needed room to address their own product needs. Short proposals (RFCs) and contribution tiers gave them a path to propose additions. The core team reviewed quality, token alignment and accessibility before changes entered the shared library. The example below separates who proposes, who reviews and who reuses the result.
From product need to shared pattern.
Start with a product need.
Describe the use case and check existing patterns before proposing an addition.
Proposed useVehicle selector
Help a customer find tires that fit.
Core review checks
- Quality
- Token alignment
- Accessibility
Illustrative workflow and vehicle-selector example.
Teams could adapt starter canvases, headers and footers when their product context required it. We distinguished justified customization from unnecessary detachment.
Contribution practices and additional reported outcomes
Previews, naming guidance, review checklists and plain-language documentation supported contributors and adjacent roles. We treated hardcoded values as design debt and used quarterly reviews to inform the roadmap.
These additional figures come from the original case study. Their underlying measurements are not reproduced here; they remain separate from the confirmed outcomes and verified survey.
3 → 18Active contributors over two years
2Maintainers: one designer and one engineer
~2 weeks → 3-5 daysReported spec-to-shipped delivery
~4%Reported detachment rate, excluding justified cases; original source: Figma published-library analytics
~65%Reported reduction in asset discovery time
~60%Speed reduction shown in the original leadership illustration
<2 hoursReported onboarding time
37 / 83 / 120Rogue colors, duplicated components and undocumented patterns shown as eliminated in the original debt illustration
The original debt illustration totals 240+ issues and shows 37 to 0 rogue hex values. Survey frequency answers cannot verify its reported 4% detachment rate.
Reflection and next steps
What I would repeat, and what I would change.
Plan publishing alongside parallel work
Separate files supported the sprint; a unified library simplified navigation and publishing. I would plan that consolidation earlier while preserving room for parallel contributions.
Use familiar structures for documentation
Matching Supernova to Figma made guidance easier to navigate. I would plan documentation structure alongside the library architecture.
Support contributions with a clear review process
Give product teams room to extend the system, with shared checks for consistency and accessibility.
Next step / Planned, not shipped
Traction Academy
DevelopersToken integrationDesignersComponent customizationProduct managersSystem capabilities
Planned workshops would help each role apply the system, alongside continued work on engineering alignment and contributions.