building a design system

starting from scratch ain't easy! but here's how I did it.

problem

How can I build a design system using an existing brand and minimal already-built components that serves the needs for both designers and developers?

Overview

Upon joining ZoomInfo in 2022, there was no design system present for the core website and brand. Due to inconsistent designs, a lack of components, and no documentation on how components should function there was confusion between teams about what was "correct" resulting in extended timelines and increased frustration.

Discovery

I audited past and present projects from our team, looked over how the few components that already existed were built, and inspected our site (both the CMS and the live pages) to see how designs matched up from our team's vision to development's implementation. What I found was:

Designs were inconsistent across different team member's projects — not glaringly so, but enough to cause concern

Components weren't being built to accurately represent how they functioned in our CMS

There were multiple components that functioned the same and had the same fields available. but were separate components based on their "main feature"

There was inconsistent naming across components between the design and development teams

Key components were missing from the design system

What our team was building in Figma wasn't being accurately developed on our site, leading to changes in UX that the design team did not anticipate

Research

I viewed as many public design systems as I could, ranging from well-known favorites to smaller brands I found on designsystemsforfigma.com, I analyzed the best and worst parts of each of them, including organization, naming conventions, and build.

In tandem, I set up meetings with our web designers, our developers, and my counterpart on the product team to hear what was most important to them in a design system and determined the following:

Components needed to be properly labeled and easy to find

Documentation needed to accurately represent functionality both on the live site and in the CMS

Best organization practices looked different for web designers and developers

Guildelines needed to be set and used across both teams

Initial Implementation

In my first go at building a design system, I chose to separate our Figma library into two sections: Components (i.e. buttons, text links, cards, etc.) and Patterns (i.e. heroes, banners, and templates). Based on the problems I had initially heard from designers and developers it seemed like this execution was the correct solution, but slowly the feedback from both teams started rolling in:

For developers, seeing all of the components at once despite being organized within their assigned pages was overwhelming

For designers, some components were built too atomically to the point that it made editing them difficult and confusing

For both teams, it felt like there were unnecessary components built

There were still guidelines missing that both teams felt documenting would better align the teams

Naming conventions were still getting mixed up between the teams

Current Implementation

In a way, this feedback came at a perfect time as we were about to start a brand refresh, giving me the opportunity to take a second look at our components to see what we wanted to keep, change, and deprecate.

I made the choice to work more closely with the development team this go-around and we decided on updating the system to a truly component-based, atomic system that allowed designers to have flexibility within the CMS to be creative while still keeping the code clean and repeatable for developers. During this process:

I placed components on their own pages, allowing for a less overwhelming experience and leaving more room for detailed documentation

I merged any components that felt too similar to justify being separate components and guided the development team on how we wanted the components to merge

I worked with a development team membrer to solidify a naming convention that worked for both teams

I led multiple demos on how to build and use more complex components so our designers were fully educated

Currently, I'm working with the development team to enhance our design system even further by applying variables to our Figma Design System and writing out further dev-based documentation that isn't already supported in Figma Dev Mode.

ResultS & The Future

Through all of the research and endless hours spent overthinking the best possible way to create a design system I realized what was most important was not building the most innovative system to grace the design world, but building a system that allowed my teams to do their jobs efficiently, creatively, and happily. As a result of the current design system:

Less time is spent creating wireframes and new designs

Development handoff meetings are quicker, and there are fewer QA questions post development

The live site reflects designs more accurately, both in look and function

Less time is spent answering questions and more time is spent coming up with the next great design

While I'd love to call this a "final" implementation, the design world is always changing with fast trends, better research, and new program updates and I'll be updating this design system right along with them!

view more projects