Case study · Stavvy
Design System
Building the foundation that lets everything else move faster.
Year · 2022–2024
Role · Head of Design
Product · Stavvy Design System
The hardest part of building a design system isn't the components. It's convincing people it's worth building at all.
A design system is an investment that pays off in the future. Leadership naturally asks: why slow down now to go faster later? Making that case, not just philosophically, but with a concrete plan, a clear scope, and a credible path to adoption, is the real design leadership challenge.
At Stavvy I led the initiative to build a design system from the ground up. That meant getting leadership aligned on the investment before writing a single token, partnering closely with front-end engineers to make sure what we built was actually adoptable, and working from atomic foundations up through full templates, so the system could scale with the product rather than constraining it.
The result was a system that front-end engineers actually wanted to use. That doesn't happen by accident.
Context
- Role
- Head of Design
- Team
- 5 designers, 2 researchers; design system work led by Jonathan with close front-end partnership
Approach
Atomic Design Framework: starting from foundational tokens and base elements, building up through components, patterns, and templates. Audited existing Storybook components before writing anything new.
Design system
Built from scratch; no prior system existed
Without a system, every decision gets made twice.
Stavvy was growing fast across multiple products: origination, servicing, eSign, eVault, eRegistry. Without a shared design system, design decisions were being made in isolation. Components diverged. Patterns contradicted each other. Accessibility criteria were inconsistently applied. And every time a front-end engineer built a new surface, they were making design decisions that should have already been made.
The deeper problem: there was no shared language between design and engineering. Designers worked in Figma, engineers worked in Storybook, and the gap between them was filled with conversations, screenshots, and approximations. A design system doesn't just create consistency; it creates a shared source of truth.
Getting leadership to see it that way was the first and hardest challenge.
Earn the investment before spending it.
The first step wasn't design work; it was alignment work. I built the case for the design system investment with leadership, articulating the cost of not having one: duplicated effort, inconsistent experiences, slower onboarding for new designers and engineers, accessibility gaps accumulating across every product surface.
The case worked. With alignment secured, we had the resources and prioritization to do the work properly, not as a side project, but as a real program with engineering partnership built in from the start.
Audit before you build
We started with a complete audit of components in Storybook that front-end engineers were already using. Building on what existed, rather than replacing it wholesale, made adoption dramatically easier.
Atomic foundations first
Following the Atomic Design Framework, we started at the bottom: color tokens, typography scales, spacing systems, elevation. Every component built on these foundations, which meant changes propagated consistently across the entire system.
Accessibility is not optional
Accessibility criteria were defined as part of every component specification, not added at the end. Every component shipped with documented keyboard behavior, ARIA patterns, color contrast compliance, and focus management requirements.
Build with engineers, not for them
Close partnership with front-end from the start. Engineers were involved in component definition, not just component consumption. That partnership is why adoption happened easily: the system reflected how engineering actually worked.
From tokens to templates.
The system was built from the ground up following Atomic Design, starting with foundational design decisions and building toward full product templates. Every level of the hierarchy informed the next.
Foundation: tokens and base elements
The decisions that everything else inherits.
The foundation layer defined the design language at its most atomic level: color palettes and semantic tokens, typography scales and font pairings, spacing systems, elevation and shadow values, border radii, and motion curves. These weren't just visual decisions; they were contracts between design and engineering that let both sides work from the same values without constant negotiation.
Token architecture
Color, typography, and spacing defined as design tokens: semantic values that described intent rather than appearance. "Color.action.primary" rather than a hex code. This meant product-wide updates could be made at the token level and propagate automatically.
Components
Defined once. Used everywhere. Accessible by default.
With foundations in place, we built the component library: every component defined through four lenses: visual design, behavior and interaction, properties and variants, and accessibility criteria.
The audit of existing Storybook components gave us a clear starting point. We weren't inventing from scratch; we were systematizing what was already working and correcting what wasn't. Components ranged from base atoms like buttons, inputs, and badges, through molecules like form groups and cards, up to more complex organisms like data tables, modals, and navigation patterns.
Component documentation
Each component shipped with complete documentation: visual specs, interaction states, property definitions, do/don't guidance, and accessibility requirements. Documentation wasn't an afterthought; it was part of the definition of done.
Accessibility as a first-class requirement
Every component was designed and documented with accessibility as a core requirement: keyboard navigation, focus management, ARIA labeling, color contrast compliance. We evangelized this work across the organization, because accessible components aren't just the right thing to do; they make better products for everyone.
Patterns and templates
The system at work in the real product.
Above the component level, the system defined patterns, repeated solutions to repeated problems, and templates that showed how components and patterns combined to form full product surfaces. These higher-level artifacts are where a design system becomes genuinely useful to product designers: not just a library to pull from, but a set of pre-solved problems that let them focus on what's actually new.
Pattern library
Form patterns, data display patterns, empty states, error handling, loading states, navigation patterns: solutions defined once and available to any designer working on any product surface.
Adoption and front-end partnership
A design system nobody uses is just a Figma file.
The test of any design system is adoption, and adoption at Stavvy happened easily. That wasn't luck. It was the result of building the system in close partnership with front-end engineers from the start, rather than handing them something finished and expecting them to implement it.
Engineers were involved in component definition. The system reflected how engineering actually built things. When it shipped, it didn't feel foreign; it felt like a formalization of decisions they'd already been making, with the gaps filled in and the inconsistencies resolved.
That partnership model is the thing I'd take to any future design system work.
What building a design system teaches you about design leadership.
The design system work at Stavvy taught me that the most important design leadership skill isn't craft; it's the ability to make the value of craft legible to people who aren't designers. Leadership understood shipping. I had to translate "design system investment" into terms that connected to what they cared about: faster shipping, less rework, more consistent quality, lower engineering cost over time.
Getting that alignment was harder than any component I designed. And it made everything that followed possible.
The accessibility thread is the one I'm most proud of. It's easy to treat accessibility as a compliance checkbox, something you do because you have to. The work we did at Stavvy treated it as a design quality standard, something you do because it makes the product better for everyone. Evangelizing that perspective across the organization was part of the job, and it stuck.
Close partnership with front-end engineers is the other thing I'd emphasize. The best design systems aren't design artifacts that engineering implements. They're shared artifacts that design and engineering maintain together. The system's easy adoption was a direct result of that philosophy being in place from day one.