In this blog post, we will provide our definition of a design system and address some of the common misconceptions surrounding this topic. We hope to help you answer the question "Is your design system really a design system?"
Design systems have emerged as a popular solution for companies looking to improve the efficiency and consistency of their design process. However, while many organizations claim to have a design system, the reality is that they may not fully aware of what a design system actually entails.
In this blog post, we will provide our definition of a design system and address some of the common misconceptions surrounding this topic. By exploring these misconceptions, we hope to help you answer the question "Is your design system really a design system?" and provide valuable insights for optimizing your company's design workflow.
According to the Nielsen Norman Group, a Design System is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.
In other words, it’s a set of principles, tools, and components that allow to create a consistent user experience across different products. This makes it easier for designers to create high-quality products, as well as allows them to test ideas and iterate on them quickly. Additionally, Design Systems can help to speed up development time, as teams don't have to create the same components from scratch every time.
This sounds good in theory, but what does it mean concretely?
The concept of a design system is still relatively new, and there are many different interpretations of what it should include. That's why it is important for us to define our own vision of what a design system is and why you may need one.
Let’s explore buildo’s vision of a design system and see if it can help you understand why a design system is much more than just a framework for creating consistent and cohesive user experiences across multiple products. We will discuss the importance of the relationship between design and development, the governance of a DS, the concept of extensibility without lacking consistency, accessibility, and many other elements which together unlock the real power of a design system.
Before diving deep into the darkest concepts of a design system, let’s scratch the surface by talking about the so well-known Component Library as a fundamental brick of a DS. A component library is a collection of UI elements, such as buttons or form elements, used to build a consistent user experience across different products.
Components libraries are pretty commonly used, and you may already have one. So you may think: “I’m using a component library, so… I’m using a design system, right?”. Well, it depends. First, a component library is only one of the key parts of a design system.
Furthermore, in order for a component library to be effective in the context of a design system, it needs to have some key features, starting from topics more related to governance, such as the relationship between designers and developers, and ending with more concrete things like extensibility and accessibility. But let's not waste time with introductions and go deeper with the first topic, the relationship between designers and developers.
The ideal final product is achieved through a balanced collaboration between design and development teams. This requires a synchronized and synergistic approach, with each team exchanging and sharing responsibilities at different stages. Rather than a relay race where designers give the design to the developers and then they just need to code it in some ways, it's more like a side-by-side race, with designers and developers working together with the same tools and languages to create the perfect user experience and interface for the end user. Effective communication and a shared vision are essential to achieving this goal.
It is then crucial that design assets (such as a Figma or Sketch component library) and development assets (such as a React.js or Angular component library) are designed and evolved together, like different instances of the same thing.
They need to speak the same language and allow a developer using the library to find exact correspondence when implementing a design made with the design system.
This is the crucial aspect that makes the design system a productivity boost for UI delivery and ensures that visual consistency does not stop at the design mockup level.
A typical mistake is considering the design system a “designers only” resource and letting developers create their own solutions for implementing a design.
A real-world example of this scenario could be a company creating a new web app.
The design team creates high-fidelity prototypes and mockups using a tool like Figma, which includes a comprehensive set of components for the app's user interface. The design team created the prototype based on the design system document outlining the app's typography, color palette, and other design guidelines. However, the design system does not consider the technologies the developers will use to implement it.
Once the designs are finalized, the developer team is responsible for building the app. Developers don’t usually re-invent every component from scratch, so they may use a generic UI library like Material UI to speed up the development. They hope that they will be able to customize Material UI components to match the design.
However, in this scenario, the developers soon realize that Material UI components do not match the designs 1:1. They have to spend more time than expected to “bend” the component library to their needs. They also run into issues with consistency and accessibility, as the Material UI components do not follow the same guidelines and standards as the design they’re trying to implement.
As a result, the final product’s UI is not as polished or consistent as it could have been, and the development process becomes much more time-consuming and costly. This example illustrates the importance of designers and developers working together and a design system built considering the whole application development process from the beginning to the very end.
To achieve consistency, it is very important that all the UI components that make the component library are built onto common foundations. They typically include colors, a spacing system, typography, and other “low-level” concerns. Having a strong set of foundations and building components on top of it is what makes a design system a system.
One common pitfall we see in the wild is building component libraries without thinking about the foundations first. When that happens, the best-case scenario is that it is very expensive to achieve visual consistency since each new component needs to start from scratch; in the worst cases, the consistency is progressively lost as more components get added to the library.
For example, we may introduce a new component in our library that needs some padding. In a design system with a proper set of foundations, we know we can use one of the predefined values for padding (e.g., 0, 2, 4, 8, 16, 24, or 32 pixels), so we pick one, and we know it will be consistent with the other components in the library since they all share the same spacing scale; if we were to do the same without foundations, we might pick an arbitrary value (e.g., 5px) which looks fine for the single component, but it will create inconsistencies when putting different components with different spacing choices together.
As we discussed, a strong set of foundations guarantees consistency across the components of a library. Still, the real strength comes when these foundations are also exposed to design system users.
A component library generally comprises standard components such as buttons, dialogs, toggles, disclosure, etc. When you introduce it in a real use case scenario, you have specific domain requirements that you must consider. For instance, you may need to implement a particular card that is recurrent in your applications.
Your original component library needs then to be complemented with UI components specific to your product and that, for this reason, live outside your design system. A design system set of foundations is as good as it allows you to build new components that look and feel like they were first-class citizens of your design system.
For example, exposing the foundations directly allows custom components to use the same spacing system, colors, and typography as the design system components, something that is not possible if your library only exposes components to its users.
Foundations play a very important role also when it comes to accessibility. It is a complex topic that requires a lot of care across the entire product delivery. However, there are things that can be centralized and taken care of within the boundaries of a design system.
Foundations can be designed to prevent some accessibility pitfalls, for example, deliberately:
While component libraries are very useful, we can push the reach of design systems a bit further. A design system's ultimate purpose is to facilitate the creation of consistent and familiar interactions for the final user. Sometimes this is achieved via components (e.g., using the same Button component across two products). Sometimes, we need to share something more complex: think of concepts like “the way we present alerts and notifications” or “the way we structure navigation.” These are concepts that the final user expects to be consistent but that are not simple components to directly use from a library. We call these “UX patterns” or simply “patterns”.
The role of a design system is to create a central repository for these patterns and make them available across different designers and developers so that the knowledge gained from previous experience can be re-used.
Last but not least, we can have all of the above, but what good does it make if we don’t have a way to evolve it? Even the best design systems will inevitably rot if there is no team and processes to ensure it stays up to date.
Introducing a design system is ultimately not (only) creating a collection of assets but, first and foremost, a change in how we think and organize work around the delivery of digital products. In this sense, in our experience, a design system works only if it has its own processes and team.
At the very minimum, a design system should always have a designer (typically an interaction/visual designer) and a front-end developer. As we discussed previously, it is paramount that design and development proceed in tandem, or much of the benefits are lost.
In our experience, without carefully designing teams and processes around a design system, some teams end up having a shared library directly evolved on a case-by-case basis by all the product teams without central ownership.
In the long term, this leads to overall inconsistent libraries, overfitting the needs of one specific application, which tend to go stale very quickly.
You may think: “our team is too small; we can’t afford to dedicate people to this.” This is a common and valid concern. In our experience, it is extremely beneficial to structure a design system team with separate processes and assets from the products team, even if the same people work on both the design system and the products.
The separation of concerns makes their work easier and less tangled, even if they wear multiple hats.
Typical processes that can’t be missed in a design system team are both internal to the team and external.
Internal processes include:
External processes include how to:
It is very important for external processes to be clearly advertised and well-documented to all intended users. For example, instead of saying "Reach out if you have a problem", you may prefer being more precise like "Open a ticket on this Jira board…, including this information…, you may expect an answer within X days, and we’ll prioritize this way…".
We’ve discussed the parts of a design system that generally should be there, but this doesn’t mean they’re all there is to it.
A design system collects knowledge and resources to deliver products effectively while maintaining consistency. In this spirit, you should feel free to include anything else you think will help you reach that goal. Some examples are:
In conclusion, is your design system really a design system?
A design system is a set of principles, tools, and reusable components, guided by clear standards, that can be used by designers and developers to deliver effective product delivery while maintaining consistency.
As we discussed in this blog post, there are multiple interpretations of a design system, many of which create a lot of confusion that may lead companies to think about having a design system and benefit from it while they actually don’t.
We saw how the ideal final product requires balanced collaboration between design and development teams. This means working together synchronously and sharing responsibilities. Effective communication and a shared vision are essential. Design and development assets should be designed and evolved to ensure they speak the same language and allow for exact correspondence between the design and development.
A strong set of foundations guarantees consistency across the components of a library. Still, the real strength comes when these foundations are exposed to dev and designers to build new components. A design system's foundations should be accessible to designers and developers as much as components exist as design and developer resources.
A design system should always have a designer and a front-end developer working in tandem to ensure that the benefits of a design system are fully realized. It's important to note that a design system is a collector of knowledge and resources, so you should feel free to include anything else you think will help reach the goal of effective product delivery while maintaining consistency.
Gabriele is co-founder of Buildo, where he works as co-CTO. He is passionate about front-end and back-end architectures, and has long-term experience with React, TypeScript and Scala.
Are you searching for a reliable partner to develop your tailor-made software solution? We'd love to chat with you and learn more about your project.
