Our design system had several problems that arose when scaling the digital product we were working on. Among them:

• Lack of a clear structure, since the components were placed on a single page in no definite order.
• Limited use cases for components, making it difficult to scale the system.
• Low adoption of the design system, since some developers considered it only as a visual reference, rather than a functional tool from which they could extract code that could be easily implemented in the development environment.
• Accessibility problems in some key components, which were present in almost the 100% of system screens

‍

Research and Development

In the color scale we used previously, problems were detected related to a non-semantic use of color. That is, there were different styles that applied color, but there was no documentation to indicate in which cases one color or another should be used.

In addition, the lack of a clear definition of primary, secondary and tertiary colors made it difficult to choose between them. In addition, the available color ranges were not wide enough to cover all use cases. For example, a less luminous shade of gray was missing for secondary texts or clarifications, as well as a yellowish green suitable for alerts and another shade that could be used in other specific contexts.

‍

As an improvement, we implemented a new color scale in which all colors meet a AA minimum contrast ratio, according to the standards of the WCAG. In addition, a collection of variables was created that organize colors according to their luminosity. For example, within the gray scale, the lighter shade was named semantically as GREY/20.

‍

‍

In addition, each color was linked to a specific semantic use, referring to a primitive token associated with its HEX value. This allowed us to define more clearly in which cases each color should be used, ensuring consistency and accessibility in the system.

‍

‍

As with the color system, we also identified a lack of proportionality and consistency across different font sizes. In addition, there was no clear documentation on the semantic use of the different typographic variations in terms of weights, sizes, kerning, line spacing and other parameters.

‍

‍

To achieve greater consistency in the application of typography within the system, we created a scale based on a ratio of 1,309, using 16px as a base value. This allowed us to maintain a clear and consistent visual hierarchy across all system representations.

‍

‍

We wanted to go a step further and abandoned the old system based on styles to define fonts and colors. Instead, we implemented one more system flexible and scalable, which allowed us to assign a semantic use to each design decision through the use of variables.

‍

A key aspect to solve in our design system is to ensure that each component is accessible. To achieve visual accessibility, we take as a reference the standards of the WCAG.

When evaluating the primary button, a component present on more than 30 screens of our system, we detected that it did not meet the minimum contrast requirement for a CTA, as shown below:

‍

‍

Once we have identified the accessibility and usability problems in the primary button—a key element in any interface, since it guides the user on the action to be performed—we implement the new design variables.

Not only do these variables ensure that the button meets minimum visual contrast requirements, but they also establish a semantic use for the background color in CTA, assigning it as background-button-primary.

The changes applied are shown below:

‍

‍

Work was done on the refactoring of several components, since some had accessibility problems, as evidenced in the case of the button.

Below is an example of the different states and types generated to cover most use cases. In some exceptions, the same types and states were not added, since they weren't needed for that particular component.

In the following sample of button states and types within our design system, visual accessibility problems can be identified in certain states, due to insufficient contrast to meet the minimum AA established in the WCAG:

‍

‍

In contrast to the previous button, we created different states for the component, making sure that each one met the minimum contrast AA According to the standard WCAG, thus improving visual accessibility.

The changes applied are shown below:

‍

‍

In addition to the refactoring of the design system, we hold meetings 1:1 with the team's developers to promote closer communication between design and development. During these sessions, we guide them through the design and explore the possibilities offered by Dev Mode from Figma.

The objective of these actions was to increase the adoption of the design system, not only within the design team, but also among developers, ensuring that they could effectively use it in their workflow.

‍

Design System Adoption Guide

In addition to the refactoring of the design system, we organize meetings 1:1 with the team's developers to promote smoother communication between design and development. During these sessions, we guide developers through the designs and capabilities of the Dev Mode from Figma, allowing them to better understand how to use the available tools and components.

The objective of these actions was to increase the adoption of the design system, ensuring that not only the design team, but also the development team, could effectively take advantage of and utilize the system in their daily workflow.

‍

Design System Governance

To ensure an orderly administration of the design system, we established maintenance procedures and requests to modify it. A single responsible person was appointed, responsible for receiving and evaluating requests from the design and development team, related to the creation or modification of components in the design system.

To adopt or update a component, we define a series of criteria that must be evaluated both in its acceptance and in the prioritization of updating or incorporating new components into the design system. These are:

• Impact of the component: Evaluated according to the number of system screens it appears on.
• Complexity of the component: Measured based on the time required for its update or development.

‍‍

Impact on ROI

In addition to improving the adoption of the design system within the product team, one of the main objectives of a design system is to optimize team efficiency by speeding up development times. Using the calculator for Knapsack and the following variables:

• $40,000 annual cost per employee
• 7 users of the design system
• 20% improvement in the efficiency of the product development process

The result was potential savings of $56,000 annually.

‍

‍

‍

If we translate this impact into efficiency in the implementation of a new component, taking into account:

• 16 hours in component design, coding and maintenance without a design system.
• 10 hours in component design, coding and maintenance with a design system.
• 20 components created in total.

This led us to the following results:

• 320 hours of implementation without a design system.
• 130 hours of implementation with a design system.
• 190 hours saved, which represents an increase in 59% in development efficiency.

This time savings directly impacts the speed of delivery and the optimization of resources within the team.

‍

‍

‍

‍