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

Jan Klever
Bootcamp
5 min readJun 21, 2022
A big white “Z” stands out in the middle of the image with the title “Zilla” also below.

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.

A black man with headphones has one hand on his chin and the other on the trackpad while looking at the screen.

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.

Zilla decision flow in Portuguese with a series of steps but it is not possible to read in detail.
[DWS — 01] Zilla’s decision flow, inspired by Vanilla Pattern

In this flow, it’s possible to identity if a change converges into:

  1. The creation of a new component;
  2. The edition of a component that already exists or;
  3. 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.

Zilla creation and editing flow in Portuguese with a series of steps but it is not possible to read in detail.
[DWS-02] Zilla’s component creation or edition flow

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…

Group of men with five people standing and one person sitting in the working environment while looking at each other.

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.

Bootcamp
Bootcamp

Published in Bootcamp

From idea to product, one lesson at a time. Bootcamp is a collection of resources and opinion pieces about UX, UI, and Product. To submit your story: https://tinyurl.com/bootspub1

Jan Klever
Jan Klever

Written by Jan Klever

Digital Designer for Education

No responses yet

What are your thoughts?