Soluto Design System, from the eyes of the design team

2020 has been a weird year, no doubt about that. In March, we went to work from home, and officially became a remote studio. This new normal made us reflect on our way of working, the methodologies, the tools we used, and the communication between the team. One of these reflections was quite clear: we were far away, but we should be more together and interconnected than ever. For this reason, amongst others, we decided to rethink our product design process and created a design system. And also, halfway through the process, we switched to Figma.

One of the main reasons for switching to Figma was so that the entire team could work on the same file, design collaboratively, and make decisions together. This change has led to a series of improvements in the design process, one of which has been the creation a design system. Once the whole team was already working collaboratively on Figma, designing and implementing a design system not only helped us to collaborate even more, but it also helped us to think in the same way, to align our decisions, our work process, and our language. We were finally beginning to discover the magic of thinking together with developers, and our team was staying more focused, more connected, and more aligned.

And so Soluto, Soluble's design system, was born, with the aim of optimising the complex process that is the design and implementation of a digital product. A design and documentation system that allows the interface design process between the design and development team to be more fluid. We established a shared vocabulary between the two teams that helped us to be more consistent across our projects, and we found that consistency makes a very positive contribution to usability.

We have been putting this system into practice for several months and designing in Figma. Here are some reflections and details of the process so far.

A design system is the foundation for scalability, efficiency, and consistency. It increases speed and reduces failures when applying the design because it is a single source of the truth, and of project documentation. It requires maintenance and updating: the design is never finished, but is always evolving, according to the needs of each project.

Soluto has not only helped with coherence and communication between the design and development team, it has also contributed and added value when starting a new project for some of our clients.

It allows us to have a shared starting point. It is very useful to have a file which can be used as a "base", to modify and adapt to each project that we work on. It allows us to work faster, and much more efficiently. In other words, it allows us to increase speed, and maintain consistency, no matter how complex the project.

We have already outlined the motives and objectives, now let's go into more detail.

Soluto is structured in the following way:

Styles are the set of elements that define a brand and its design system. They are made up of colours, typography, effects, and patterns. These are all elements that help to reflect the visual identity of each brand.

When we start working on a new project and its design system, incorporating the colours of each brand into the system itself is key. This helps us to make each system unique, and reflect the brand personality throughout the interface.

When defining the colour palette, it is very important to consider accessibility. Not all colours have to be accessible, but most must meet this requirement. For this reason, we must have a wide set of accessible colours in our palette so that we can use them without issues in text, components, and backgrounds of the interface.

In each design system we group colours according to the following categories:

• Brand colours — These colours are associated with each brand, they are named according to their importance (primary, secondary, tertiary…) and they are the colours that give the product the brand's personality.
• Basic Colours — Basic colours are made up of a palette that ranges from white to black. We keep this palette in every project, and we call them Basic Colours.
• Support colours — This is the group of colours that help us to communicate the generic messages of a product (success, warning, error).

Another key point of each design system is typography. Through typography, each brand can reflect its personality and visually communicate in a fluid manner.

Defining typography styles helps us to be consistent at each breakpoint, provides hierarchy, and helps the presentation of the entire interface. We usually use a maximum of two fonts in each project, and the least possible amount of different font sizes. However, this always depends on the type of project, and on the brand.

One of the key points when applying text styles to different breakpoints is that the same styles between breakpoints must have the same name. For example, an H1 heading in 1024 resolution should also be H1 in the mobile version. This greatly assists the work of the development team, and at the same time helps maintainability and consistency through the different resolutions of a website or product.

Style names are named as follows:

[F1] / [Breakpoint] / [Weight] / [Name]

Effects refers to layer styles that are present in the brand system, supporting the coherence and tone of the brand. Here we categorise, document, and define the necessary effects to achieve different “lifts” in buttons or modals, effects such as shadows and blurs.

They are named according to the effect, following a numerical sequence from the flattest to the highest. Example: shadow-01

In order to design in an orderly fashion, and maintain balance in the products that we create, we are guided by grid structures.

We categorise them as viewport grids and space grids.

• Viewport grids — A set of columns that help us organise horizontal space and adapt to the size of each screen. This ensures consistency between layouts.
• Spacing grids — Based on an 8 pixel grid, helping us to measure across each page. Each element on a page must be a multiple of 8; this includes margins and padding on both components and sections of a page. For example, if the only element of a component is the text (buttons), we set the text to a size that is consistent with the rest of the UI and then use padding to determine the size of the component itself. The padding will determine the height and width of the component. There is one exception to this scale: 4 pixels in the cases of small components and margins.

