How working with it made me learn more about people than components

Illustration showing multiple hands dragging components to multiple screens

Illustration showing multiple hands dragging components to multiple screens

Overview

My role

QuintoAndar is a Brazilian real estate startup that grew exponentially in 2019. It needed a robust design system to scale fast sustainably while focusing on accessibility from the beginning.

I was the only designer in a squad of 4 people. I had the help of a more experienced designer at the beginning of the project.

Goals

Impact

This is a translation of the article posted on Medium. Its content was presented at ILA 2019 with my colleague Ana Cuentro, at ILA Redux, and Product Camp 2019 in São Paulo.

Creating a component system goes beyond making its parts and promoting their everyday use. It's about uniting teams around a common visual language. As they intersect so many areas, Design Systems involve hundreds of difficult decisions. At QuintoAndar, we make this decision-making easier by focusing on inclusion. However, this was not obvious from the beginning. When we started our work, we had only a Sketch file with our main symbols. Few were implemented on code and had documented rules. It was common to see the same component being applied in different ways, which was an obstacle to scaling the design and engineering work and could compromise our growth as a startup.

How our Design System was born

Despite its name, Design Systems don't survive on designers alone. In our case, the movement to "organize our house" started small, but organically. The design team organized the symbols in Sketch at the same time that the engineering team set up a group to share components they've created. This started to bear fruit, but there was no point in the two areas solving their problems in isolation, focusing only on their disciplines. Thus, the Design Operations team suggested the creation of a multidisciplinary team focused on building Cozy, our Design System.

Image showing screens from Cozy documentation, our Design System

Image showing screens from Cozy documentation, our Design System

Cleaning the house

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 mapped all QuintoAndar's product pages to highlight any inconsistencies, from colors to interactions. We then interviewed designers, developers, product managers and involved them in Design Critiques and feedback rounds on Slack. After this research, we prioritized what made the most sense for our context and planned the releases.

New challenges

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.

Changing strategy

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). We decided to focus on the following challenge:

<aside> 💡 How might we empower design and engineering teams to think systemically and strategically?

</aside>