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.

What is a Design System?

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:

• A common language.
• A balance between strict control and the chaos that results from freedom.
• A collection of reusable elements guided by clear documentation.
• A set of patterns and practices that are shared among a team in a coherent and organised way.
• Each pattern describes a problem that frequently occurs and describes and suggests a solution for it.

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.

What value does it add?

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.

Principles

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:

• Systemic – visual design uses patterns and reuses elements. This gives coherence and cohesion to the product and speeds up the creation and regulation processes.
• Reticular – design should use a defined system of proportion to organise and synchronise the whole.
• Rational – visual design must be based on logical and reasoned decisions.
• Aesthetic – the aesthetic quality of design has a direct impact on the utility and usability of a product.
• Understandable – our aim is to create self-explanatory products.
• Multi-platform – unifying the user experience across all platforms and adjusting the product to each platform.
• Scaleable – clear documentation allows for the design system to be easily actionable and adaptable to new situations and needs.
• Consistent – the use of patterns allows the user to adapt easily and reduces the learning curve.
• Flexible – it encourages personalisation, giving the user the freedom to adapt the product and its functions to their own objectives.

These principles also have a clear influence throughout our production process.

Specific principles

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.

How the system is created

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

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

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:

• Neutral – grey pallets that we divide in two sections: light and dark. The shades that belong to the light section will be applied on backgrounds and those that belong to the dark section will be applied on forefront elements, such as text and icons. Should we be designing in dark mode, we would invert them.
• Branding colours – these colours are normally associated with branding, they define and give the brand its personality*.* The main function of these colours is emphasis.
• Typography colours – we must choose at least a light colour and a dark colour for the typography. We can also establish other styles with different text styles to the ones we have mentioned.
• Semantic – colours that have an associated meaning. These are: red (negative), orange (warning) and green (positive).
• Support – there are colours that are rich enough to work when used for categorisation or over illustrations or pictures.

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.

Layout

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:

• Columns – they help structure the space horizontally. Based on the project’s needs, we can establish an even number of columns, between 2 and 12. It’s necessary to establish: the width of each column, the space between them and the margin of the set of columns in relation to the edges.
• Baseline – this organises the space vertically. The vertical spacing must be equivalent to the horizontal spacing between the lines in the main body of the text. This way, all the elements will be aligned and we will feel a sense of order.

Sizing

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.

Typography

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:

• Establishing well defined hierarchies between the different types of information. In order to do so, you can use different typographies, weights, sizes, colours, etc. An interesting way of identifying different hierarchies is to, first of all, establish the settings of the body text, and use this as a base.
• Adjusting the line spacing to 1.4-1.6 times the size of the typography normally works for text bodies. For highlights and titles, we reduce the range to 1.2-1.4.
• Controlling the length of the lines in the text body. It’s advisable to stick to 45-75 characters for a good reading experience. You can find more information about this in the article here.
• Sticking to one or two typographies and using the lightest possible font weight. This has to do mainly with the performance on webs and tools.

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

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:

• Line width – it’s important to establish a standard width for all the icons of a group. Even those created from solid shapes could use lines at some point.
• Finishing – as a general rule, they can be rectangular or round.
• Corners – normally they are: angular, round or have a bevel.

Layer Styles

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

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).

The tokenisation process consists of replacing sensitive elements with their non-sensitive equivalent.

Tokens are intermediaries between foundations and their application on the interface.

Advantages to using tokens:

• It’s easier to maintain consistency.
• It makes decision-making easier.
• It encourages scalability.
• Automatic application of changes.
• Resources optimisation.

In the design system we can find colour tokens, typography tokens, layout tokens and object style tokens.

Components

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:

• Action
• Content
• Input
• Navigation
• Feedback
• Overlay

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

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.

Naming and Documenting

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.

• Foundations and tokens.
• Components.
• Patterns.

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:

• The design system supports many platforms: web, iOS, Android.
• The design system has many components because it supports multiple case studies.

Whether it’s within pages or files, the elements are organised in frames.

Foundations And Tokens

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.

Colour

The frame of “Global Colour” is structured by colour scales, naming these by their given name. For example: red, blue, grey.

Global/[Colour]/[Number]

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:

• It allows us to add more colour afterwards and the current naming will still be valid.
• They are more consistent with what a scale of 10 would be.

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.

• Content.
  Colours used on texts.
• Border.
  Colours applied to borders.
• Semantic.
  Colours that have an associated meaning. For example, red (negative), orange (warning) and green (positive).
• Support.
  Colours that are versatile enough to work when applied to categorisation or over illustrations or pictures.

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.

Specific/[Use]/[Distinctive]

We can use numbers or any other special feature as a distinguisher.

An example would be: Specific/Content/1

Or: Specific/Semantic/Danger

Typography

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.

Specific/[Use]

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:

Specific [Resolution name] / [Use]

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.

Component Naming

The following is important to keep in mind for Figma.

Figma’s hierarchy to create a component’s path in a library is:

1. Library name.
2. Name of the page where the components reside*.
3. Name of the frame where the components are located.
4. Component name.

Resulting in:

[1] / [2] / [3] / [4]

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:

[Name] / [Variant] / [State] / […]

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:

• Action
• Content
• Input
• Navigation
• Feedback
• Overlay

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:

• States − Default, Active, Focus, Error, Disabled.
• Scalability – it’s built in a way that the component can scale, be it with the content or manually (auto layout and constraints).
• Variations – can there be a variation? Documenting when each variation is to be used and, according to this, change any relevant aspects (when to use, positioning, action...).
• Positioning – should the element be located in a specific place? If so, this should be accounted for in the system.
• Behaviour – animations, transitions, order of appearance…
• Anatomy and content – if we talk about components or elements that are part of a component, we must detail them so that everyone using the design system can access their documentation directly and understand how they behave. It’s also important to take into account if these elements can be replaced (variations).
• Content overflow – this is the most present aspect to take into account when detailing a component because it will always appear whenever there is text. How is the content, the text, growing? Is overflowing the result of any previous aspects (anatomy, positioning)?
• Action – is the component always linked to the same action? Example: Close Modal ❌ - it can store data, not store it, give a warning that data is going to be deleted. Or, for example, the submit button always has the same appearance, it implies safe data and has specific action.
• “When to use” for components that aren’t basic, but which are used for a particular reason. Example: Sheets.

The aim of the checklist is to make the decision-making process easier for all parties that work with the system, from designers that use the system to developers that implement it.

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.