OPS! Evoluímos nosso Design System

Como um time com um design system ops deu continuidade à história do Design System da Quero

Nas fases de confusão e construção do Design System, iniciamos com um time bastante enxuto o início da operação e, depois, tivemos apoio da guilda de design para materializar nosso sistema. Cada passo dessa caminhada foi nos levando aos poucos para uma inversão nas responsabilidades — que antes eram exclusivas da guilda — para então se tornarem então governadas por uma squad dedicada.

Iniciar o processo de construção de um design system é confuso, cheio de incertezas , mas é divertido. Mesmo com tantos desafios, é quando de fato aprendemos a construir — em time — um produto que norteará todos os outros.

De átomo em átomo, de molécula em molécula, chegamos à matéria que tanto queríamos: o Zilla.

E, em meio a essa alquimia, conquistamos o elemento que faltava para a manutenção e continuidade do nosso produto, um papel ainda tão novo dentro de organizações mas tão importante para o produto e negócio: o design system ops (modéstia à parte, eu mesmo).

Ao lado de um squad composto também por desenvolvedores, assumir o papel de design system ops é garantir que a documentação e os processos realmente ocorram e que ele cumpra sua função. É o momento em que existe um alinhamento de expectativa e realidade e entendimento de que o ROI realmente segue acontecendo.

E aceitar esse desafio é também vestir a camisa do design system para que ele continue atendendo as necessidades de todos: dos designers, engenheiros, dos usuários e da empresa.

Dos reagentes à transformação da matéria

Na Quero, temos hoje um squad de Design System, que pertence a tribo de Plataforma. Essa tribo é responsável pela visão global de tecnologia dentro da empresa (ou até do grupo de empresas que a Quero possui).

O squad de design system precisa entender se os tokens utilizados estão garantindo o bom funcionamento em todas as linguagens da empresa. Um dos resultados práticos foi garantir, por exemplo, a mudança de cores para o site novo do Quero Bolsa, após a mudança de marca.

Ter um squad voltado para resolver essas questões resulta por manter estreita a relação do time de Design com o time de Engenharia — que historicamente era quase inexistente. Participar dos processos ativamente, ao lado de um time de engenheiros, reflete em algo positivo:

você passa a pensar não só como um designer, mas como um engenheiro também.

Na minha opinião, a energia envolta dessa relação bem como um perfil de liderança é necessária em alguém na posição de design system ops e no caso da Quero, mostrou-se o ideal para garantir a funcionalidade do Zilla.

Desenhando fluxos

Desenvolvemos boas práticas para garantir a manutenção do nosso design system. Basicamente seguimos três fluxos a fim de decidir, criar ou editar e finalizar componentes. O objetivo de cada um deles é questionar necessidades ou apresentar as etapas a serem executadas.

Muitas vezes a criação de um novo componente pode ser necessidade de apenas uma squad, que não reflete um uso global. Foi com base nesse tipo de situação frequente que definimos o primeiro fluxo de governança: decisão. Testamos diversos fluxos junto ao time, mas o que melhor apresentou resultados foi a inspiração no Vanilla Pattern.

[DSW-01] Fluxo de decisão do Zilla inspirado no Vanilla Pattern

Com esse fluxo, é possível identificar se uma necessidade converge para:

1. a criação de um novo componente;

2. a edição de um componente que já existe ou;

3. desenvolvimento de algo local.

Para criarmos um componente novo, é necessário seguir o mesmo fluxo de edição de componentes já existentes. Tanto a guilda de front-end quanto a guilda de design precisam validar a solução dentro desse fluxo que foi construída em conjunto com essas áreas.

[DSW-02] Fluxo de criação ou edição de componentes do Zilla

Após o code review ser aprovado, partimos para o fluxo de validação, na qual aprovamos o storybook e a library de design, pelos desenvolvedores e designers respectivamente. O resultado de toda essa validação é a documentação, que fará o registro de todo esse processo.

O resultado da participação ativa de um squad e de um design system ops deve ser a manutenção de um design system, finalmente, global — sem pontas soltas, funcionando como um produto deve funcionar.

Evitando código clandestino

Não importa o quão amadurecido um time ou processo possa estar, velhos hábitos podem se repetir. Aqui na Quero, mesmo quando estávamos mais criteriosos e melhor assistidos em relação ao design system, foi inevitável que ainda assim alguns códigos piratas acontecessem.

Devido ao tempo sem processos e sem governança, nos deparamos em certo momento com três versões do Zilla na Engenharia. Sem um centralizador para checar os processos, duas squads começaram a desenvolver seus códigos sobre cópias do Zilla. Mais uma vez ficou claro para nós que, se um time não segue os parâmetros e fluxos definidos, é natural que um código clandestino permeie dentro do time.

Com uma tribo e squad definindo padrões de forma global, esperamos que casos como esse sejam reduzidos de maneira drástica ou até mesmo deixem de existir. E provavelmente seu benefício será tão claro que a empresa compreenderá que o design system é um produto que beneficia a todos.

To be continued…

Sinergia foi o primeiro ingrediente do design system que entendemos que precisávamos ter no início de todo esse processo. E, assim, seguimos: enquanto um time de design system, composto também por um design system ops, trabalha para manter o funcionamento do Zilla, o restante dos squads da empresa entendem a importância para desenhar e tangibilizar o produto.

E agora que passamos por tantas fases, com tantas falhas, tropeços e aprendizados, é hora de evoluir aos poucos. Seguir processos é também evitar que ajamos com impulsividade e perceber que o real motivo do Zilla ter nascido é que, de átomo em átomo, seguiremos melhorando nossos produtos e consequentemente tornando mais fácil a vida de nossos usuários.

• Design System: da confusão à construção de um produto, por mim mesmo.
• Design System por um desenvolvedor front-end, parte 1, por Danilo Vaz.
• Design System: conectando desenvolvedores e designers, por Ney Pimenta.
• Design Ágil na prática: adaptando UX ao seu meio e cultura, por Álvaro Rosa.