Superlógica 2022

Structuring a multi brand Design System

Design System, OPS


Superlógica has various products and projects for both desktop and mobile platforms. The company's growth and expansion led to a challenge of maintaining consistency in design and development across different products. To address this, Superlógica began to explore the concept of a Design System.

The first iteration of a Design System at Superlógica was born out of collaboration between the Marketing and the UX team, with two developers and one designer from the Marketing team contributing to the initial draft. However, as Superlógica had more than one product, the Design System needed to be scaled up and adapted to be usable across multiple products.

The Superlógica Design Language (SDL) initiative wanted to create a scalable Design System that could be used across all of the company products, present and future, while accommodating different brand characteristics.

DS Team: UI Designer: Virna Varela, Guilherme de Lima | Development: Wilson Prado, Henrique Corraro, Diogo Righi
Skillset: Design System, OPS
Products: SDL (Superlógica Design Language)

The problem

Superlógica's product teams were affected by inconsistencies in design and development across the products. One product had some components designed and developed and the other was outdated and inconsistent in both technology and user interface. The lack of a scalable Design system and an official team and workflow resulted in inefficiencies and slower decision-making processes.


The goal of this project was to improve consistency and processes across Superlógica's product teams. To achieve this, the company aimed to create a scalable Design System that could be adapted to accommodate their existing products, as well as any future products they may develop, while maintaining their brand characteristics. Additionally, an official team structure and workflow would be established to manage the Design System effectively. By implementing a scalable Design System and an official team structure and workflow, Superlógica could maintain consistency and efficiency across all of their products and improve their overall performance.


We used the Double Diamond methodology to guide this project. The company organized the project using OKRs (Objectives and Key Results) to ensure alignment with their overall strategic objectives.


Courses, desk research, and conversations with both internal and other companies helped us establish our idea initial idea for this project.


Establishing the Design System concepts helped us to structure our base, team, processes and files.


Structuring documentation, figma files for designers, a temporary website for developers and a more well-rounded team to present to the team.


Delivering component libraries and handoffs, presentations, onboarding and team initiatives.

The before state

Before the Design System multi brand initiative, the team lacked a collaborative approach, resulting in inconsistent styles across the products. Product A had started working on a style guide and had a base system, while Product B was highly inconsistent in its design.


To address the challenges of having more than one product with different aesthetics, the team created a multi-brand design system that could be customized for each product. The design system includes a centralized library of design components, typography, colors, and other visual elements that can be used across all products.

Design System Concepts


To start the project, we put together a definition based on the discovery that would guide us throughout the project:

"A Design System is an ecosystem of organizational systems that includes component libraries with coded design semantics and centralized style management. Tokens are semantic style variables that help bridge the gap between design and technology by providing a common language for visual options that can be used to create components. Components are pre-designed elements that can be reused across multiple products and platforms."

Group structure

To address the multi-brand nature of their products, we implemented a group definition, also based on the discovery phase, that allowed for scaling while preserving the teams' creative freedom build on different scenarios.

  • Group 1 - Design System Core: includes the style definitions and components that are utilized across all products.
  • Group 2 - Team Components: this includes product-specific components that product teams can create and share with other squads within the same product. These components are not meant to be used in other products, allowing for greater freedom and flexibility in their design.
  • Group 3 - Not in DS: used for creating components that are specific to a team's needs and not intended for use by other teams or products within the organization.

The components within groups were flexible and could be moved between groups based on their usage. For example, a UI element that was not originally part of the Design System (DS) might need to become a DS component if it were to be reused in the product. Conversely, a team-specific component could be promoted to a Core component if it was going to be used across multiple products.

Although we didn't strictly adhere to the concept of Atomic Design, we found it helpful to establish a basic structure that allowed us to visualize UI elements from the smallest to the largest parts. Tokens were used to store design characteristics to build a foundation, components, templates, and ultimately pages.

DS Structure

Building upon past concepts, we developed our multi-brand system by utilizing global tokens and brand tokens to establish a solid foundation. We then created white label components that utilized this foundation to style their characteristics. This process was referred to as "themification" with each product having unique information for their colors and border-radius, etc.


In our design system, each Figma file category served a specific purpose. We had files dedicated to foundational styles, such as Global and Brand Design tokens. We also had files for Core components, which included both white label and themed components, as well as supportive libraries for icons and imagery. Additionally, we had files for team components. By organizing our design files in this way, we were able to ensure clearer and more specific documentation.

