Restructuring the tokens of the Locaweb Design System
Company:
Locaweb
Role:
Product designer
Company:
Locaweb
Role:
Product designer
The Locaweb design system was built on top of Vuetify to speed up development, but it ended up producing components and tokens that were hard to scale and lacked clear documentation. In this project, my role was to review and improve these elements, bringing more scalability and efficiency to designers and developers.
The first analysis consisted of cataloguing every design token and understanding its use case within the design system. In addition, using Figma analytics, I was able to observe the number of insertions of styles, variables and components in the file, as well as the number of detaches.
Looking at color usage, I noticed that in every palette at least one shade was never used, and due to the lack of documentation there was no real guidance on how and when to use each one. With the sole exception of the neutral palette, all the others were only used for microinteractions in components, but without names that indicated that. I also noticed that some shades used as text backgrounds in components did not have enough contrast according to WCAG guidelines.
The responsiveness of the typographic scale was poorly executed. Instead of working with relative units (such as rem or em), as is conventional, and reducing the value per breakpoint, texts simply dropped one step down the scale: if on desktop we had 40, 32 and 24 pixel texts, on mobile the one using 40 became 32 pixels, the 32 became 24, and so on.
This reduction resulted in texts that were far too large on mobile devices, and also in the last two scales ending up the same size, since the last one had no smaller value to fall back to.
However, the biggest problem I noticed regarding typography was its practical use. Within the design system itself, some headings were made of different sizes, and products had no consistent pattern between them. This was due to the unclear naming (font-size-xl, lg, md...) and to the lack of any indication of what an h1, h2 or other tags should be.
Finally, the design system also provided the same scales for both brand typefaces, Ubuntu (primary) and Open Sans (secondary), but the latter was rarely used in projects — some designers did not even know it existed.
For the second analysis, I prepared a script and ran an individual interview with each of the designers who were already using the design system in their products, aiming to understand their perceptions about token usage.
The research confirmed some of the data I had already collected in the first analysis, but also brought new findings:
Little use of the secondary color
Designers never used the secondary color anywhere in the product interfaces, and since there was no documentation, they could not say what that palette was for.
Difficulty understanding typographic hierarchies
Designers had different understandings of when to use most of the typographic scales. There were different definitions of what the page title, subtitle, and even a section heading should be.
Unused "light" weight
The file provided the "light" weight for each of the eight scales, and even with very few insertions seen in analytics, every designer said they never used it and did not know its use case.
Uncertainty about using gray scales in text
Due to the lack of standards and recommendations, designers had different understandings of how to use the gray scales in text to support the hierarchy of headings and paragraphs.
The third and final analysis involved a direct comparison between Figma and code for every design token and component.
I first did this survey on my own, to form my own views initially, but in the end I decided to meet with the person responsible for the design system front-end development, both to collect more information and to hand over the points I had gathered.
Components with different names
Although designers and developers used the same components, some of them did not share the same name, as was the case with Dialog for designers and Modal for developers.
Typographic scales with distinct names
While designers recognized the scales by a certain naming in Figma, the design token naming actually used by developers was different.
Elevation differences between design and code
The design system file in Figma provided some elevation levels (shadow styles) that were completely different from the tokens, both in naming and in value.