Safra Design System
Unifying standards and processes to ensure consistency, agility, and identity in Safra’s digital products
Client
Design System, Ui
Safra Bank
Year
2022
The Design System is a set of interconnected standards and shared practices, organized coherently to achieve the goals of digital products.
The standards define the recurring elements we combine to create an interface: user flows, interactions, buttons, text fields, icons, colors, typography, and microcopy. The Design System is an environment where we choose to create, capture, share, and use these standards—especially when working as a team.
Our goal is to create a document with consistent, easy-to-use elements, focused on empowering each Safra team, reducing misunderstandings, and accelerating processes.
1. Preparation
Before working directly on the document, it is important to understand the culture, real needs, strengths, and weaknesses of everything that revolves around our Design System.
This stage also involves compiling essential data that will support future decision-making.
We start by mapping all the main active fronts within Safra, each with its own particularities and business rules.
What do we notice?
We noticed that among the many interface component inconsistencies within Safra, they visually fell into two main styles: one with an elegant, minimalist identity, and the other with a more retail-oriented identity.
Finding only two visual patterns across so many products and interfaces is great news—our mapping has already given us a clear direction for how we will move forward with component development.
Although we were able to narrow down the visual approaches, we also found a large, inconsistent variety of colors, which will require a deeper study to define the purpose of each one.
2. Methodology
At Safra, around 40 products were mapped—each with its own component standards.
To implement the Design System and bring autonomy, speed, and consistency to each product without losing its unique visual identity, we adopted the concept of the Design System Core.
The Design System Core functions as an umbrella for other libraries that may emerge in the future.
Starting with Safra PF, we will create a parent library with structured rules and guidelines for creating and modifying components both within and outside the Core.
Tokens
Design tokens are attributes of a component. They are design standards that are more descriptive and less tangible—such as styles or colors for iconography and typography—generally used to create a certain aesthetic and strengthen the emotional connection with a product.
Tokens are at the core of the Design System—they are the styles that keep the system scalable and consistent. Moreover, we use these attributes to give all Safra products their unique visual identity.
The items inside the token are:
-
Brand (harvest)
-
Colors
-
Sources
-
Grid
-
spacing
-
Iconography
-
Images
-
shadows
-
illustrations
-
Tone of voice & microcopy
base components
They are functional patterns, tangible building blocks of the interface. Their purpose is to allow or encourage certain user behaviors.
Components are built using tokens and follow the standards and guidelines defined by them. It is important to emphasize that the components that fit here are not complex, such as cards, footers and modals, but buttons, tooltips lists and etc.
Here are stipulated minimum rules for each element, but aiming at the independence and identity of each product, the components can be styled if necessary.
The items inside the token are:
-
buttons
-
Tooltips
-
Inputs
-
Datepicker
-
data table
-
Accordion
-
badges
-
Buttons Sheet
-
Filters
-
list
-
Loading
-
navbar
-
paginator
-
Indicator
-
Selection Controls
-
Tabs
-
stepper
-
switches
-
Dotnav / Slider
Team components
Has components are by-products of the design system. They are libraries that hold all elements and tokens with minor modifications in order to meet the individual needs of that product.
Here we also find the complex components like Card, Banner, Modal, Header, Footer and etc.
There is only one core token and only one base component, but when we talk about team components, these libraries can exist simultaneously, each serving its product.
There is only one core token and only one base component, but when we talk about team components, these libraries can exist simultaneously, each serving its product.
Not in DS
Components for occasional use.
Here we enter the scope of exceptions, it is important to have a dynamic and realistic view of the Design System, we will always have components to be created and modified, but there are occasions where the component is built with a single functionality and for a single product._cc781905-5cde -3194-bb3b-136bad5cf58d_
Understanding that we will have exceptions is building a healthy scenario for adherence and an organized environment where we can even generate data on which products are not following the Design System.
Understanding that we will have exceptions is building a healthy scenario for adherence and an organized environment where we can even generate data on which products are not following the Design System.
3. Processes
A glimpse into our work processes, tools, and frameworks that we need to keep aligned throughout the project.
discovery
DISCOVERY
Discovery clarifies the potential and relevance of a new feature and, at this stage, we decide whether or not to adhere to it.
This activity can be performed by anyone on the team, designer, front-end developer or product manager. Here surveys, request screening, interviews, product and system analysis, discussions with influential partners in the team are done.
design
DISCOVERY
Discovery clarifies the potential and relevance of a new feature and, at this stage, we decide whether or not to adhere to it.
This activity can be performed by anyone on the team, designer, front-end developer or product manager. Here surveys, request screening, interviews, product and system analysis, discussions with influential partners in the team are done.
Homologation and handoff
DISCOVERY
Discovery clarifies the potential and relevance of a new feature and, at this stage, we decide whether or not to adhere to it.
This activity can be performed by anyone on the team, designer, front-end developer or product manager. Here surveys, request screening, interviews, product and system analysis, discussions with influential partners in the team are done.
Design Documentation
DISCOVERY
Discovery clarifies the potential and relevance of a new feature and, at this stage, we decide whether or not to adhere to it.
This activity can be performed by anyone on the team, designer, front-end developer or product manager. Here surveys, request screening, interviews, product and system analysis, discussions with influential partners in the team are done.
Build
DISCOVERY
Discovery clarifies the potential and relevance of a new feature and, at this stage, we decide whether or not to adhere to it.
This activity can be performed by anyone on the team, designer, front-end developer or product manager. Here surveys, request screening, interviews, product and system analysis, discussions with influential partners in the team are done.
QA
At this stage, the goal is to ensure that the component works correctly, follows the approved design, and is free from visual or technical issues. The verification includes functionality testing (interactions, clicks, navigation), layout review (colors, sizes, spacing, typography), and compatibility checks across different devices and browsers. This analysis ensures the component is ready to be integrated into the final product without negatively impacting the user experience.
Dev Documentation
This stage aims to ensure the component functions as intended, aligns with the approved design, and is free of visual or technical flaws. The process involves testing functionality (interactions, clicks, navigation), reviewing the layout (colors, sizes, spacing, typography), and verifying compatibility across various devices and browsers. This thorough check confirms that the component is ready for integration into the final product without compromising the user experience.
Publication
DISCOVERY
Discovery clarifies the potential and relevance of a new feature and, at this stage, we decide whether or not to adhere to it.
This activity can be performed by anyone on the team, designer, front-end developer or product manager. Here surveys, request screening, interviews, product and system analysis, discussions with influential partners in the team are done.
4 Versions
The Design System will be initially created based on Safra individual como global brand. Next, the specific needs of each child product of this brand will be added.
Each case will have the breakdown of the necessary versions, according to the diagram on the side.
The versions to be created will be for desktop / mobile, retail / refined and light / dark.
Nomenclature
To be descriptive enough, a tokenized language that incorporates taxonomy and typology needs many levels. Enough levels to organize them into groups and serve all the products involved in this project.
Different systems apply levels in different ways.
Due to the complexity and importance of the nomenclatures for the success of the process, it is crucial that the chosen scheme is a joint decision between the design and development teams.
design principle pyramid
The Design Principles Pyramid is a Canvas to help define the principles of our Design System. It is a tool where we can organize the alignment between teams about what the Design System is and parameters for the success of the components.
13 participants
3 hours from WS
200 sticky notes
Design System Workflow
Persistent Epic
The persistent category represents the work we are continuously engaged in:
-
Visual style, including color, type, spacing, sizing, iconography, and more
-
UI components to fix, enhance, deprecate, or add
-
Technical architecture to improve testing, build tools, app integration, and other technical aspects beyond the library’s source code itself
Formative Epic
DISCOVERY
Discovery clarifies the potential and relevance of a new feature and, at this stage, we decide whether or not to adhere to it.
This activity can be performed by anyone on the team, designer, front-end developer or product manager. Here surveys, request screening, interviews, product and system analysis, discussions with influential partners in the team are done.
Epic of growth and change
DISCOVERY
Discovery clarifies the potential and relevance of a new feature and, at this stage, we decide whether or not to adhere to it.
This activity can be performed by anyone on the team, designer, front-end developer or product manager. Here surveys, request screening, interviews, product and system analysis, discussions with influential partners in the team are done.
Conclusion
The implementation of the Design System at Safra begins with a detailed diagnosis of existing inconsistencies and patterns to establish a solid, centralized foundation — the Design System Core — serving as a reference for all teams and products. This framework aims to balance autonomy and standardization, speeding up processes and ensuring visual consistency while preserving the unique identities of each solution. With clear guidelines, well-defined libraries, and alignment between design and development, the goal is to create a cohesive ecosystem that enhances collaboration and strengthens the user experience across all touchpoints.