A series of boxes with an example of the content inside each category file. Global tokens: spacing, shadows, etc; Brand tokens: Typography, colors; Core components white label: all of the components with no brand characteristics; Core components Product A: Components with brand characteristics; Support libraries: imagery and icons; Team components - product A: Specific product components; Prototyping: an example of all working together.

Content example inside the files

Importing figma files

To ensure a smooth connection between files, we documented the contents of each file as well as which other files were imported into them. This allowed for easier library setups in Figma when starting a new project.

Component libraries

The component libraries were organized based on platform, and once the components went through the theming process, they were then organized based on specific product. Within each file, each page was dedicated to a specific component, which allowed for more focused attention without generating an excessive number of files. Each component was accompanied by its own documentation, including definitions, dos and don'ts, types, and more. Additionally, component variants were created to enable designers to quickly generate prototypes with greater ease.

An example of a component page: the button page. This image shows possible characteristics, behaviour and handoff.

Example of a component page

Team structure and Workflow


Based on Nathan Curtis concepts for Design System team models, the earlier initiative was more isolated (Solitary), involving a designer from the marketing team who developed the Superlógica Design Language concept while assisting a single product in creating its identity and components. However, as the initiative expanded, it became more centralized. And the future goal would be to establish a collaborative environment where other teams could also contribute (Federated). As a first step, the product teams were responsible for maintaining their team components.

Team scheme

After conceptualizing, the two developers that were on the marketing team, the marketing designer, and myself formed an official Design System team. This team would build components together with the product teams, but the design and documentation would be the responsibility of the DS team. Besides that, the product teams would have the freedom to build their own team components with the help, to design and develop, of the Design System team and publish to other squads

It shows the current state of the collaboration flow. The Design System team provides to the Design system and help other teams build their team components. The product team build their team components and can contribute to the Design System team.

Design System and Product team collaboration scheme

This is an example of the component creation flow: The Design System team designs a Core component, which is reviewed by the entire team. A handoff is then created by the UI team and passed on to the Design System team, who proceed to develop, test, and document the component before publishing it and making it available to the entire team. Squad teams are responsible for designing and developing the team components, which are also reviewed by the Design System team before being published to the team components pack. Finally, the product team can access these components after they have been made available.

Core and team components flow


In addition to the component library, we created various initiatives to involve more people in the design system process and keep it evolving. These initiatives received significant support from other teams, allowing for constant communication and collaborative planning.

Creating a UX Writing guide with the marketing team
Design System Committee meetings with product teams to plan and present results
Design System onboarding, presentations and training for the team
Design System discord channel for questions, discussions and requests


Thanks to the combined efforts of the Superlógica Design System team and the product teams, the project to structure a scalable design system that could be applied across products and platforms showed great promise. The teams were able to achieve significant results, particularly in terms of shifting the company's mindset. Some of the notable results were:

  • he implementation of a unified Design System across all products and platforms resulted in a significant improvement in product consistency;
  • The documentation of the design system was instrumental in enabling teams to work autonomously and more efficiently;
  • The changes we made in our initiatives and team structure have helped to streamline the process of creating and requesting new UI elements;
  • The Design System significantly reduced the time needed for product designers and developers to create new UI elements from scratch;
  • Improved communication facilitated better decision-making between design and development teams.


The project has provided valuable insights into the importance of a scalable design system for organizations with multiple products and platforms, resulting in significant improvements for the product teams. The maturity of the Design System evolved considerably, along with communication, consistency, and processes.

Upon reflection, we identified areas for improvement. For instance, the White Label could be a separate file solely for documentation and copying purposes, rather than nested and imported inside themed components. Instead of a General Core components library, we recommend always separating web and mobile libraries, even if the UI is the same. We also suggest separating variant construction from the documentation page. The technology is always evolving and there are several ways of doing the same thing. It is important to build something with longer shelf life and continue to research for change and improvement whenever necessary.

Moving forward, our next steps would include creating more automated and documented workflows and guides, such as component creation and versioning. The documentation would be made more dynamic and serve as a source of truth on the website. Additionally, we were plan to implement success metrics to measure our achievements as a team and as a product.

Next project: Redesigning a table component ➝