Introduction

Before diving into the world of Design Systems, we first need to understand a bit about where and when the need to use component libraries arose, what a Design System actually is, and why we need it more and more as a key tool for the success of our digital products.

It all started when the need to modularize systems emerged, which is nothing more than reusing components across various different products. This occurred due to the enormous growth of new devices, screen sizes, and online access environments that continue to emerge today. 

A modular system not only makes the process of developing new UIs compatible with multiple devices faster and simpler, but also ensures the consistency of a system’s visual structure and experience – which is even more necessary when we are talking not just about one, but about multiple systems within the same organization.

With the need to deal with device diversity and the goal of building projects conscientiously, the famous component frameworks like “Bootstrap,” for example, emerged in the beginning, created with the intent of facilitating and speeding up front-end interface development.

“These frameworks are nothing more than user interface structures that provide a collection of pre-built HTML patterns, CSS styles, and JavaScript to add functionality to interactive components like dropdown menus and carousels. One of the most appealing aspects of these structures is speed.” (Brad Frost)

As not everything in life is roses, no matter how incredible these structures may seem, they have disadvantages.

Over time, the customization of components and adaptation to each product’s brand became necessary, along with creating new experiences for different products.

Therefore, the ideal would be to have small libraries for each product and client that can be customized according to their needs, thinking not only about meeting the needs of the design and development team, but mainly the needs of the end user.

But then, what about Design Systems?

We identified, then, that we need more than component frameworks – we need Design Systems! These are sets of libraries that unify the language of a given product.

“A Design System is not a project, it is a product that serves products.” (Nathan Curtis)

A Design System, in general, is basically composed of design tokens, component libraries, and code libraries.

We often confuse it with a Style Guide, but keep in mind that a DS goes far beyond that and/or a simple component library.

I like the analogy that a DS is a pizza and the style guide is like a small slice of that great pizza that is a Design System. Let’s explore some of the points that make up a DS next.

Style Guide

The Style Guide is super important for creating the design tokens of a Design System.

It is a documentation that specifies the verbal and visual communication guidelines of a brand or product, and is composed of: brand usage rules, positioning, writing, tone and voice, fonts, colors, icons, illustrations, shapes, design language, user interface patterns, etc.

A style guide provides a foundation for everyone involved in the project, where each one can contribute with their respective considerations and concerns about the standards and language of a product.

“Education is as important as documentation. A style guide can show clients that websites are systems, not collections of pages.” (Anna Debenham)

Design Tokens

Design Tokens are the semantic style variables of our Design System – the best definition given by Meiuca, one of our great DS references today.

In other words, they are nothing more than style properties that have a common meaning to the team and can vary according to our project’s needs.

To make it a bit clearer, these tokens are a unified way of describing style elements (extracted from our style guide) that can have their value changed at any time and can also be combined with each other to form our components later.

Component Library

The component library is composed of the mapping of all components used for building the product, specifying everything from the visual structure to the behavioral aspects of each one.

In other words, it contains all our components with their variants, states, functionality, how they should or shouldn’t be used, how they can be combined with each other, etc.

There are some methodologies like, for example, “Atomic Design,” created by Brad Frost, that help in creating Design Systems, mainly facilitating the construction of more robust and structured component libraries.

However, there are several other models, such as the way Meiuca organizes its Design Systems, thinking about design construction based on “components first,” distributing its component libraries in a way that facilitates not only organized and well-structured design construction, but also thinking about maintenance and the mirroring of code libraries for different Stacks.

Code Library

The code library is nothing more than the mirroring of our component library in code.

Through a mapping, these components are developed so that their implementation can be reused, following all the guidelines of our component library.

Thus, there is a code library that is shared between products, ensuring consistency and the possibility of code reuse between projects.

It is common to use, to document code libraries and allow mapping all components in a simpler and faster way for developers, tools like “Storybook,” for example, which was already mentioned in one of our posts!

But then why use a Design System?

To start, after everything we’ve seen so far, we can say that a Design System is a huge help in making everyone’s life easier. Let’s highlight some of the points that make it so important for building our products.

A Design System, above all, brings clarity to a project, eliminating ambiguities and allowing everyone on the team to understand and act with confidence, precisely because of the more robust documentation, which covers everything from the base structure of a component to how it should behave and be applied.

A study was conducted by Figma to quantitatively measure the creative process of some of its designers.

Participants had two tasks, and only one of them was provided with a Design System. It was then identified that participants who received access to the DS completed their objectives 34% faster than those who did not receive it.

Therefore, agility and efficiency are two more super advantages of using a DS.

Furthermore, the components created can be reused across projects, allowing the team to focus more on problem-solving and ensuring consistency and a good user experience for the developed products.

But it doesn’t stop there! In business, there are benefits that can add a lot of value to the product.

In addition to providing speed, reducing time and commercialization costs of the product, it is possible to develop a more agile process for launching new versions with quality, ensure a more intuitive product interaction, and reduce adaptation time for new users, as a result of a good experience from a consistent design.

Thus, we can create cleaner designs and code, create a solid and clear design system for everyone involved from the beginning of the process, allowing changes more easily as the product grows.

Besides achieving a lighter and simplified process for integrating new team members, we can keep everyone on the same page, collaborating with each other, sharing knowledge, and directly contributing to the product. All this and more through the Design System!

So? What do you think about Design Systems?

At Zappts, we are constantly studying ways to deliver quality products that offer incredible experiences to our users.

In part two of this article, we’ll talk a bit more about how a Design System works in practice and some of the challenges we face, especially in the day-to-day building of our products. Stay tuned!

Here are some top DS examples for inspiration:

• Material Design
• Atlassian Design System
• Microsoft Design
• Mailchimp
• Uber.com
• Ant Design

References:

• Everything you need to know about Design System | by Jonatan Zylbersztejn | UX Collective (uxdesign.cc)
• Designing Systems | Atomic Design by Brad Frost
• What is a Design System? How to create a design system? (chiefofdesign.com.br)
• Understanding Design Systems. Before starting: What is Design… | by Van Serradas | UX Collective (uxdesign.cc)
• Meiuca Design
• Design System – A guide to design tokens by Yanna Ballantyne on Invision Design
• Figma – Measuring the value of design systems by Clancy Slack

    This article was developed by Carol Zaglia, UX Designer at Zappts.