Design systems

What is a design system?

There is no single objective definition to a design system, and the term can often be used interchangeably with its possible parts, like style guides or component libraries. 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.

The design system is the fabric that ties together all the individual pieces. It bridges the gaps between disciplines and instructs the users (designers, developers, etc.) on how to use the styles, blocks, and whatever is included in the system – to build products that are more than just the sum of their parts.

An average design system usually consists of a style guide, component library, and various design & development documentation. Design systems come in all shapes and sizes, so the contents may vary significantly. It all depends on the product or service it’s built for. For good references on design systems, big and small, you can examine Elizabet Alli’s article “10 great design systems and how to learn (and steal) from them”Opens in a new tab.

What features does a design system have?

One way to point out design systems’ three key aspects is the following by our designer Niklas Drugge:

1. It’s a single source of truth. When adopting a design system, it should, from that moment onwards, be the 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.

It’s also important to understand that there is no such thing as a finished design system. When a design system goes static, it either means it’s going to be outdated very soon or that the product it was built for is no longer in development.

In many ways, a design system is also a product on its own. It has its own users, the designers, developers, and everyone else, with their unique needs. It requires dedicated workers and managed processes to stay relevant and up to date.

Why we use design systems

When a design system is harnessed right, it can increase efficiency and scalability, and enhance consistency. These participate in making the work faster, improving the overall user experience, improving team collaboration, and reducing costs.

Increased 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 allows the designers and developers to change the focus from constantly reinventing the wheel (building UI) into solving bigger and more meaningful problems. For example, in a test conducted by FigmaOpens in a new tab, they measured that designers with access to a ready design system completed the objective 34% faster than the ones without.

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

Enhanced consistency

Every designer and developer is a unique human being. All of us have our own personal best practices and working habits, which means that some minor inconsistencies are always going to seep into the final product. The bigger the product, the more inconsistencies there will be. For example, when HubSpot audited their service, 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.

Better scalability

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

Who benefits from a design system?

The benefits of a design system sound tempting, but it is by no means a requirement for a successful product or service. Also, using one does not necessarily make your product any more successful than it already is or isn’t. So, who could need a design system?

Large teams

A key to success is communication, and this is where a design system is a great help. A small team working tightly together probably doesn’t benefit from the extra work put in documentation, if they share all the needed information in daily meetings, coffee breaks, etc. A smaller team usually survives well with smaller fixes, like creating a component library or a style guide, instead of building a heavy design system.

Teams with active product development

Design systems are especially effective for continuously evolving products, where there’s constant development, for the added efficiency to start paying off. Setting up the system, designing and developing all the building blocks and styles takes a lot of work. If there aren't that many places where to apply those blocks it doesn’t make sense to invest so much time into creating them in the first place.

Teams with sufficient resources

The design system also needs to constantly evolve along with the service, the technologies used, and the company’s vision. This requires overhead. 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 for raising it past the point of a simple icon library or style guide, into something meaningful and useful. And, if the resources are not extensive, sometimes those need to be guided to more urgent tasks, like launching the product.

Create your own type of design system

Starting a design system can feel like a daunting task to do. There are as many types of design systems as there are companies that use them. Hence, don’t feel pressured to copy someone else’s model like it would be the only true way of creating a design system. Starting out one 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 out 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.

One way to evaluate your current situation, and plan where to head in the future, is the Design system maturity modelOpens in a new tab by Marcelo Somers and John Gully. 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.