Case study: From confusion to building a design system
In this initial chapter, we gathered the first steps and learnings from the ones who created the Quero Education’s design system
If you have already participated in the creation process of a design system, you know that it’s not easy at all. At Quero Education, we lived through different phases while building our design system, and today, with a bit more clarity, we managed to identify three phases of this process and name them as: confusion, construction and, currently, the continuation phase, which I intend to give more details soon.
Before we start, design systems are systems (as the name already suggests us) which assemble principles, patterns and libraries which easen the development of products.
In order to get to the phase we are in, two very important things were needed: a fully-operational marketplace and a company seeing the real importance of a Design team.
And again: it wasn’t easy. I anticipate that, from all the lessons learned, the most important one was to understand that what a product designer wants is not always what the stakeholders and the Engineering team need.
What did we have in our advantage? The Quero Education’s directors were on our side and saw the need of developing a Design System almost at the same time our team did. It would have been much more complicated if we had to work hard to convince C-Levels as well.
Moreover, from component to component, from the buy-in to the governance, there have been around two years in order to be sure that the Design team had concluded an important stage: the complete “zillage” of all the marketplace’s pages! That is, we had “zilled” (from the non-existent, brand-new verb “to zill”); we had completed the conversion of all the old pages to Zilla — the Quero Education’s design system.
And, yes, for us, the design system is a verb; it’s action.
Confusion: preciousness versus pragmatism
Inconsistency. This is usually the reason a team starts thinking about developing a design system. And this was our motivation too: when there’s no standardization, every product designer tends to design the page in their own way. The result was clear for everyone at the company: what our biggest product, Quero Bolsa, had the least was coherence when we thought about the website’s components.
The inconsistency used to affect our relationship with the Engineering team. The creation of each page used to cost us a lot, since they used to be developed by different designers, even if the original intention was different. For both engineers and designers, the feature implementation duration was longer than it should have been.
At the end, the stakeholders understood what the user, the most affected from the chain, really needed. Because of that, having the buy-in from the directors was easier. So the Product Design team had the first decision to make: build the design system from scratch or refactor everything. At that time, the majority of the team voted for creating a design system from nothing. A self-evaluation is welcome here: when we chose the hardest way to go, it’s necessary to admit we opted for preciousness too.
When we started to think about our design system, the first task to be done was to understand the intersection point between each of the areas which would depend on it — such as Product, Engineering, Product Design and Branding — and how they would relate to each other. However, if we review the building process today, it’s clear that we started for the same motivation every company starts: the designer wanted to build something — even without pragmatism, in that moment, there was a will of making it happen.
The inventory story
In Quero Education’s tech team, this story is very famous. One day, the designers went to a coworking office and isolated themselves for one week to elaborate the first stage of the Zilla development.
The process was old-school: a physical (and not sustainable at all) inventory was created. Quero Bolsa’s pages were printed and attached to the wall so all the existing components could be mapped.
This was the first construction phase, as a design system is built from a specific need, and ours had already been pointed out.
With all the visible pages, needs and problems, the team started listing everything to laterly draw what would be necessary for a library. It was in that phase that the Zilla’s initial principles were developed. Afterall, without them we wouldn’t have a design system, but only a new library and this wouldn’t be the way to go if we wanted all the problems to be solved at last.
It was time to decide beyond the cards and buttons’ finishing. It was the moment to put together the construction planning, the branding and the accessibility. From there on, we kicked the second phase off, named as construction.
Thus our team gained what any other tech team had until then, the Design Guild’s day, that is, a weekly day dedicated to resolving global problems. In that specific case, “zilling” (again, the new verb) the pages of our marketplace was one of those tasks that all the designers had to work on.
Not always a bed of roses — not at all
A design system is a product — and that’s how we saw it and how, in our opinion, it should have been seen from the start.
Unfortunately we didn’t see Zilla like that in the beginning, when a group of designers decided to meet to make it happen in the inventory week. The result of that immersion week was the construction of a design system for designers and not for engineers, and not for the company.
Today, together with the lessons learned, after the mistakes of the beginning, we accepted that first we should have understood if that project would have resolved the problems and not only thought about the perfection of a design system. In that moment, in that week, something huge was built — a robust design system that overflowed from the capacity it had by then.
That immensity of a project never would provide what we needed and the Engineering team, which would use the design system together with us, would never be able to use it. We forgot that, in order to build something that big, we should have included the Engineering part. And, no, nothing from that team had been done. Something was missing — the synergy between the Design and the Engineering teams as a goal of our huge project.
And it was pointed out not only by the Design Guild, but by the other stakeholders too. In the end, we were asked why we didn’t bring a real solution after the immersion. The problem had been solved only by the designers and, in order to be solved globally, we should have done it little by little, as a team, and not building a lab monster.
An egg, a lizard, and a Zilla
When we launched the MVP, we also launched our how-to guide, that is, how we should have done the whole process. The design system robustness was in accordance with its name. If we had started from the beginning, little by little, we wouldn’t have faced so many problems while executing it. In our favor, there was only the constant iteration environment the company breathes.
Zilla, our little huge monster, was not planned to grow as a product. If it had been, we would have nurtured the egg, raised a lizard so, after it matured, it would have been launched as a real Zilla.
Thus, even if Zilla didn’t evolve ideally from the beginning, at least our team evolved organically to step up on the right way of building our design system.
Process, alignment and documentation: they were the foundations of the next stage, which I will tell you soon. This is because a design system, as any other good product, doesn’t have an end.
This article was originally published in Portuguese:
