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.
Com esse fluxo, é possível identificar se uma necessidade converge para:
- 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.
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.
