Cozy QuintoAndar Design System

We mapped all QuintoAndar's product pages to highlight any inconsistencies, from colors to interactions and with the help of other UX professional, we've interviewed prospective users of the design system: designers, developers and product managers from different squads. We concluded that:

• Designers struggled with the symbols in our Sketch template organization
• Developers had difficulties to find and reuse code and kept building new components
• Designers were not aware of the rules to use colors, typography and components in general

It seemed that forming a centralized team fully dedicated to implementing Cozy was all we needed to organize cross-platform interactions and ensure consistency.

We involved them in Design Critiques and feedback rounds. After this research, we prioritized what made the most sense for our context and planned the releases.

We were able to standardize some components; however, we faced other obstacles:

1. Our team process was not fast enough to meet the demand of the 20+ teams;
2. We had low engagement and adoption of already standardized components, sometimes because teams didn't know it was released or because they didn't know how to use it;
3. Our components weren't taking into account all accessibility aspects.

We learned that our component decision process shouldn't be something imposed (the infamous top-down decision-making).

It was not about having a larger volume of components at high speed, but we needed to include more people in the process. That means providing the necessary tools for everyone to participate in building components (to achieve volume and speed) and decision-making (to get adoption and engagement).

It's no use taking isolated actions to make interfaces accessible. We have to teach people to think and apply accessibility.

One of the most commonly used buttons on our product did not pass the minimum contrast of text and background recommended by WCAG, it was not easy for people with dyslexia to read and had a touch area that was too small for mobile devices.

By standardizing components following WCAG guidelines, we were able to show teams what to consider when designing accessible experiences. So the process starts to get more organic.

Every page has a table describes all states in a visual manner and prevents designers to forget to design a specific status:

1. An anatomy image describes the spacing between elements inside components
2. Use cases describe what's the intent of the component and what should not be done
3. A table shows the different variations of the component and when to use them
4. A list of do and don't also follow
5. The status of the component clearly states if it's already implemented

The spaces are built onto a scale of multiples of 8.

We started designing options on Sketch. Then we would do a Design Critique where designers and developers would give their opinion about it. The component moved to a status where it would be on the playground where designers could try to use them on their design and test with real users and see if it was working well.

Components like alerts had 30 variations. We gathered them all and defined rules, eliminating variations not needed. We invited other designers to critique on it and the accessibility experts to review the requirements.

Before releasing the component we invited teams to test them first for some days and let us know any struggles or edge cases. This mechanism helped us release components that were adopted faster.