O desafio da manutenção e melhoria de um Design System

O desafio

Ao ingressar na Bild, recebi a missão de realizar a manutenção de um Design System já existente, o Asteroid, que além de desatualizado, possuia estes problemas:

• Organização básica(dificuldade para encontrar um simples componente).

• Explicações claras(fazer com que o colega saiba o porque, quando e como usar aquele compente ou até mesmo uma cor).

• Falta de documentação para o time de desenvolvimento.

A questão da documentação para os devs, empatia e handoff será um dos principais assuntos desse case, continue comigo que vou te explicar o motivo.

Organizando a casa

O básico e simples sempre funciona, portanto, iniciei minha aventura organizando o Design System da seguinte forma:

• Uma página para os componentes

• Uma página para os fundamentos

Por que separar?
Porque assim podemos facilitar na busca pelo que o usuário em questão(que pode ser um colega ou um desenvolvedor) deseja, se ele pretende buscar por cores, espaçamentos e tipografia basta acessar a página de fundamentos, caso o contrário, basta buscar pelos compontentes em sua devida página.

Dissecando cada página

A importânica da padronização, simplicidade e objetividade.

Componentes

Essa página é onde os blocos reutilizáveis de interface são construídos a partir dos fundamentos, nela você encontra váriantes, explicações e casos de uso, organizados por ordem alfabética.

Fundamentos

Essa página serve como a base conceitual e visual do Design System. É onde ficam definidos os elementos mais primários que orientam toda a identidade do produto e garantem consistência.

Os Fundamentos

Aqui é onde enocntraremos cores, tipografia, espaçamentos, grids e muito mais.

Cores

Além do nosso velho conhecido hexadecimal, também deixamos documentado em RGB e HSL, além do mais importante: Token para conexão com o código para o desenvolvedor.

Tipografia

Nesse caso, a separamos por sua classificação, conténdo a font-family, tamanho, o line height, letter spacing, peso e é claro o token.

Para o espaçamento, a explicação e os casos de uso são extremamente importantes, deixando claro quando usamos um tamanho ou outro, por exemplo o espaço entre itens dentro de uma mesma seção.

Espaçamento

Os componentes

Muito além de blocos para a interface, documentamos de forma ampla para explicar os casos de uso e suas variações.

"Dissecando" o componente

No exemplo da imagem acima, podemos ver que deixamos de forma completa e documentada toda a questão de especifidades do componente, as cores utilizadas, espaçamento interno, fonte, etc.

Variantes

As variantes, como o próprio nome diz, são os vários "tipos" desse componente, lembrando: de nada adianta separar as variações e não explicas quando e como se utiliza cada uma delas, por isso temos o próximo tópico abaixo.

Os exemplos de uso e prototipação servem justamente para mostrar quando usamos cada variação, qual o comportamento esperado do componente e como ele se portaria em uma página UI real.

Exemplo de uso e prototipação

Notion para complementar a documentação

O notion foi extremamente importante, principalmente na documentação dos componentes, nos auxiliou a responder diversas perguntas dos desenvolvedores, questionamentos que eram em sua grande maioria devido aos casos de uso, como por exemplo:

Por que nesse caso devo utilizar o botão secundário e não o primário?
Explicamos não somente com palavras, mas com exemplos e casos reais de UI do produto.

Sua organização ocorre da mesma forma que o Figma, dividindo por fundamentos e componentes, cada um com sua pasta e seus itens internos, mantendo o mesmo padrão para não fazer o usuário pensar demais.

Ok, mas e se fosse a minha empresa o que eu ganharia com isso?

No fundo, um Design System organizado é sobre futuro. Ele garante que, à medida que a empresa cresce, a qualidade não se dilui, que a marca não se perde em interfaces desconexas e que os times não se afoguem em complexidade. É sobre dar poder às pessoas para que criem mais rápido, com mais qualidade e menos esforço.

Esse entendimento é vital: quando o desenvolvedor compreende com profundidade a lógica por trás dos fundamentos e a aplicação nos componentes, o trabalho deixa de ser apenas "codar telas" e passa a ser construir experiências consistentes e escaláveis. É menos retrabalho, menos fricção entre design e código, mais produtividade e mais confiança no resultado final.

Por isso, ter um Design System bem estruturado e documentado não é um luxo, é uma necessidade estratégica. Ele é a ponte que conecta design e desenvolvimento, e sem ele, cada novo produto ou funcionalidade será mais difícil, mais caro e mais lento de entregar.
Se a empresa quer escalar com consistência, eficiência e confiança, precisa desse pilar. Precisa investir nele com seriedade. Porque no fim, o que realmente importa não é apenas construir interfaces bonitas, mas criar produtos que funcionam, encantam e crescem junto com o negócio e só um Design System organizado torna isso possível.