Design systems.
 
FIRST STEPS

After having worked for more than two years with Sketch we decided to migrate all our libraries to Figma, Sketch had become somewhat slow and unstable, also the synchronization of the libraries when we worked several designers simultaneously used to give problems. The big challenge came when we realized that the best way was to start assembling all the components from scratch in Figma. It was quite a challenge, but the results ended up proving us right.

 
 
MY POINT OF VIEW

Much has been written about design systems and from my short experience I think it is of great importance to find the balance between usability, consistency and scalability of the components avoiding that this modularity ends up destroying the creativity that makes the difference.

 
THE BASIS

After having been working with the Sketch libraries we detected several problems that in some cases due to software limitations and in others due to errors in the base of the libraries had generated the need to rethink at a structural level the organization of the entire library and how the different files behaved.

  • 1.Contributing to creativity

    Think of modular and flexible components that contribute to its transformation and creativity. Nothing is definitive and can be modified at any time.

  • 2.Components will never walk alone

    Always code. All components have to follow the respective guidelines and iterate with the development teams so that they are aligned with their code.

  • 3.Communication

    It is very important for the maintenance of design libraries the communication between the different members of the design and development team.

 
THE LIBRARY

We usually work with three different master libraries for each of the platforms for which we design: iOS, Android and Desktop. Each of them with their own particularities, since for iOS we try to follow apple style with Human Interface Guidelines, and for web and android we work with Material design.

All of them have to maintain consistency in terms of color styles, icons and different elements such as chips, labels, badges... so the structure of the libraries follows the following hierarchy.

 
1.Root libraries (Atoms).

At this point the aim is to establish a balance between the brand guides and the styleguides of the different platforms we work with, so in terms of colours, fonts and icons, different libraries were established as the basis. The web and and android icons and fonts are managed from a single library by following the material design styleguides.

 
 
2.Elements library (Molecules).

This library is the basis of the components, so each of these elements are not useful on their own, they need a context to provide value, so they are all grouped together and ready to be called from the native libraries of each platform that we will build later.

 
 

Each of the pages is divided into 3 artboards that group the variants for each of the platforms. For example for chips we have iOS, web and android. Each group of components is structured around a master or parent component in different sizes that serve to manage the main format of all its variants/children organised hierarchically by type, class and size.

 
 
3.Device libraries (Organisms).

Once the hierarchy of elements has been defined, we can begin to assemble the different components of each of the platforms according to their corresponding styleguides. It is important to be clear that depending on the device, the different tokens have a different behaviour, so the screen size of the device must be taken into account.

 
 

The structure of each of the artboards of the different pages consists of an upper row in which the master or parent variant is defined with all the necessary elements to represent all the variants of the cell.

 
 
4.Sample pages (Templates).

Our templates consist of a sample page of each of the sections of the application. Dashboard, Contacts, Accounts, Opportunities, Tasks... from each of these templates we can obtain some basic components to be able to work in the different projects and combine them to obtain as a result the specific pages and flows of each of these.

 
 
5.Pages.

Our templates consist of a sample page of each of the sections of the application. Dashboard, Contacts, Accounts, Opportunities, Tasks... from each of these templates we can obtain some basic components to be able to work in the different projects and combine them to obtain as a result the specific pages and flows of each of these.

 
 
THE CHALLENGES

Broadly speaking, this is the structure on which I have based the team's libraries to work in a synchronised way, although it is important to stress the importance of fluid communication between the members of the design team to minimise human errors derived from the duplication of components or the wrong application of components.

It is important to note that a design system is not a project that is started and finished, it needs constant maintenance, open to variations and changes according to the needs of the product. The challenges I would like to start working on revolve around the use of tokens and generating components capable of generating accessible and understandable flows for all users.


 
MY ROLE
  • Develop and maintain the design system

🧩