Case study: The design system has evolved
How a team composed by a Design System Ops continued the story of Quero Education’s design system
![A big white “Z” stands out in the middle of the image with the title “Zilla” also below.](https://miro.medium.com/v2/resize:fit:700/1*tl4eahdOAOf6jawVWuHMwA.png)
In the phases of confusion and construction, we started the operation of Zilla, the design system, with a very small team and, later on, we had the support from the Design Guild to materialize the system. Each step from that journey brought us to an inversion of the responsibilities, which before was exclusive to the guild, and later governed by a dedicated squad.
Starting the building process of a design system is confusing, full of uncertainties, but it’s also fun. Even with so many challenges, it’s when, in fact, we learn how to build — as a team — a product which will guide the others.
From atom to atom, from molecule to molecule, we got to the matter we wished for so long: Zilla.
And, among this alchimia, we acquired the element that was missing to the maintenance and to follow up on the product. A brand-new role in our organizations, but also so important to the product and business, has emerged: the design system ops (if I do say so myself, my own role at Quero Education).
In a squad composed also by other developers, creating the design system ops role is to guarantee that the documentation and the process really happen and that the design system fulfills its main goal. This is the moment that an alignment between expectation and reality happens and that ROI is really going on.
Accepting this challenge means to give the best so the design system keeps meeting everyone’s needs: designers, engineers, users and the company.
From the reagents to the matter’s transformation
At Quero Education, we have a team called Design System, which is part of the Platform tribe. This tribe is responsible for the global technology vision inside the company (or even in the group of companies Quero owns nowadays).
The Design System squad needs to understand if the tokens used keep making sure the good functioning in all the stacks used in the company. One of the practical results was to guarantee, for example, the color changes for the Quero Bolsa website, after a rebranding process.
Having a squad focused on resolving these questions results in keeping close the relationship between the Design and Engineering teams — which was nonexistent, historically. Also, participating in the process actively, beside the engineers, reflects in something positive:
you start thinking not only as a designer, but as an engineer as well
In my opinion, the energy focused in this relationship as well as leadership skills are needed for someone in the design system ops position and, in Quero’s case, it showed to be ideal to guarantee Zilla’s operation.
Designing flows
We developed good practices to ensure the design system’s maintenance. Essentially, we created three different flows in order to decide, create or edit and finalize components. In each of the cases, the goal was to question the needs or to present new stages to be executed.
Frequently, the creation of a new component would be something important just for one squad and wouldn’t reflect in a global use. Based on a similar situation, we defined the first governance flow: decision. We tested many different flows together with the team, but the one that presented better results was inspired by Vanilla Pattern.
In this flow, it’s possible to identity if a change converges into:
- The creation of a new component;
- The edition of a component that already exists or;
- The development of something locally.
In order to create a new component, it’s necessary to follow the same edition flow of components that already exist. Both Front-End and Design Guilds need to validate the solution inside the flow in which was built together with those areas.
After the code review, it has to go through the validation flow, in which the storybook and the design library need to be approved by the engineers and designers, respectively. The result of these validation steps is the documentation, which will register the whole process.
The consequence of an active participation of a squad and a design system ops is the maintenance of a design system which finally can be considered global — without any loose ends, operating as a product should operate.
Avoiding clandestine coding
It doesn’t matter how mature a team or the process might be; old habits might come back. At Quero, even when we were more thorough and better supported regarding the design system, it was inevitable to come across pirate code.
Due to a period without process and governance, we bumped into three different Zilla’s versions in the Engineering side. Without a central member or team to check the process, two teams started developing their code over copies of the original design system. Again, it was clear for us that, if a team doesn’t follow the pre-defined parameters and flows, it’s natural that a clandestine code might appear in an Engineer team.
With a tribe and a squad defining global patterns, we expect that cases like those should be reduced in a drastic way or even disappear. And, probably, its benefit will be so clear that the company will comprehend that the design system is a product that helps everyone.
To be continued…
Synergy was the first ingredient we understood the design system needed to have in the beginning of this process. Therefore, while the design system team, which a design system ops is also part of, works to keep the Zilla’s operations, the rest of the squads understand its importance to design the product and to make it tangible.
And now that we went through so many phases, with so many flaws, stumbles and lessons learned, it’s time to evolve little by little. Following the process means also avoiding to act impulsively and understanding that the reason Zilla was born is that, from atom to atom, we will keep improving our products and, consequently, making the user’s life easier.
This article was originally published in Portuguese: