What is a Design System?
This is the first article from my series about design systems and I know, you’ve probably read millions of definitions already but this is more of an introduction to managing expectations of the next articles. Let’s start!
Design System Definition
Design & UI Components
These are the main tools for designers and developers to enhance communication and collaboration, helping them to speak the same language when defining new features.
Input
Button
Style Guide
Here's where branding connects to the DS with detailed information on how to use visual styles for typography, color, spacing, and icons. It increases consistency when building new features and components but is also helpful for the whole company's design assets.
Interaction Patterns & Guidelines
Describes behaviors and how the elements should be used and integrated into the product. Patterns and Guidelines ensure a shared and cohesive experience in all the products and each of the features.
Documentation
It needs to cover every single detail to help learn and understand the system and its possibilities, what it covers, what is limited, and what is customizable. Documentation should be unified and include both design and development details to elevate communication and collaboration.
The main goal of a design system is to increase the efficiency of the company in building and delivering branded, consistent, cohesive, and accessible features and products.
The FrankensTable Example
I’d like to also give you a real example of a design system team in action:
Let’s say that you have 4 different features that use a table. It could be a dashboard, a CMS feature, a pricing table with comparison, and a simple checkout panel.
Velocity vs Scalability
We like to think that everything is optimized and built following the best practices, but in reality is very common for companies to have multiple teams assigned to the different features, each one working on the table functionalities individually, which is 3 or 4 times the amount of work depending on the requirements.
This multi-level workflow makes it hard to ensure consistency and coherence. Product teams might have started using the same base, maybe the Bootstrap table, but chances are they will end up having a disconnected FrankensTable that will require manual maintenance every single time there is an update.
This kind of workflow usually works to release features fast, the problem is that it’s also easy to build up a lot of complexity in the product architecture with an incredibly high costs to maintain in the long term period.
Applying a Design System
Using the same scenario, a design system team will be in charge of building the table component, defining the style and interactions, making sure to cover all those use cases above, and integrating it into the product with a final QA phase. Thus, product teams will only work on the actual features and spend less time working/maintaining the table directly.
The result is a consistent product with cohesive interactions that will benefit both the users and the company in the long run.
Beyond Figma Libraries
As you can see from the example, a design system goes way beyond Figma libraries. It requires strategy, politics, advanced knowledge of the product, meetings, decisions, and negotiations. Don't worry, I will talk about all this in the next articles.
As conclusion, I'd like to share a thought:
It's called Design System, and it's owned by the entire company, not just designers.
If you see someone trying to make a case for a design system, don't be scared by the amount of work and just hear them out. They will probably have some interesting ideas that will benefit product delivery and thus the company.
Next: Benefits of a Design System
I will talk about the benefits of a design system, not only for the company side but also for the users. Consistency, Scalability, Accessibility are some of the aspects I will describe.
Issue 02