When should you use a design system?

I was recently working on a project where I was tasked to provide an overview of design systems for a customer. To prepare the presentation, I pored over dozens of articles on the subject, both for and against design systems, trying to form an objective view on what design systems are and if you should be using one.

So, based on the task I had, we will here gain some tools to better understand and evaluate whether a design system could benefit your service. If the term ‘design system’ is new to you, you might want to check our article Creating better experiences with design systems first.

Disclaimer: We focus on design systems used for digital products and services in user interface (UI) and frontend-related concepts. The term product and service used in this article refer to an online digital service or product, i.e., website, mobile application, or similar implementation.

A quick recap: this is a design system

First of all, there does not exist a single objective definition of what a design system is. That also explains why it’s so often mistaken and used interchangeably with, for example, style guides or component libraries. However, that is not the whole truth.

A design system is much more than just a style guide or a component library. In fact, these are often parts of a design system. The style guide defines abstract styles like colors, fonts, icons, etc. On the other hand, the component library defines the building blocks of which the product is built. But the styles and blocks by themselves are not enough. Emmet Connoly summarized this well in his article “The full stack design system”opens-in-a-new-tab:

“Your product is more than just a pile of reusable UI elements. It has structure and meaning. It’s not a generic web page, it’s the embodiment of a system of concepts.”

And to deliver that structure and meaning, you’re going to need good instructions and a mutual understanding of what’s in the core of the service. That is where the design system steps in.

Defining and dividing the design system

The best definition I’ve come across is one made by Audrey Hacq in her article “Everything you need to know about Design Systems”opens-in-a-new-tab:

“A Design System is the single source of truth which groups all the elements that will allow the teams to design, realize and develop a product.”

I like this definition as it’s flexible enough, enabling different kinds of design systems for different needs, but still crystallizes three key aspects that are the most important in my view:

1. It’s a single source of truth. When adopting a design system, it should, from that moment onwards, be the one and only source of documentation – the single source of truth. The design system can and should be updated, but nothing should ever go past the design system.
2. It contains all the elements for realizing the product. A design system should consist of everything relevant to realizing the product. That means that different products can have very different design systems – and that’s ok! If the brand book, tone of voice, etc., is not relevant in your design system, it doesn’t need to go there.
3. It’s made for and used by everyone. Even if the name can be a bit misleading, the design system is not only for designers; it is for everyone involved in building the product. That is, designers, developers, content creators, product owners, etc. Thus, all design system’s content and principles should also be agreed upon mutually by all the parties involved.

In many ways, a design system is also a product of its own. It has its users: the designers, developers, and others, with their unique needs. It requires dedicated workers and managed processes to stay relevant and up-to-date – because there is no such thing as a finished design system. When a design system goes static, it either means it will be outdated very soon or that the product it was built for is no longer in development. The design system needs to constantly evolve along with the service, the technologies used, and the company’s vision.

Benefits of a design system

The main benefits of design systems can generally be distilled into efficiency, consistency, and scalability. They, in turn, make the work faster, improve the overall user experience, improve team collaboration and reduce costs, as summarized by Marijana Vukovic in her article “Here's Why You Definitely Need a Design System.”opens-in-a-new-tab

Efficiency

Reusable UI elements, accompanied by a clear set of instructions and guidelines, mean that visualizing and realizing new or existing services is much faster. That actually allows the designers and developers to change the focus from constantly reinventing the wheel (building UI) to solve more extensive and more meaningful problems. For example, a test conducted by Figmaopens-in-a-new-tab showed that designers with access to a ready design system completed the objective 34% faster than those without.

Good and clear documentation also allows faster onboarding for new designers and developers and makes handovers smoother.

Consistency

Every designer and developer is a unique human being. We have our own personal best practices and working habits, which means that some minor inconsistencies will always seep into the final product. The bigger the product, the more inconsistencies there will be. For example, when HubSpot audited their serviceopens-in-a-new-tab, they found 100+ different shades of gray, 40 different text styles, six different primary buttons, and so on.

With reusable UI elements and instructions, the overall visual and functional consistency remains much higher throughout the entire service. The same primary button looks, feels, and functions the same way everywhere. You can take this even further by using a live component library, where the same UI code is shared between the library and live service components.

