Design Systems: a glossary for developers & designers
Tags: ux, design, webdev
Published: 2020-09-27 19:04:02

## **👋🏾 Introduction**
Design systems are interdisciplinary by nature. They are built and consumed by designers and developers, therefore it is important for common terminologies to exist to support the communication between these two disciplines and other related actors.

_Note: while some of the concepts are explained in a way that is more related to the context of web development, most of them are applicable to other contexts as well._

---

## **📖 Glossary**
In this post we will present some key concepts from design and development, explain their meaning in the context of design systems and point to any ambiguity that may exist.

### **Foundation/Essentials/Principles**

![](https://dev-to-uploads.s3.amazonaws.com/i/2j7sejx6wg533zhfqsvw.png)
_Example of Material Design foundations_

Every design system is built on top of a set of fundamental rules which are shared across components or other parts. These rules can relate to visual design (e.g. **animation**, **colors**, **typography**) or define more abstract principles such as **brand personality** or **writing style**.

### **Components**

![](https://dev-to-uploads.s3.amazonaws.com/i/rqnbzxme3sxckukemyti.png)
_Example of Kor UI button component_

Perhaps the most used term, components are individual units (such as **buttons**, **inputs**, **tabs**) that have defined appearances and interaction paradigms. Components can have different variations and be customized through APIs (Application Programming Interfaces).

### **Patterns**

![](https://dev-to-uploads.s3.amazonaws.com/i/jk1yggdtxa5n5fboy4k0.png)
_Example of Carbon Design login pattern_

Patterns define how different components can be combined in a certain way to serve specific user goals that are often repeated across screens or applications. For example, input fields, icons and buttons can be combined in a certain way to serve the goal of signing into an application. Examples of patterns are **forms**, **navigation** and **onboarding**.

_Note: UX patterns should not be mistaken with ‘design patterns’ in software engineering, which are also common ways of solving problems but specifically related to the context of engineering._

### **Properties**

![](https://dev-to-uploads.s3.amazonaws.com/i/kus93wfjswfbvmmf1ks9.png)
_Example of Kor UI card properties_

Components can be modified through the use of properties (or ‘props’, for short). In the example of a button component, the text **label**, **icon** and **disabled** state can all be set through properties and combined to define a variation of that element.

Properties have types. For example, `label` can be set as a `string`, allowing any character to be entered, while `disabled` has a `boolean` type, allowing only true or false as value.

### **Slots**

![](https://dev-to-uploads.s3.amazonaws.com/i/yjrvli8sqggq1xb64dx2.png)
_Example of Kor UI card slots_

Components can have slots in which content can be inserted. For example, a card can have a **top** slot for tabs, a **center** slot for text and a **bottom** slot for buttons.

### **Events**

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/4cdskc0hok3kplllp3cz.png)
_Example of Kor UI tag events_

Events are triggered by components in given circumstances. They are used by applications to react to user interactions or changes in the components. In web technologies (HTML), all components fire a set of standard events such as **click** or **mouseover**, but components can define their own custom events such as **expanded**, **collapsed** or **checked**.

### **Tokens/Variables**

Design tokens or CSS variables are sets of values shared across components. For example, the **body font size** token can be defined as `14px`, or the **accent color** token set to `#51AA51` to reduce repetition and increase the ease of customization.

### **Classes**

Classes can have two meanings. In CSS, classes are used to **add styles** on top of the standard ones, and this can be a way of theming design systems.

On the other hand, in software development classes are objects used for **encapsulating data** such as the definition of properties and functions. In this sense, components or utilities can be exported as classes.

### **Binding**

When consuming a design system, one of the tasks performed by front-end developers is called binding (or data-binding), which means **linking components to variables** stored on a database or application.

Binding can happen from the component to the variable (e.g. editing an input field sets a variable to the value of the input) or from the variable to the component (e.g. the label of a button is a translated string coming from the database). Both types of binding can happen simultaneously, configuring a **two-way data-binding**.

### **Framework**

Applications are usually built on top of frameworks that take care of tasks such as routing, data-binding or translation. For example, when building web apps, frameworks such as **Angular**, **React** or **Vue** are commonly used. While some frameworks can also come with component libraries, they are not intended to replace design systems but rather complement them.

Frameworks can also be used to build the components themselves, but a component built based on a given framework does not always have to be consumed by that same framework. For example, LitElement, Angular or Vue can generate components that can be consumed by any other.

---

## ✔️ **Conclusion**

While the explanations and terminologies listed in this post are based on the most common practices, you should be aware that they can defer across teams or institutions.

We hope this information will be useful for you and hope to see you soon in our upcoming posts :)