Primož Škerget
Senior product designer at d.labs
I had to ask for an extension to write this post. Not because I had nothing to write about, but because there are so many resources and approaches when it comes to design systems that one can get lost. Instead of writing out a detailed step by step post about how to create one, I stepped back and asked myself the what, who, why questions and tried to answer them as sincerely and straightforwardly as possible. If you think that a piece of information is missing or have other questions, please write to us, and we'll update the post.
Donella H. Meadows wrote in her book "Thinking in systems" that a system is an interconnected set of elements coherently organized in a way that archives something. It must consist of elements, interconnections and function (purpose). While this is a more general definition of a system, we could apply the same thinking to a design system.
A design system is a systematic and strategic approach to product development. Its simplest definition is a set of guidelines, design assets, components, patterns, and code used to manage design at scale.
We must understand that any of those things alone is not a design system. A pattern library is helpful, but it’s missing the why. Guidelines can fill you in on the why but are missing the how and so on. Any part of the design system is helpful to create by itself, but only everything together will give you the desired benefits.
Not every website, app or product needs a complete design system, but they can benefit from a more component-driven architecture and development. We usually start using design systems on a product with high design maturity and can benefit from this approach. What we mean by that is that a product has moved beyond the initial discovery and go-to-market phase and is now ready to optimise the experience.
Smaller projects still in the early stages need to move fast, while spending resources on a design system would slow them down and take them away from pursuing their goal (e.g. product-market fit).
We need to point out, more established projects can benefit from design systems by increasing efficiency at scale.
More detailed answers are in the section below.
I specifically added “build, maintain and use” in the question since all of those are key for success in this endeavour.
The obvious and most visible one is that it creates a visual consistency across the products (or multiple products/channels). When multiple teams work on the same product, it can lead to inconsistencies in appearance and experiences, primarily if the teams work independently or, even worse - in silos. In this case, deploying a product-wide design system can address this problem efficiently.
Good designers and developers are scarce. Using a design system can help team members to focus on larger, more complex problems. When you remove the need to polish every screen and close the option of reinventing the interface at every point, you give teams the necessary space to tackle the hard problems of your business.
The most significant benefit of design systems is that they enable teams to produce design and development work at scale. By reusing premade components and patterns, they can deploy new features earlier and more consistently. As a result, they can do more user testing and have richer data and more insights.
Remember how we formed the question? It purposely included “build, maintain and use” as those three words are mainly the reason for not using a design system. A design system takes time to build and maintain, usually by a dedicated team. After the system is created, someone still has to maintain it. But perhaps the biggest pitfall is that a design system needs to be regularly used for it to make sense. And here is where most teams fail. They don’t invest enough resources into teaching others how, when and why to use it.
Want to chat more about design systems? Get in touch at sales@dlabs.io.
.png)
