Photo by Toa Heftiba on Unsplash

Starting a design system

Questions you should answer before you get started

This past year my wife and I went through the process of finding a new home. During the many months we spent looking for a home, we discussed building a house. We were frustrated by our inability to find what we were looking for over many months. Maybe building a new home was the way to go.

We had never built a house before, so we were unsure about the process or costs involved. Our first step was to sit down with a builder. Through that discussion we learned the benefits of building a new home, but also the higher costs associated with it. We could get the house we wanted, but we would pay for it up front versus potentially in stages with a pre-existing home.

My wife and I were weighing how we might allocate our resources among other competing concerns we had in life. The same is true of design systems.

A common question I’ve received from designers as they’re starting a design system is where do they start. Do they build something from scratch, use a pre-existing system (e.g. Primer, Tachyons, Tailwind), or start with what you have? Essentially we have the same decision as the one I had to make earlier: do I build a custom house, purchase a pre-fabricated house, or remodel an existing home?

And the answer, like many things, is… it depends.

Dan Mall, speaking about design systems, has this great quote:

[A lot of designer’s] first inclination as to what a design system is is a UI kit, and that’s not what a design system is. That might be part of a design system, but … [it’s something] only designers can use. Part of a good design system is that it’s a tool that everyone on the team can use. (Emphasis mine)

A good design system works for everyone. Designers shouldn’t be building design systems independent of other teams—instead they should be gaining consensus across teams.

So if you’re starting a design system, consider the following items with your team—just like when looking for a new home.

What’s your current state—and does everyone agree?

If you’re looking for a new place, it’s probably because there’s something about the your current place doesn’t meet your needs anymore. Maybe you’re moving to a new location, or your current place is too small or too far away. Whatever your reasons are, you’ve found deficiencies with your current place.

It’s the same thing with a design system. In order to start working on one, everyone needs to agree on the current state of deficiencies. One of the biggest things that will slow down your ability to create and implement a design system will be that not everyone on your team agrees that there’s a problem in the first place.

A great way to start gaining this agreement is to do a pattern and component inventory. Identify people across multiple teams who could help. Have everyone take screenshots throughout the product, gather those screenshots into a shared document, and organize them with your team.

This inventory is helpful for a few reasons:

1. It helps you understand the product’s current state. Before you start a new project, you should know what you’re up against. Doing this exercise allows you to walk into the project fully understanding the problem in front of you.
2. It encourages you while building your design system. Just like when finding a new home, you forget somedays the reason you’re going through all the stress, anxiety, and frustration associated with this process. Having a document like this allows you to be reminded of the problems you’re trying to solve.
3. It helps others understand why you need a design system. Explaining to your boss that you want to start a new project isn’t easy. They have other concerns weighing on them. It’s your job to help them understand how a project like this will help the team and your customers, both immediately and in the long-term. A document like this provides an artifact that illustrates the problems that exist today quickly.

At Stack Overflow, we gathered our screenshot inventory into a documentation site for future reference.

When I started building a design system at Stack Overflow, it wasn’t until we did an inventory like this did people understand the time and effort we were wasting, as well as the poor experiences we were providing to our users. Once people saw these deficiencies, they supported the project.

So before you jump into your project, take the time to find out what your current state is.

What will it cost to get started—and where should you start?

Everyone agrees that you need a design system. Great! But how much time and effort is your team willing to contribute toward a system?

You may want to move to a new place, but before you start looking you need to make sure you can afford it. The same is true of design system projects. Some teams will be able to fully support an effort like this right away, which is great! However other teams will agree a design system is needed, but they aren’t able to dedicate much to the project initially.

At Stack Overflow, people understood we needed a design system, but they weren’t sure about making a big commitment. How much would that cost? How big of a project are we talking about? How much time will it take to implement? Will this slow down the team as they learn a new system?

If you find yourself being asked the same questions, here are a few things you could do to help make a case for a design system.

1. Identify what’s most important for your team. For some teams, maybe a HTML/CSS pattern library is the best place to start. For others it’s a copy style guide, UX patterns, or motion library. You don’t have the time to do it all. Instead focus your efforts on your area of biggest need.
2. Keep your scope limited at first. At Stack Overflow, our initial focus was a pattern library composed of utility classes (padding, margins, grid system, typography, colors, etc), buttons, and forms. That’s it. Eventually we added other items, but it was enough to get us started and show the power of the system.
3. Set deadlines—and be accountable to them. It’s easy to get excited working on a new project, but then the weekend comes and the project gets forgotten among the more pressing project needs the following week. One way to make sure that doesn’t happen is by setting project deadlines and holding yourself accountable by sharing those goals with others.
4. Keep an open line of communication with your team. As you start to implement your system, ask others for feedback. What’s confusing? Where could the documentation be better? How could the system support them better? Figure out how you can support the team by regularly gathering feedback.

What could we do today—new builds versus remodels?

At the end of the day, what people care about is how will this system help them do their job better. Now that your team understands the effort involved and resources available, you can determine what you can do today. Do you build a new house or remodel one? Do you build a system unique to your team or modify one to meet your needs?

There’s no wrong answer here. It depends on your team needs, time, and ability to adjust to new systems. No matter your approach, here are few tips to consider when you start the process:

1. Stand up your design system alongside your current product — don’t try replacing it all at once. We tried multiple times at Stack Overflow to replace existing styles with new styles. And time and time again we would find undocumented implementations that would end up breaking when new systems were implemented. Not only is this frustrating, but it looks bad for your team. Instead stand up a new system alongside your current system. This allows you to either cut over to a new version immediately or slowly move older items over time.
2. Figure out what’s in your Design System MVP. Design systems should meet your team’s needs. Just because something is in Lightning, Polaris, or Solid doesn’t mean you need it. Those teams built those systems for their teams. Once you know what your team needs the most, figure out what items within that area you need to get started started.
3. Documentation is the life-blood of a design system. If you don’t document it, it doesn’t exist. You can’t expect people to use a system if it isn’t documented well. Writing documentation is difficult. It takes practice. But the payoff is that you’re enabling others to quickly understand how to use a tool to help solve their problem without you being around.

Starting a design system can be an exciting time. Like looking for a new place, it seems only your imagination is the limit to what your design system could do for your team. Yet every great system out there didn’t happen overnight. Instead it took diligent, methodical work over time, building on previous efforts to get where they are today.

Focus on what your team needs first. Work from there. Eventually you’ll find that you’ve built an amazing home in the process.