Hvordan vi organiserer designsystemet vårt

Design systems have become an essential asset for any design or development team, they became a nøkkelelement 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 som definerer produktet og hjelper teamene med å designe og bygge konsistente og sammenhengende digitale løsninger. Det hjelper teamene til å jobbe raskere og mer effektivt ved å tilby et felles språk og et sett med gjenbrukbare komponenter og mønstre. Det er her nykommere i prosjektet kan lære å utvikle flere elementer og finne spesifikasjoner for å forstå og implementere dem.

Hvordan hjelper det?

Hovedformålet med et designsystem er å forbedre effektivitet, kvalitet og skalerbarhet i design og utviklingsarbeid. Det hjelper team med å skalere design- og utviklingsarbeidet ved å tilby et rammeverk for å bygge og vedlikeholde digitale produkter over tid.

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.

Slik organiserer vi designsystemet vårt i Lasting Dynamics: Som seg hør og bør består designsystemet vårt av følgende elementer 2 hoveddeler:

1. Foundation
2. Komponenter

Grunnlaget

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.

Komponenter

Hver komponent av disse har en egen side som er delt inn i fire hovedpunkter eller aspekter, og vi vil forklare hvert aspekt med et eksempel på Switch-komponenten fra vårt Design System :

1. Documentation: For hver komponent gir vi detaljert dokumentasjon om bruken av komponenten, tilgjengelige typer, tilstander, størrelser og underelementer.

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 (se vår artikkel om atomdesign).
• 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.