Design systems

What they are, why your need one (or not) and how they can be of use

Carmen Martínez-Freile
Mar 6 · 10 min read
Photo by Balázs Kétyi on Unsplash

Design systems have recently increased in popularity in the design world. These days there are so many terms in use, terms such as ‘pattern library’ or ‘component library’, ‘style guide’ or ‘design system’. I’ve heard them being exchanged for one another or used alongside each other.

Personally, I think sometimes the design industry gives too much importance to the differentiation of these three terms. However, there is a specific definition for each term and it’s useful knowing what each entails, not so much for terminology’s sake but to know how to make the most out of each and understand what you might need.

In this blog post I will define these terms and outline how a design system might be beneficial, as well as some of the drawbacks. I will also talk about how important it is to create a system that is customised to your project.

Before we start, it is important to understand that the most important thing when creating a design system is for your team to be on the same page. There might be some designers that understand something slightly different for style guide, pattern library or design system. This is not unusual as these terms often overlap. However, the key takeaway is that everyone on the team should speak the same design language by having terminology that everyone agrees on and uses.

Style guide

How you create the style guide and what you include in it might also be dependent on various factors such as:

  • The dev hand-off tool you use (eg. Zeplin, DSM, Avocode, etc). All tools have their unique features as well as limitations and each allows you to organise information slightly differently (I will talk about dev hand-off platforms later on this post).
  • The project’s needs: Every project is different and therefore the content of the style guide can vary. Some projects might need special attention to typographic rules while they might not have many icons and therefore a section addressing icon style might not be needed.

Pattern library

To better understand how a pattern libraries are built it’s worth looking into ‘atomic design’, a term conceived by Brad Frost. Atomic design makes a parallel between chemistry and design. The concept is based around the idea that an interface is composed of very small components (atoms) which then get together to form bigger, slightly more complex ones (molecules) which then combine to create what could be understood as a more distinct section of the interface (organisms). These organisms then combine to create templates which then develop into specific pages.

Atomic design by Brad Frost

Pattern library in relation to the style guide

Design system

Benefits of a design system

For customers (users of the site or app):

  • The learning curve is reduced: Reducing the number of representations for a certain action or element within the interface avoids the user having to learn new representations for each action or task they undertake.
  • Avoiding confusion: By striving for a consistent user interface that follows standards and conventions we are making the users’ lives easier. Users come into a website with their own set of expectations based on what they have learnt elsewhere. We shouldn’t reinvent the wheel if there is no need as this will challenge their expectations, which could lead to confusion.
  • A faster experience: By making use of components in the pattern library the user will also have a faster, leaner experience. This is because fewer and more consistent components mean cleaner code, which in turn means better performance.

For the team:

  • Respecting the brand guidelines (designers): By having a design system, we can ensure all components follow certain rules dictated by the style guide.
  • Maintaining consistency (designers): Having a design system helps us keep our designs consistent which in turn means leaner and faster design as we don’t have to think of a new design for each new element.
  • Documentation for future designs (designers): When new designs are needed, with a design system we have somewhere to start.
  • Less code (developers)
  • Independence for developers: By having a design system we can avoid potential blockers where the dev team might be waiting for a specific person to provide designs and documentation. All components are available to the whole team.
  • Documentation for developers: Good documentation will help the dev team understand when and how to use each component.

For the business owner or organisation:

  • Keep costs down: By reusing components and therefore functionality.
  • Happier users and potential to attract new ones: By having a design system your product will be more consistent which would translate in better usability, leading to happier users.
  • Longevity: Having a design system will also mean a longer life span for the website as new elements are easier to create and tweaks are easier to implement.

Disadvantages of having a design system

  • Design systems can become rigid if not revised with time.
  • When a design system has been in place for a while it can lead to a decrease in reflection, exploration and new creative ideas.
  • It can become very time consuming to maintain a design system. Every change must be accounted for and ultimately this is manual work. Having a design system that is always up to date is especially difficult for products which are constantly being iterated.

One could think that a design system might be restricting. Although this can be true, in my experience those restrictions have pushed me to be more creative and improve the usability of my work. The truth is, often, the statement of wanting to have complete freedom and creativity is an excuse that we put to ourselves to justify our unwillingness to follow a set of rules. It is sometimes easier to design without rules. However, when you put a set of rules in place and stick to them, the overall outcome breathes quality, harmony, and a sense of solidness that a design without restrictions wouldn’t.

I have learnt to not look at rules as restrictions, but understand them as guides. When you don’t have any rules you get to a point where you are frustrated because nothing fits together perfectly, and creating a new element to go with the whole becomes an unnecessary challenge. By creating a system, those restrictions put my design work on a more focused path and give my creativity a reasonable framework to express itself without putting the usability of the product at stake.

Learn the rules like a pro, so you can break them like an artist — Pablo Picasso

Do you need a design system?

It might be that you need a simple design system. Perhaps, a style guide with colour and typography and a couple components in your pattern library will be more than enough to have that useful documentation and guidance.

This brings me to the next section which is making a design system that works for you and your project’s needs.

A design system that works for you

For instance a content-heavy website might need more attention on typography use, while a marketing website might need more guidance on use of colour and layout. Your design system should adapt accordingly, giving extra support in the areas that need that extra documentation.

When we talk about the transition between UI and development, it’s worth mentioning the gap in communication that can exist between these two stages of the process. This gap can be frustrating for both designers and developers alike, and can lead to issues with the product further down the line.

Having a design system can be a huge help to bridge this gap. It will help organise things and provide good documentation for the dev team to understand the underlying rules of the design. However, even with the most comprehensive design system and hand-off instructions, it is important to work together from the beginning to the end of the project, and even after the design has been implemented to ensure there is no room for interpretation.

Something that has helped me a lot when building design systems is trying to identify common problems within this gap and producing specific documentation to address them. It’s all about customising your design system. For example, as a designer I often see a lot of mistakes being made regarding spacing (spacing in between text styles, visual elements, padding etc.). To address this I provide extra documentation for this area.

Design system and dev hand-off platforms

For example Zeplin has a great way of organising components but in my opinion it lacks a space for describing certain rules and elements (ie. you can’t rearrange text styles on the type scale and you cannot add descriptions to go with these). To help with this, what I do is create a separate artboard on Sketch and put in there the set of rules I need to communicate. I will then upload that artboard as another page and make a section for it called ‘Guidance’. These ‘sticker sheet’ artboards can contain anything you need to explain or even function as a summary of what could otherwise be appreciated in the components area (ie. an overview of the states of interactive elements).


It is key that you make your design system work for the project in hand, and that you look for ways to make it as complete and helpful as possible. It is also very important that the whole team understands and agrees on the same terminology within the design system, as well as the terminology of each of its components.


User experience design studio based in Oxford.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade