How we organize our Design system

Design systems have become an essential asset for any design or development team, they became a key element for all sizes and industries with a digital presence and not only tech companies. Design systems provide a single point of reference for digital design, including guidelines, components, etcetera.

This article will outline the Lasting Dynamics team's way of creating and organizing our Design System. We will use some of our internal objects, as an example and describe them step by step.

But before enrolling in the steps, we should know what’s a design system? and how does it help?

What’s a design system?

A Design System is a well-structured set of shared and integrated patterns and principles that define the product and help teams design and build consistent and cohesive digital solutions. It helps teams work faster and more efficiently by providing a shared language and a set of reusable components and patterns. This is where new arrivals in the project can learn how to develop further elements and find specifications to understand and implement them.

How does it help?

The main goal of a design system is to improve the efficiency, quality, scalability of design and development work. It helps teams scale design and development efforts by providing a framework for building and maintaining digital products over time.

Design systems are a powerful tool to simplify and boost the work within a team but it requires careful planning and execution to be effective.

Here is how we organize our Design system in Lasting Dynamics: as it should be, our design system is composed of 2 main sections:

1. Foundation
2. Components

Foundations

In this section, we described the most principal parts: Colors, Typography, Icons, Spacing, Grid and Shadow as shown in the view

In addition to a General section that contains all general components used to display items in the pages like the Header, Colors box, Documentation box, etcetera. These items allows to organize our pages and components so any new member in the team can integrate easily. For example, we have the documentation box that is used to add documentation about the component regarding its elements, states, sizes or types, or also the explanation arrows that are used to point the margins, the paddings or the any details inside the component’s anatomy.

Since our design system is more general and not project related, we made sure to include more examples and options in each part for better use in the future.

Components

Each component of these has an individual page divided into 4 main points or aspects, we will explain each aspect with an example of the Switch component from our Design System :

1. Documentation: For each component, we provide detailed documentation for the use of this component, available types, states, sizes, and also its sub-elements.

2. Anatomy: The anatomy is a detailed representation of the component to show and explain all elements and styles used, this representation help developers build this component with the right properties.
   

2. Component Variants: Here we build our component with all variants and properties that match the documentation (types, states, elements, etcetera), this is the final component that will be tested later.

A good approach is to create an instance and test the component with all possible cases to understand how it is used, and make sure to do a review about it -following our review process- and report any bugs found.

1. Animation: In addition to the component design, some components have different states with interactions between these states, this is what we call animation between instances. In our example below, we can see the different interactions between instances from a state to another, while hovering, while pressing…

After performing our tests on the component, if the component is validated, that means that it is ready to be used and published.

Here are some tips we prepared to help you create components:

• Build nested components: it is very important to first create all small components and then built big ones assembling them all together, the best way to do so, is to follow the atomic design approach (check our article about atomic design).
• Naming conventions: are important to let everyone access and use the component in an easy way, if we can document somewhere that could be really good.
• Variants: are another important aspect of the component, the main reason to use variants is to have components in different states.
• Clean layers: it is important to clean your layers and get rid of nested or unused layers because having a lot of hidden & unnecessary layers may reduce your file performance.
• Test your component: as already mentioned, it is good to test your component in all possible cases (you can ask for a colleague too), this approach helps you find mistakes and improve the structure of your components.

Publish & update components

Our team understands that every product is evolving and growing, and the Design System is a crucial part of any project, that’s why keeping it up to date with the changes for the Identity is the key. By working with components we ensure the possibility to publish changes on styles, colors, components, and other assets from the System in a matter of minutes, showing up on every Figma file where the Design System is synchronised.

Still, making many updates in short periods of time is not a good move, each improvement should be discussed between the team and proposed in ideation pages of a master file and a documentation related to this change should be announced to the team. That way, everyone is conscious of the possible improvements, how to use it and can propose suggestions.

With the latest Figma releases, it is more easier to publish your changes and keep track on those changes from any other fact. In fact, it is possible now to apply the changes on some components and the others will keep the other version, this way Figma gives us more freedome to manage our components and changes.