Starting a Design System

I've been building Design Systems now for a little over 6 years! I've built them at varying scales, from small startups to large corporations. I won't go into what a Design System is, or too deep on how it can benefit your organization - there are a ton of really great articles and videos online about that already. Instead, I'd like to dive into how do you get buy-in to build one within your organization and what are some items you should be thinking about early on in your Design System process. After this article, I plan on writing more about specifics, but I wanted this to be a high-level overview of how to kick things off internally. NOTE: This is from my personal experience as a frontend developer working on Design Systems, your mileage may vary -- please don't take this as gospel!

Get Management on Board

Pitching a Design System can be very difficult. The main pitch I've given in favor of Design Systems is UI/UX consistency across product(s), providing web accessible components so developers don't need to know the ins-and-outs of web accessibility, and speeding up designers and developers when it comes to building new features and products by providing building blocks. To me, these pieces are the primary drivers of Design Systems within organizations. Upper management normally cares about two things when it comes to UI/UX departments:

  1. Are customers/shareholders happy about the current UI/UX experience?
  2. How can we ship more value to our customers faster?

Luckily, creating a Design System will help both of these cases.

Building a Design System is a long-term investment, where it starts out slow, but over time it begins paying dividends. The benefits will not appear right away - it takes some time to get going, especially if you are creating a Design System from an existing product. This is all completely normal! Don't sweat it!

If you find you're having issues pitching a Design System and the benefits, I recommend sharing the "Measuring the value of Design Systems" study. Here's the TL;DR:

We found that when participants had access to a Design System they completed their objective 34% faster than without a Design System.

…if every task they’re working on has a relevant Design System, they are able to do 34% more design work in that 140 hours, giving them 212 design hours. That’s equivalent to adding another 3.5 designers to the team each week!

Several participants commented that they felt more confident in their final design when they had access to the Design System because they knew it was consistent with the product.

Pretty crazy, right? This study is only from the design side as well! Unfortunately I'm not finding any similar studies from an engineering perspective, but I can tell you from experience that building a feature with existing building blocks versus having to build them all myself has saved me a ton of time! Finding statistics like above will hopefully help your pitch on why a Design System is important and what it can do for your organization. Once you have management on board, you may not want to do this all alone! If you're an engineer, you'll want a design counterpart and vice versa.

Dedicated Focus versus Side Project

Depending on your situation, you may be hiring to build a new Design System team, pulling folks from the existing organization, or working on the Design System as a side project because you think it's the right thing to do. Any of these options are completely valid! Every organization is different. From experience, typically having dedicated folks work on the Design System is the best for long term support and growth. Sometimes, the project may start as something on the side, but as you begin shipping value to customers (in this case, customers can be end users and internal folks consuming your Design System), people will start to notice and it may be easier to get additional headcount and/or transition to working on it full-time.

Even if your request to build a Design System formally gets denied, you can still build one if your engineering and design teams are aligned. Following atomic design principles applies to both design and development. One of the biggest mistakes engineering teams make is not following these patterns. Breaking components down into atomic pieces makes them easier to test, easier to reuse throughout applications and packages, and helps you write better components by ensuring one component is not handling too much business logic that leads to brittle code. There is an argument about premature abstractions and abstractions in general, but I'm mostly talking about building foundational, presentational components as building blocks. By following atomic design patterns with components, your frontend code will be much easier to maintain and reason about.

Next Up

In summary, I hope this was a semi-helpful read. I'd like to continue writing about building Design Systems and have a few ideas in mind for next time: