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)
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.
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.
Example of how the team, Product A and B were before the Design System multi brand initiative
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.
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."
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.
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.
Upgrading component to Team component or Design System Core
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.
Design System: from tokens to pages
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.
Theming proccess
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.
Content example inside the 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.
Figma files structure and imports
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.
Figma libraries and component page
Example of a component page
Preview of the website documentation (in construction at the time)
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.
Design System team models scheme
Team Models for Scaling a Design System by Nathan Curtis
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
Design System and Product team collaboration scheme
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.
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:
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.
