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.
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.
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.
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).
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.
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.
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.
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.
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 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.
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.
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.
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 :)
Also published here.