Illustration showing multiple hands dragging components to multiple screens
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.
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.
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
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.
We were able to standardize some components; however, we faced other obstacles:
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>