Get started with Design Systems

What is a design system

Design systems evolved from the earlier brand guidelines, but instead of being static like those, they’re dynamic and constantly change depending on the needs. A design system is made to create a streamlined process between design and development, to speed up the designing process and be manageable whenever there are (significant) changes.

It’s a collection of

• Components
• Patterns
• Languages

Arguably, components might be the most important category because they are the building blocks for good design systems. Components should be easily reusable, basic enough to modify, and clear enough for everybody to understand them.

Some synonyms for a design system are:

• Pattern library
• Modular design
• Component design
• Design language
• User interface library

It’s important for a design system that it’s not static and always up to date with changes, a new component needed? It should be added to the design system first and then look at the implementation. The same goes for bugs that require fixing, always make sure your design system is up to date with any changes.

One of the best ways is to iterate design systems, set dates for different releases, and have targets that need to be accomplished by then. Don’t randomly update the design system and send it off into the world like that, that creates chaos and is unreliable.

Also make sure that everybody is always up to date when it’s about using new files and not using old ones, since you can’t always immediately delete a file or component, make sure it has a clear indication that it shouldn’t be used anymore. The indication should also be clear to every team member, the best way to accomplish that is to create a system that has several icons indicating which is what.

What is the process

The first step to creating a design system is to have a dedicated team. This team can be one single person, a dedicated team, or a distributed team, this is a team where everybody within the office/community helps with the development of the system when they have time. There is no good or bad way to create a team, but it’s recommended that it’s not one single person's job, the best results are thanks to teamwork.

In the second step, you’ll encounter some phases that you’ll have to go through in order to successfully create a design system:

Discover: find out what’s needed in the design system

• What are the needed components
• How many components will there be
• Will there be variants
• What’s the style, look and feel
• Where will the mood board be created
• Is there a dark and a light mode
• What’s the naming convention
• …
• It’s important to ask yourself all these questions before starting the design system, this way you can create a clear structure.

Design: in this phase, you’ll start designing the components

• Wireframes
• Applying design
• Approval: before doing anything else you or you and your team will go back and see if there are changes needed. This ensures there won’t be a waterfall way of working. It’s important to ask in between designs and components for feedback as well.
• Development: when everything is approved and ready to go, it’s time to develop the components. Most developers have “try-out” components in a Storybook. This means they can test components without risking anything to break an entire site. This method is very useful to see how a component will interact and if it needs to be tweaked.
• Documentation: there are multiple ways to do documentation, this could be during the creating of the design system, after, … It’s all about preference, however, it’s important that all API’s get documented and that it’s a task as well for the designer as the developer. Documentation will mostly be used by developers to see how components interact (which each other) and how they should behave.

It doesn't mean because the creation of the design system is done that everything is done. A design system is organic and will constantly change and needs to be kept up to date.

What are tokens

Most design systems use tokens, but what are they exactly? Design tokens are all the possible values that a design system can have like colors, spacing, typography, styles, …. If it has a value (no matter the kind) it can be transferred into a token. Tokens have multiple advantages, two of the most important ones are:

• They are easy to reuse and make sure you’re able to quickly create/change a design because of their flexibility
• It’s easier for developers to create the code based on the design because the tokens can be extracted into a JSON file

There are three different kinds of design tokens: (from general to specific)

• Global tokens (red-400)
• Alias tokens (ds-cta-warning)
• Component-specific tokens (button-ds-cta-warning)

Global tokens

They are the primitive values in our design system. Things like: color palette, animation, typography, and dimension values are all recorded as global tokens. These can be directly used, and are inherited by all other token types.

There are different kinds of global tokens, one of them being size-token. Global size tokens are used for specifying dimensions and spacing for every Spectrum component. Since Spectrum supports two platform scales, token values automatically adjust between scales, allowing for a single token to be used for each.

Size tokens are anchored around a base value. Each token’s number represents a percentage relative to the base value. For example, size-100 is 100% of the base value, size-400 is 400%, and so on.

Another one is static size tokens, they are persistent across each platform scale. Global size tokens change at every scale in order to support the overall scaling of an application and its components. Static size tokens are used for properties such as border thickness, which are meant to remain the same across platform scales.

Alias tokens

Alias tokens relate to a specific context and they help communicate the intended purpose of a token. They are effective when a value with a single intent will appear in multiple places.

Component-specific tokens

They are a representation of every value associated with a component. They often inherit from alias tokens but are named in a way that allows engineering teams to be as specific as possible in applying tokens in component development.

What are some best practices

One way to work is according to the atomic design, in this way of designing you start with the smallest component (= atoms) and keep on combining them to molecules and keep on combining those to organisms …  and so on. This way of working ensures you’re not forgetting vital components.