In a live component library, updates to a component are automatically shared between all of its instances across the service. Thus, you need to do the design update, bug fix, etc., only once as it’s updated everywhere. On the other hand, if you break something, it’s now broken everywhere, so this method also requires some more governed processes on managing and updating the components.

However, once you get it up and running, this method offers some big advantages for centralized accessibility or performance testing, for example. And as an added benefit, the live component library also ensures that the library components are always up to date on what’s on the live service, as they are essentially the same components.

Scalability

When you have a ready-made component library and a good set of instructions, the medium for applying the design system becomes less and less constricting. You already have the understanding of what and how the service should look and feel, so it’s easier to expand it even further or jump to entirely new platforms.

Not everyone needs a design system

Looking above at all the benefits offered by design systems, it can be said that usually, for the added efficiency to start paying off, design systems are especially effective for continuously evolving products.

Also, large services built by big teams benefit a lot from shared instructions and principles.

And even if your service does not fall into the continuously evolving or large category, you might still benefit from a design system! Generally, if you have problems adding features, inconsistencies in look and feel, and/or sharing knowledge within the team, you should consider adopting a design system.

But… how do you know if you do not need a design system?

Design systems are not always the right tools for the job. Sometimes it’s important to ask yourself, “Do you need a design system or just better documentation?” as pointed out by Bryan Bruyn in “When NOT to use a design system.”opens-in-a-new-tab

You most likely do not need a design system if you have a small team communicating well. Design systems shine in sharing and delivering information between different members and disciplines in the project team. If your team is working tightly and already shares all the needed information in daily meetings, coffee breaks, etc., there might not be any real need for the extra layer of documentation. If you have problems with consistency, a component library or a style guide might be an easier fix.

You are neither likely to need a design system if you aren’t doing that much active product development. Design systems genuinely start to pay off when you get to utilize those building blocks and styles. Setting up the system, designing and developing all the said blocks and styles takes a lot of work. But if there aren't that many places to apply those blocks, it doesn’t make sense to invest so much time into creating them in the first place.

And lastly, let’s be honest, design systems require a lot of overhead. Sometimes it might be necessary to put the resources into something more urgent, like getting your product launched. Creating and raising a design system is a big undertaking that takes a lot of time and resources before it starts to pay off. It takes commitment and dedicated builders to raise it past the point of a simple icon library or style guide into something meaningful and useful, as described by JD Jones in “9 design system traps to avoid”opens-in-a-new-tab.

Should you use a design system?

Accelerated time to market, increased consistency, improved collaboration, and reduced costs – the benefits do sound very tempting. I mean, who wouldn’t be intrigued?

But to find the truth of whether you should use a design system or not, you need to take a look at the product or service you have. Is it something where you can cash in on the benefits of a design system? Do you have enough active development to tap into that improved efficiency? Does your team benefit from the additional documentation, or are they already sharing all of that in their daily work? Is the design system a tool that will eventually break even and reduce the costs for building your product?

The benefits of a design system are great, but so is the undertaking.

Create your own truth

Starting a design system doesn’t mean you have to immediately go for something like Google Material Design, with hundreds of pages of documentation, thousands of assets, and even its own blog!

You can start small. It’s even very likely that you already have some elements of a design system in place, like style guides or some other documentation, that help you get up to speed faster.

A good tool for evaluating your current situation, and planning the future, is the Design system maturity model by Marcelo Somers and John Gullyopens-in-a-new-tab. In the maturity model, the design systems have been divided into five different stages, based on their implementation and level of adaptation, from nonexistent to fully automated and governed.

Take a look at the model to learn more of the different stages, and figure out what would suit best for your service. Also, keep in mind that the stages presented in the model are not absolute. You can create your own hybrid model that suits your needs somewhere in between the stages.

The most important thing to keep in mind is that the design system you choose to create is your design system. It should contain the tools and guidelines relevant for building your product, and it should make the lives easier for those involved in it.

Conclusion

In general, design systems are great tools. When utilized properly, they yield great results. However, I feel they are too often presented as a fast and easy solution for more efficient design and development, increased consistency, and so on. But in truth, they aren’t really that fast. Nor easy. Actually, they require quite a lot of work and commitment.

Adopting a design system should be a meaningful decision with a real purpose and understanding of how it will benefit you.

All the work for creating, setting up, and maintaining the design system will be considered extra work until the design system starts paying off. That might take some time, and until it does, you got to keep at it so all the extra work will not be in vain.