As we previously indicated, Soluto is made up of several elements (or components). These can range from something simple, like a button, to something more complex and detailed, like a modal. We document all the components, and at the end of each project we analyse and discuss, together with the development team, whether a component that has been created for a specific project can be added to the ‘mother’ file that is Soluto. This approach keeps Soluto updated and consistent for both teams, design and development.

Example of a Design System created/adapted to the Dozen product

Soluto is a design system that is constantly updated and growing, but it is also the starting point for each project. We have optimised the initial process of a project to be more agile when creating the styles and components that we need. Now we invest our time in customising and adapting each system to your brand, focusing on the most creative aspects: the redesign of each component, according to the attributes, personality, and values of each brand. We resolve the states and behaviours of each component and we continue to improve to document more, better, and using a language that is uniform and common to all.

Until now, our most common components have tended to be:

• Buttons
• Text fields
• Selectors
• Navigation bar
• Lists
• Tables
• Icons

In some projects, the components are more complex. In those projects, we also have:

• Manners
• Notices
• Forms
• Cards
• Search engines
• Image galleries

We ensure to keep the layout file tidy, using a consistent structure, and correctly named screens. Why? Because this will speed up everything when it comes to sharing, and working with other team members. We create a nomenclature from design that is maintained throughout development, and makes everything work better, as we speak and work in the same language.

Name of the pages and order of the files

We have developed a naming system that allows us to remain consistent across all files and allows all elements, artboards, and pages to be organised, making them easy to find for anyone.

In the same way as we have Soluto for the design system (which serves as a starting point for each project), we also have a template file that will be connected to the design system of each brand. This file is the Soluble — Design File Template, which we duplicate at the beginning of each project. This is where all the screens of a product will be designed, and it contains 4 main pages:

• 📷 Cover — The most immediate way for the whole team to have an overview of the status of each project. We update the thumbnail whenever the project moves to a new phase.
• 💡 Exploration — All the explorations performed to identify the path that will lead to the final design.
• ✅ Design Ready — Screens/flows sorted by version.
• ↳ [FASE]-[breakpoint]-[Version] — These subpages are arranged by version to help maintain version control and mark client deliveries. We often add emoji 🚧 to signal the pages that we are working on before sharing it with the client. And of course, once we share it, the WIP emoji is removed.
• 🤖 Dev Ready — Screens prepared and documented for the development phase. Go!

Name of screens

Files are organised with the relevant names. We also have some defined rules for naming each artboard of a design. All artboards must follow this nomenclature, from the UX phase to exports and deliverables. Everything must have a consistent name and must follow this naming pattern:

[01.screen]/[01.status]

01.home/01.nav-bar-open

• No capital letters
• Words must be separated by only a hyphen
• There may or may not be status (it will depend on whether or not the artboard in question has various statuses)
• The numbers help us understand the flow of the product and the statuses of each artboard

These rules are the result of iterations that we have performed and tested over the past few months. We may change again according to our needs, but for now this works for us.

At this point, we are still improving and testing what works best for us in each project and situation. It is clear that we are documenting more than yesterday, but we hope that next week we will be documenting even more.

For now, our process is as follows:

• We organise the components in different artboards so that we can have a global vision, at the same time keeping everything organised and easy to use.
• Aside from this more visual approach to organisation and documentation, we also keep more detailed documentation when a component or flow needs particular attention. On the one hand, we document behaviours, micro-interactions, and states in the design system file of each brand. On the other hand, we try to leave descriptions, notes of use, and behaviour when something requires more detail in the layout file where all the screens and flows are located.

We like to be thorough in this documentation process so that our development team can get straight to the point and make our designs real and ‘usable’. We understand product design as a dynamic process, not a static one. For this reason, it is very important that everything is well detailed so that it can be executed as we had imagined it, when we pass our designs to development. As designers, we are the creators of the products, the ones who hold all the information. If we don't have good communication with our tech team, the result will take longer than expected to arrive, and we will make too many detours in the process. Nobody wants that, right?

Thanks for reading this far and for helping us to welcome Soluto.

Maria Martins, UI Designer

PS: This has been all about Soluto, from an interface design point of view. We are reflecting on the design system in terms of its development. We will continue to report on our progress