How we built a design system in 3 months

This content was originally shared as a Front Conference workshop taught by Lindsey Martin and me in the fall of 2019. This content can also be viewed as an interactive workbook here.

This title isn’t an exaggeration, but can be somewhat misleading. First, we did have an existing (though simple) design system. Second, though we outlined and documented our design system in just three months, there is always more work to do. The lifespan of a design system is the lifespan of the team.

This wasn’t our first rodeo, though. In the five years I’ve been at Lucid I’ve gone through at least five iterations of component systems using some combination of Illustrator, Sketch, Zeplin, Figma, and other in-house tools we created for ourselves. Each time we learned a little more and our system got a little better. Our system even became strong enough to convince engineering of the need for dedicated developers to support the design system.

Most importantly, we did all this on borrowed time. We didn’t have a single dedicated design systems designer. Instead, each member of our 8-person team put in as much time as they could spare each week to keep the effort moving. (At the time of writing, however, we are growing our first ever design systems team!)

Our most recent implementation (during summer of 2019) is by far the most detailed and most robust design system we’ve ever created, and we’d like to share how we created it in just three months.

What we made

We designed a system of classifications to better organize our patterns. It included pattern groupings, state organization, guides for writing documentation, and consistent specs across components.

We store our pattern symbols in Figma using their slash (/) hierarchy notation to stay organized.

Each of the symbols and states in our Figma symbol library correlates to a component in our design system in Zeroheight.

Each of those component entries has a “Code” tab with an interactive playground (built in-house at Lucid, but can be accomplished using other tools like Storybook).

By following this guide (originally published as a workshop) you will be able to create a system similar to the one we’ve created here.

Step 1: Auditing your system

The first step is to make an audit of your existing patterns and components. You probably have more to start with than you realize. The goal of this step is to identify patterns that work, pattern inconsistencies, and gaps in the state of your design system.

Advice

• Go broad: include things you’re not even sure should be in your design system!
• Design systems crumble without strong foundational principles (grid, color, type, etc.). Be sure to write these down!
• Use whatever methods are quickest (we used a spreadsheet, but had participants use sticky notes during the workshop).
• If your company doesn’t have any design system, start with a list of common elements or walk through your experience and document elements you’re currently using.
• If you’re attempting to define a design system before starting a project, trying to sketch or imagine what that experience might look like and list the common elements you find.

Activity

• Using sticky notes (or another tool of choice, like a spreadsheet), generate a list of patterns to include in your design system.
• You might consider using different colors to denote existing, incomplete, or missing patterns.

Step 2: Defining a taxonomy

Once you’ve made your audit, you’ll need to define a classification scheme. This is important for two reasons: it will allow you to find information in your design system (navigation), and it will help describe relationships between elements in your design system (buckets).

Advice

• Consider your users! How might people want to browse and search your design system?
• Taxonomies that work for one company may not work for another (see above). Don’t worry about doing it the “right” way. Make it useful.
• Starting with a framework (like Atomic Design) might help.

Activity

Start clustering your sticky notes into common groups. Give those groups a title, such as “Forms,” “Communication,” or “Foundations.”

Step 3: Create a Pattern Template

Determine the details you would like to describe about each pattern with specificity. Defining this early on will allow you to move quickly later.

Examples include:

• Color
• Layout
• States
• Classes
• Variations
• Motion

Advice

• Don’t be too rigid here, it’s likely to change over time.
• Try to pick one pattern and write about it. Write down “what’s important to know about a dropdown” vs “button”.
• Think about where you’ve seen confusion on your team and make that a section.
• What things could change about this pattern (size, color, etc.)?
• Reference your design principles (grid, layout, type, etc.) and determine how these patterns interact with those.

Activity

Write down the different sections you would like to include in the detailed view of each pattern.

For reference, here is our template:

• Dimensions & Spacing
• Rules (usage guidelines)
• States
• Variations & Limitations

Step 4: Share the workload

The work required to generate this much information can sometimes be too much for one individual with competing responsibilities, so have others help you. Sharing the work also helps others buy into and feel invested in the design system. This step involves designing a simple process so others can follow along.

