“What is a Design System?” is the Wrong Question
Ask yourself: “What is a Design System made of?”
Hello everyone, my name is Mauro Erta and I’m a Software Developer at VLK STUDIO.
In the last few years, I had the opportunity to build some Design Systems for different companies, and to build a library called Morfeo that can help you to build your own.
In this article, I want to share with you what I learned from those experiences.
Table of Contents
· The problem: Developer Driven Design System
· The wrong question: What is a Design System?
· The right question: What is a Design System made of?
∘ Design Language
∘ Design Kit
∘ Component Library
∘ D̶e̶v̶e̶l̶o̶p̶e̶r̶ Sandbox
∘ Documentation
∘ Governance model
· Dividi et Impera
· Ⓜ️ Morfeo
· 👋 Thanks for reading
The problem: Developer Driven Design System
In the last few years of development and refactoring of component libraries, I noticed a recurrent pattern:
Most of the time, Design Systems are made by developers, for developers;
To be honest, I don’t even think these kinds of things are Design Systems, they are an attempt to reuse components and common rules, but in a chaotic way and with pretty bad results.
I like to call them “Developer Driven Design Systems” (DDDS in short, or 3DS if you’re a Nintendo fan).
It’s weird if you think about it — a Design system should be the result of a collaboration between Designers and Developers (at least); DDDS instead, are the result of a lack of collaboration, and the more they grow, the more the communication between the teams become harder and harder.
In a DDDS, whenever the UI/UX team propose a new design the result is always something like this:
Yep. The available components cannot represent the new layouts, so you have to build new components or update some of the existing ones, and you know what this means: Nightmares and tons of bugs and regressions.
We should stop for a second if things like this are happening in our projects, and ask ourselves:
- How is that possible that our component library is this fragile?
- How is that possible that the design team asks for updates this hard to implement properly?
The answer is pretty easy: Lack of communication!
Who’s guilty of this? Designers? Developers? What about both!
The guilt of a lack of communication is always shared!
I hope this article will reach not only developers; If you are a designer and you think that all the inconsistency in the design of your application/website is caused by incapable developers, I have something to tell you:
You’re probably even more responsible for this situation than (eventually incapables) developers themselves, for a simple reason: you know design!
What do I mean by “You know design”?
I mean that a good design should communicate, like a language, so my question is: where is your language? Have you ever taught this language to your team? If the answer is no, I was right and you’re responsible for the mess you currently have.
The wrong question: What is a Design System?
If you search on google, or here on Medium, you can find tons of different definitions, why there are so many? Simply because it’s not just one thing.
I‘ll try to give the simplest and shortest definition I can:
A Design System is a source of truth of the visual behavior of your application.
Are you satisfied with this definition? I spent 15 minutes thinking about it and even if I think it’s correct, I don’t think it will help anyone to get the point.
What if the question is just… wrong?
A Design System is not only one thing, and it’s not made by a single person.
It’s a set of different parts made by different people with different skills.
So why we should try to find just a single definition? If you really want to understand what is it, and eventually build your own, it’s better to focus on the big picture!
The right question: What is a Design System made of?
I think that the folks of Rangle.io made an amazing job describing parts of a design system, I completely agree with what they wrote in this article, and here I’ll just make a brief of it, and give you also my point of view;
But anyway, I strongly recommend reading the original article!
Rangle suggest splitting the concept of the Design System into 6 different parts:
- Design Language
- Design Kit
- Component Library
- Developer Sandbox
- Documentation
- Governance Model
Design Language
As I said before, a good design should communicate, like a language.
The design language is a starting point for your brand new design system, it contains the definition of the colors, spacings, gradients, shadows, … All the other parts will be based on the design language, the right implementation of it will ensure consistency and harmony all around your application.
From the application point of view, the design language is usually called “theme” and can be described with an object that follows the System UI specification.
Design Kit
Made by designers, it’s a set of all the UI elements of the application, these components are made by strictly following the Design Language.
The most common tools to build design kits are Figma, Sketch, or Adobe XD.
Component Library
It’s made by developers and it’s the implementation of the Design Kit.
In a nutshell, it’s a set of the real elements that composes your UIs and must be a 1 to 1 representation of the Design Kit and, of course, it strictly follows the Design Language too.
The Component Library is usually made in React, Vue, Angular, Svelte, or Web Components.
D̶e̶v̶e̶l̶o̶p̶e̶r̶ Sandbox
It’s a place where you can visually test the components, more specifically — you can see them in isolation, play with them and their properties and see how they look in different screen sizes or color modes.
The Sandbox is a playground for your component library and also the fastest way to see how it performs in a real environment.
The most known tool to create and maintain the sandboxes is Storybook.
ed: Rangle called this part “Developer Sandbox”, but I like to call it just “Sandbox” because I think that allowing also Designers to play with the Sandbox can really help them to understand the state of the component library, what is possible with it and if it follows the design kit.
Documentation
Power is nothing without control
A good documentation contains a description for each component, describing their functionalities, use cases, and relations with other components. It should also contain higher-level information to make clear the intention of the Design System, its philosophy, and the rules that will ensure harmony in the compositions of the layouts.
Nice tools to write and maintain documentions are Gitbook, Confluence, Notion, or, in case of entirely dedicated websites, Docusaurus and Nextra.
Governance model
Such as any product, software, or hardware, a Design System also needs maintenance and constant support.
It’s important to understand how a Design System should be updated, how an issue should be reported, how to fix bugs, and how new people can prepare to start working with a design system itself.
Visualizing the design system as a composition of different parts helps to understand the main concept of this article even better: the communication between designers and developers will make the difference between a successful and a failed design system.
This collaboration though, should not be seen as an extension of the responsibilities of each team, instead, completely the opposite!
Dividi et Impera
Dividing the design system into 6 parts also helps to understand how different teams should interact with each other:
Design Language and Design Kit are made by the design team, Component Library and (Developer) Sandbox instead, are the responsibility of the developers, while Documentation and Governance Model will receive contributions from each team.
That’s the reason for my initial thought on DDDS:
Most of the time, Design Systems are made by developers, for developers;
I think now it’s clear how important is to think of the design system as a combination of different parts, this way it will be also easier to split the responsibilities for its implementation and facilitate a successful collaboration.
We all saw an incredible improvement and impressive advantages where we applied these concepts:
- Harmony through the whole application: The new layouts and components, since they’ve been created following the Design Language, are consistent with each other, even if they are made by different teams of engineers;
- Clean Code: Having clear and concise documentation, strict type checking, and tests improved the quality and the maintainability of our code a lot;
- Communication between teams: The design and developers teams were working closely together. Sharing a common language (Design Language) helped the teams to communicate faster, but also made it easier to work independently because the Design Kit and Component Library are sharing the same core values;
- Performance: Making new layouts became like playing with Lego, the components were fitting together perfectly and there was no need to do any “hack” or refactor to make new features possible anymore;
- Learning Curve: Getting comfortable with a large codebase is never easy, but good documentation and standardization of the processes made it possible for newcomers to get ready with the whole project in a couple of days, not weeks like it used to be;
- Scalability: Not only the time needed for the implementation of new layouts is decreased, but also updating the existing ones is easier and faster, allowing the project to grow faster than ever!
As you can see, the fact that now our application looks good is just a side effect of a process that gave benefits to the whole company!
I think that the reason for this should be found in the old but gold concept of “Dividi et impera”, in this circumstance, splitting the Design System into parts that can be optimized and thought through by specialized teams, while sharing the same goal.
Ⓜ️ Morfeo
I’d like to finish this article by introducing Morfeo, a set of tools and libraries that helps you to build your Design System.
You can integrate Morfeo with any framework or library. With it you can create styles and components strictly related to a Design Language (the theme); it supports Multi-Theming, it’s extendible, and easy to test.
Also, with the browser extension, you get an auto-generated and always available Developer Sandbox directly in your browser. For free.
Morfeo is still in beta, we are working on some new cool features to make it production-ready as soon as possible, but if you’re curious about it, here you can find all the information you want:
If you wanna help us and contribute to the project, here is the Github page (It’s completely open-source):
And here you can find the link to download the browser extension (you can test it directly on the website of Morfeo if you want to have a look):
👋 Thanks for reading
I’m curious about any feedback, feel free to drop a comment and give me your point of view, also, if you want to share your experience in building design systems I can’t wait to know what kind of issues you faced and how you solved them.
If you’re interested in Morfeo, we have a Discord server, feel free to join us:
🇮🇹 Are you Italian? there is also an Italian version of this article, check it out here.
Further reading
More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter and LinkedIn. Join our community Discord.
