This is the tool that our methodology revolves around. Therefore, we believe it’s appropriate to dedicate an entire chapter to explaining what we understand as a design system, what design principles guide our work and what elements our systems are made up of.
It is a tool that allows us to establish patterns and utilise a series of elements that can, and must, be reused to create functions. The modulation of the system is what allows us to build the smallest units to the most complex components, as well as establishing rules that will help us work as a team in an aligned way by using principles. In addition to all of this, a design system serves as a meeting point between the design team and the development team. As a result, we can implement a clear and consistent language through which we create and develop products.
A design system can be understood as:
The design system must be flexible and remain functional throughout time. A design system isn’t something static, but dynamic. It evolves with the product and its design.
Using a design system guarantees consistency in our products. This has a positive impact on the user experience and significantly shortens the time taken to design, develop and create products. On the other hand, design systems are a particularly useful tool for creating digital products with the ability to grow and escalate in a controlled manner. Last but not least, they allow us to spend as little time as possible on unnecessary details and to think more about the product itself.
Even though there are some similarities, a design system is not a brand manual or a style guide, or a substitute for either. It can coexist alongside them and each one adds its own value.The main difference is that a design system isn’t just a static document that simply explains how each element should look. As we have previously mentioned, a design system is a living entity that contains a common language, principles and tools that help build coherent products.
When it comes to making decisions related to design management systems, we follow a series of principles that we share with all members of the team. Thus, we are able to lay out the foundations for what we consider a good product. In our opinion, design systems can be:
These principles also have a clear influence throughout our production process.
Beyond these general rules that serve as prerequisites when using a design system, we also give specific principles to each one of them. The purpose of these principles is to give each system its own personality. For example, a design system of a public entity could have impartiality as a principle. Whoever manages that system must abide by these maxims in order not to create functionalities that will influence the user’s decisions.
Each design system is unique. It fulfils the needs of the product that it supports. To guarantee that the design system works and is aligned with principles and goals, it must be created as a set of pieces that fuel each other.
Foundations are the aspects that define the visual aspects of a system. In design systems, we normally find colour, typography, iconography, layout, spacing and object styles. It can also include aspects that define the content such as tone, voice and photography, which help us give the system its own unique identity.
The foundations represent the complete selection of resources that we will work with. There will be some that will be used and some that won’t. These foundations will also feed the tokens, which is what will eventually be applied to the interface. Their purpose is to make the decision-making process easier in the scalability of the design system.
In “Foundations” will be gathered, after being analysed and studied, to guarantee that they function properly.
Now we will talk about good practice when it comes to designing the foundations for our design system.
Colour is a very important element of visual communication. As such, we must use it intelligently and intentionally. When creating design systems, we differentiate different types of colours:
In “Foundations” we define the colours by pallet based on their tone. We divide them into scales of 5 or 10 colours, depending on the complexity of the system. With this, we want to avoid the use of transparent or opaque colours and encourage the use of “pure” colours.
There isn’t a systematic method that can fully automate the creation of colour scales. However, as a starting point, it works to put the luminosity up by 20pt to create lighter shades and put it down 5pt to create darker tones. The exception would be the lightest colour of the scale, for which the L value can be changed only by 1 or 2 pts, as this colour will be used for big sections like backgrounds.
In order to properly organise the space, we use a grid. This tool helps us distribute the elements that are documented in the design system. It must be used in a structured way to create functional components that will form the product.
This grid must be defined mathematically, setting up the rules that will define the size and position of the elements that we place on it. This way, we will limit the possibilities and speed up the decision-making process based on a harmonious system of proportionate measures. In our case, we establish two different variables that define the grid:
While the single pixel is the minimum unit of a digital grid, our system will be based on a grid of vertical and horizontal increments of 8 pixels. Given how important it is for us to organise the grid in this way, we have decided to dedicate a whole section to it.
Each page measurement has to be a multiple of 8. This includes aspects like column width, margins, text, icons, pictures, etc. Only by sticking rigorously to this will we manage for all the elements to be perfectly aligned.
When we apply the multiple of 8-rule to the typography, we make an exception and take the liberty to establish the baseline on multiples of 4. This way, we achieve versatility when it comes to setting up line-spacing consistent with the typography size and we create a block of text that is easy to read. For example, if we stick to multiples of 8, for a typography of 12 px, 16 pts of spacing could be insufficient and 24pts could be too much.
There are isolated cases in which it is not clear how to use the 8-pt grid. For instance, when the elements have a line border. In this case, the line will be defined in a way that the space it takes up is closer towards the inside of the element. We won’t count the border width when measuring the spacing.
Exceptions to the rule
There are projects and situations in which a grid of size 8 is too big. In these cases, the team studies the possibility of using a 4-pixel grid. This way, we have more versatility when defining spacing, proportions and hierarchies within interfaces that have a high density of information.
Because writing is our main visual communication, a good use of typographies is crucial. This good use facilitates the reading process and makes the user’s experience more fluid. Furthermore, typography is a great tool to give different projects different personalities and to establish a communicative tone that matches that personality.
Each typography has its quirks and establishing dogmas with their numeric values doesn’t always work. However, we do follow certain general premises that can help structure the information and composition of texts. They are the following:
As a starting point, we have an incremental rule to determine different sizes and line breaks when establishing line spacing according to the size of the typography.
In “Foundations” we have a catalogue of typography sizes that can be used in an interface.
Iconography represents complex visual concepts that, at first sight, convey useful information for the user. It must be carefully and concisely used, avoiding ambiguities.
With the design system, we group up icons according to their size. We establish a minimum size of 16 px and we escalate in multiples of 8 px depending on the needs of each system. In order to make sure that all icons of a specific size are of the same proportions, we insert them in a transparent square background of the same measurements.
It's important to define the shape characteristics of all icons so that there is a visual unity formed between them. We can have icons made of lines as well as solid shapes. They both share the same visual properties that can be defined by:
In this section we classify certain characteristics that, because of their global nature, are present in many of the pieces that make up the system and help give it its own tone and voice.
In this category we will find a number of elements that we can manipulate, such as the roundness of borders, shapes and shadows they project, blur, etc.
Tokens are variables that associate foundations with the system to give it visual consistency and flexibility. The naming of the tokens is ambiguous in its values as these can change or be dynamic (theming).
Tokens are intermediaries between foundations and their application on the interface.
Advantages to using tokens:
In the design system we can find colour tokens, typography tokens, layout tokens and object style tokens.
By definition, all systems are made up of elements that articulate the system and make sense of it. To make teamwork viable with system designs it’s crucial to use a common and self-explanatory language to name those elements. Depending on the nature of each element, we suggest the following classification:
This grouping, depending on the use, action or problem the design system component is solving, facilitates the use of the design system on Figma, as well as its documentation.
Patterns are solutions that, through the use of components, fulfil recurrent needs in products.
Example: a text box allows to incorporate data (it makes sense on its own), but when it’s to be combined with other data, buttons, etc., it can become part of a module, assuming a more global function, such as a registration form.
Another example would be a footer. Often, a footer consists of a link to another page, which makes sense by itself; but in general, it has a more global function – navigation.
In order for a design system to make sense on its own, it has to be documented, with enough information available to be of use. This documentation must fulfil the needs of everyone who works on and makes use of the design system: designers, developers, product owners and product managers, among others. Therefore, there isn’t an exact global naming system that can be applied to all design systems, but it must be adjusted to the needs of the product that it’s supporting.
Down below, there are some recommendations for documenting and naming different elements of the system. This guide is based on how the design systems of companies like Inditex, BNEXT or Repsol, among others, have been built and maintained.
Depending on the complexity of the product and the design system, the elements will or won’t coexist within the same file or, by default, Figma’s library.
If the design system is small and of low complexity, it’s advisable to keep it all in the same file in order to make its use simpler, differentiating the elements in different pages.
However, if the design system is complex, the best option is to differentiate the elements that we saw previously by “Files” instead of by pages.
When does it make sense to differentiate by files?
Here are two examples of this situation:
Whether it’s within pages or files, the elements are organised in frames.
In our design systems we differentiate between “Global” and “Specific”, global being the foundations and specific the tokens that will be applied to the final interface.
The frame of “Global Colour” is structured by colour scales, naming these by their given name. For example: red, blue, grey.
The number refers to its position on the scale. On a scale of 10 we would have: Colour 10, Colour 20, Colour 30, Colour 40, Colour 50, Colour 60, Colour 70, Colour 80, Colour 90 y Colour 100. On a scale of 5, we normally keep this same numbering, resulting in: Colour 10, Colour 30, Colour 60, Colour 70 and Colour 80. It’s this way because of two reasons:
An example would be: Global/Red/20
The frame of a “Specific Colour” is structured and named by the uses that it has. We normally differentiate the following uses.
From each one of these elements, we will gather a group status that will allow us to define how the colour will behave in a state like hover, pressed, focus.
We can use numbers or any other special feature as a distinguisher.
An example would be: Specific/Content/1
For the typography we also contemplate “Global” and “Specific” frames. For “Global” frames, we have a guide for font families, weights, spacing and sizes allowed; whereas for “Specific” frames, we specify which combinations of these aspects we will choose depending on the use. For the naming of these typography tokens, we follow the same logic as for colour tokens.
An example would be: Specific/Title 1
We also count on dynamic typographies, which refer to typographies that can adapt depending on the resolution. To document these ones, we will add the resolution name before the use, as follows:
Example: Specific M / Title 1
This logic will be applied to all foundations and tokens in the system.
To document foundations and tokens, we use the following template.
Figma’s hierarchy to create a component’s path in a library is:
If the name of a component contains “/”, Figma will consider it as an additional level.
*If there is only one page that contains components within the file (Master Components), Figma will omit this level.
*If all components of a frame are located on the same page, Figma will omit this level.
Taking into account the way Figma manages the different levels, the name we give to a component will have the following structure:
Example: Button / Primary / 01 Default
Additional properties can be added and separated by a “/”. If we want the components to show up in a specific order when using the library, it’s important to add numbers at the start, as is the case in the previous example with the property state.
In order for Figma to create the correct path and facilitate both decision-making and the use of the design system, we document all the components in frames. We will consider the following frames and add components to them:
It’s important to accompany the components with a user guide. We will create the frames guide where we will document the different components. It’s crucial to communicate to the team all the decisions regarding a component for its later implementation, use and any future decisions made about it. We propose the following checklist to be taken into account when documenting a component:
In order for a specific behaviour of a component to be understood by the relevant person, it’s advisable to include it in the component description. The goal is to share this information with whoever is using the system.
The same logic we use for components can be applied to document patterns.