You might not need to do this if you have a dedicated design systems team, or you’re the only designer at your company. Otherwise… you should probably do this.

Advice

Think about your team and how involved you would like to be in the specific details of each pattern. When should they check back in with the team? How often? What steps should they take?

Some quick math will tell you approximately when you could complete your design system:

(30 patterns / 6 designers) x 2 weeks per pattern = 10 weeks

Activity

• Choose your favorite project management tool: Asana, Trello, etc. (We used a spreadsheet but we don’t recommend it).
• Define a process to follow (Discovery? Check-in? Approval? Redesign?).
• Assign work to others, help them follow the process.

Step 5: Holding Reviews

Patterns should be reviewed by the team (or small group of individuals) before being canonized in the official design system. This ensures a consistent voice, avoids conflicting guidelines and patterns, and creates accountability to timelines.

Advice

• This was one of the hardest parts of the whole process, but don’t give up now!
• Only designers invested in approving this specific pattern need to attend. Otherwise, everyone in the room may feel the need to share their opinion (whether positive or negative) which will make it harder to filter out the most important feedback.
• Designers should speak with proposals (“I propose that we get rid of this component altogether, and unify all these patterns into one”) instead of context (“Well, I started by exploring how Material Design does it…”).
• Any larger conversations should be moved outside the approval meeting.
• …We bought a gavel. For real.

Activity

Imagine you have 3 proposals in 30 minutes. How will you spend your time? What do you expect from participants? Here’s a helpful outline one of our designers, Aditya, made:

Step 6: Implementation

Find tool(s) that can support your design system documentation into the future.

Advice

• Choosing a tool with “master symbol” capabilities will assist your design team with change management. Rolling out changes to sizes, colors, and styles is more easily accomplished with symbols.
• Find tools that allow documentation and symbols to either live side-by-side, or in sync. We accomplish this using Figma and Zeroheight.

Activity

• Establish a single source of truth for design and frontend development guidelines.
• Guidelines should live side-by-side with design patterns.

Side Note: Finding Engineering Champions

A design system is only as strong as the code behind it. While your design team may be able to plan, organize, and design a system, it will eventually fail unless it is similarly represented in your codebase.

Start building your Design System coalition now (designers, engineers, leadership, etc.) and encouraging early resourcing discussions with leadership. Present your case in terms of customer value, design team value, and engineering value.

We started this effort by meeting early with product and engineering leadership to discuss:

• The customer experience and how consistent, high quality UI contributes to trust, ease of use, and brand perception.
• Problems with our products, and how a design system could solve them
• Ways a design system could increase velocity, quality, and reliability of our engineering processes

We gradually gained more traction, which led us to hiring our first Design Systems Engineer (and at the time of writing, we have two!). She participates in planning, auditing, reviewing, and (obviously) implementing new changes to the design system. She thinks about the future of the design system and how to create a scalable architecture that will continue to serve us in the future.

During our early efforts we intentionally checked in with leadership to give reports and readouts of our progress, the effectiveness of our efforts, and our future plans. The design systems team continues to report on proper component usage and updated guidelines. Keeping leadership in tune with our efforts helped us protect our resources.

It’s worth noting that this wasn’t the first time we approached product and engineering leadership about the need for design system resources. Due to staffing, strategy, and other constraints, it took a few tries before we gained enough momentum to form a dedicated team. Admittedly, in our previous efforts we failed to link the design system back to business and how it would help anyone other than the design team. Broadening our perspective and sharing a larger vision seem to do the trick.

Step ∞: Maintenance

The steps outlined above are to help you start a design system (because it’s never finished). Once you have cataloged, stable components, it’s time to design a system to help them evolve. Below is a diagram outlining how the UX and UX Engineering teams collaborate to track design and development changes for design system patterns.

Inevitably your design system will experience inconsistency and necessary evolution. Defining a maintenance strategy prevents your team from having to perform this entire exercise year over year, and instead allows your team to protect the basic foundations while allowing for iterative improvements. Just as your products and services evolve, so will your design system.

This workshop was originally hosted with a workbook. If you’d like to use the workbook yourself, you can download it here.