One Design System for Design and Engineering
UI bugs
−30%
6 months after rollout
Handoff time
2 wks
3 days
Design to engineering
Blocked features
3 shipped
Unblocked by the new system
Two sources of truth, and neither was right
When I joined Tekmetric in 2023 as the company’s second designer, engineering was building from an outdated, incomplete Storybook library while design worked from its own files. The two had drifted apart, and it showed in the product:
- Duplicated components doing the same job in different ways
- Inconsistent buttons, typography, shadows and status colors
- Blue-on-blue tabs that made inactive tabs look disabled
- New patterns from one team that other teams didn’t know existed
- A growing backlog of UI tech debt
That drift slowed every release and put reliability, and retention, at risk. I was the only designer on the effort, with no PM or engineering lead, while also designing for two other product areas.
Document What Exists
Before proposing anything new, I spent my first year building a Figma library that mirrored every component engineering had already built in Storybook. It gave design and engineering one shared vocabulary, and it surfaced the evidence I’d need later: every duplicate, gap and inconsistency, documented.
Year one: bridging the gap
Engineering
Storybook library
Outdated and incomplete, but what actually shipped.
⇄
1:1
Design
Figma library
Mirrors every Storybook component: same names, same states.
ResultOne shared vocabulary, and a documented list of duplicates and gaps to build the pitch on.
Define Global Styles for a New Design System
Before proposing anything new, I spent my first year building a Figma library that mirrored every component engineering had already built in Storybook. It gave design and engineering one shared vocabulary, and it surfaced the evidence I’d need later: every duplicate, gap and inconsistency, documented.
Scalability
Variables map brand values to every component part, so one change updates everywhere.
Accessibility
Readable type, clear contrast and comfortable targets for users who are mostly 40 to 60.
Cohesion
Shared rules for color, type and spacing, so every team’s work looks like one product.
Library Structure
How variables flow through the system
01 · Primitive
Raw values
Color
Type
Spacing
→
02 · Semantic
Named by purpose
Action
Surface
Text
→
03 · Component
Mapped to parts
Button
Input
Dropdown
Icon
Change a value once and every component that uses it updates.
Voice and Tone
Direct and Confident
Say what needs to be said in as few words as possible.
Avoid jargon
Always choose a short, simple word over a complicated one.
Describe the action
All buttons and links should start with a strong verb.
Current Problems
The top and side nav was the first component I rebuilt in the new system, for three reasons:
Sets the tone
It would set the visual direction for every component that followed.
Visible, low risk
Users focus on content, and keeping every menu item in place protected their trust.
Most broken
It didn’t scale across breakpoints, couldn’t support mobile web, and had no room for nested menus.
Research: Breakpoints and Navigation
I studied how other products in our users' daily toolkit handle navigation, to keep their web experience familiar. I then built a new Figma library with variables mapped to every part of the nav: buttons, inputs, dropdowns and icons, and explored two directions:
Solution
After six rounds of iteration, I shipped direction B: nested menus for a growing app, a modern look, and a simpler palette that doesn’t compete with content. After release:
- No usability complaints on Canny or our Facebook community
- More usage on smaller screens
- Room for 2 new features in the nested side nav
Direction A · Future state
Side nav replaces the top nav
Built for an information-dense product, but the biggest change for users.
Direction B · In-between
Shipped
Nested side nav, familiar top nav
Every top nav item stays in place with updated colors, while the side nav gains nested menus.
Incremental Release
Once the nav proved the approach, I partnered with one front-end engineer to modernize all 500 components, releasing them incrementally through early 2026 with the same low-risk scoring. The new foundation also set up what comes next: redesigning high-traffic pages like the estimate page.
Selling a design system without a PM
With the audit in hand, I pitched the design system to stakeholders as a velocity and retention investment, not a visual refresh. I gathered engineering issues and counted duplicated components to show the cost of doing nothing.
The key decision was how to ship it. A full overhaul would finish sooner but risk disrupting shops that live in Tekmetric all day. I proposed an incremental rollout instead, and scored every release by how much it would change for users:
Low impact release
Ship it
Small changes with minimal disruption.
✓ No training or onboarding needed
✓ No impact on core workflows
✓ No expected downtime
✓ Easy to roll back
High impact release
Plan first
Changes core functionality and needs user adaptation.
! Needs training or documentation
! Could cause downtime or support load
! Likely user resistance or confusion
! Hard to roll back
How it rolled out
2023
Joined as the second designer
Found engineering building from an outdated Storybook library.
Year one
Mirrored Storybook in Figma
One shared library for design and engineering.
Next
Designed the new system
Built for scalability, accessibility and cohesion.
Approved
Pitched an incremental roadmap
Low-risk releases instead of a full overhaul.
First release
Top and side nav
The proof point for the whole system.
Early 2026
500 components modernized
Shipped with one front-end engineer.
Faster handoffs, fewer bugs, an unblocked roadmap
A design system’s impact is hard to isolate, but six months after the major components shipped:
Design-to-engineering handoff
Before
2 weeks
After
3 days
- UI bugs dropped 30%
- Product teams shipped 3 major features that had been blocked
- Groundwork laid for redesigning the estimate page
What I’d carry forward
What worked: Documenting the existing library first earned engineering’s trust before I asked them to change anything.
What I’d do differently: Spend more time documenting the behavior of components so other designers can contribute to the library.
Next: The future-state side nav, and redesigning high-traffic pages like the estimate page on the new system.