DAS Design System
O DASDS é o design system dos Digital and Automation Systems da NETZSCH: um pipeline de Figma pra código feito pra que oito squads de produto entreguem UI consistente sem pagar um pedágio de coordenação a cada sprint.
- 8+
- Squads usando o DS
- 1.2k
- Variáveis no Figma
- 60+
- Componentes em produção
Desafio
Cada linha de produto da NETZSCH tinha seus próprios componentes, tokens e convenções. Sobrepostos, mas incompatíveis. Toda feature que cruzava times se arrastava porque ninguém era dono da camada compartilhada.
O briefing era construir algo que os times de linha de frente realmente quisessem usar, não um sistema imposto goela abaixo. O que significava que a base tinha que resolver problemas reais primeiro: cor acessível, tipografia que sobrevive à tradução de português pra alemão, tabelas de dados densas e padrões de formulário à altura da natureza regulada do software industrial.
Abordagem
Tokens primeiro. As variáveis no Figma mapeiam um pra um pras custom properties do CSS via Style Dictionary, então uma mudança de cor ou espaçamento flui do design pra produção sem tradução manual. Os componentes têm dono no código, são documentados no Storybook e demonstrados no Figma ao lado do build de produção.
A governança é leve de propósito. Qualquer time pode propor um componente novo via PR. O time de plataforma revisa pela consistência. Quem contribui mantém o crédito de autoria. A métrica é adoção por squad, não contagem de componentes.
Resultado
Oito squads de produto usam o DS em produção. Features novas que cruzam times saem sem o velho vai e volta entre design e engenharia sobre qual token vence. As revisões de acessibilidade caíram de dias pra horas porque a base já é AA.
Hoje o DS serve de semente pra linhas novas (IRIS V3, o Customer Portal, ferramentas internas) em vez de cada uma reconstruir as mesmas peças básicas do zero.
Pra quem eu desenhei
Dois públicos com necessidades bem diferentes.
Os engenheiros de frontend das squads são quem de fato consome o sistema. Eles queriam coisas sem graça: uma página de Storybook que carrega rápido, nomes de prop que batem com o que esperam e componentes que não brigam com o build que já existe. Qualquer coisa chique perdia pra qualquer coisa confiável.
Os product designers das squads (em geral um por linha de produto, às vezes nenhum) queriam variáveis no Figma espelhando as variáveis do código, pra não terem que refazer o trabalho que a engenharia já fez. O mapeamento de tokens 1:1 não era estética. Era o contrato que deixa um designer entregar sem traduzir.
A decisão-chave: uma fonte única de verdade pros tokens
A maioria dos projetos de DS falha no mesmo ponto: os design tokens do Figma vão se descolando das variáveis CSS do código e, em seis meses, todo mundo volta a copiar código hex na mão. Me recusei a lançar qualquer coisa antes de o pipeline estar à prova de vazamento.
As variáveis do Figma exportam pra um spec JSON do Style Dictionary. O Style Dictionary compila os mesmos tokens em custom properties do CSS, config do Tailwind e um arquivo de tipos TypeScript. Uma fonte, três saídas, tudo gerado. Um designer renomear uma cor no Figma dispara um PR. Um engenheiro ajustar uma razão de contraste atualiza o Figma ao mesmo tempo.
Todo o resto do sistema (escala tipográfica, espaçamento, raios, sombras, movimento) fica em cima desse pipeline. Sem ele, o DS é só uma pilha de componentes que parecem certos hoje e errados daqui a dois meses.
O que não foi bem
A parte difícil não foi construir o sistema. Foi fazer squads com código legado que já funcionava adotarem ele. Componentes sólidos e documentação limpa não bastaram. Os times resistiam quando um padrão novo significava refatorar algo que já tinha ido pra produção, e os primeiros seis meses foram mais demo, pareamento com os líderes de squad e reescrita de doc pra responder as mesmas cinco perguntas.
O modelo de "governança leve" também mostrou o limite. Deixar qualquer um propor componente fez a fila encher de especiais de uso único. Tive que começar a dizer não, o que é desconfortável quando você vende o sistema como propriedade da comunidade. Todo DS precisa de um dono com opinião, e esse dono era eu, com ou sem o organograma dizendo isso.
Telas selecionadas
" Um DS vive ou morre pela adoção, não pela estética. As vitórias vieram das partes sem graça (pipeline de tokens, piso de acessibilidade, fluxo de contribuição) feitas antes de alguém se empolgar com a linguagem visual. "
MyCT
→Portal voltado ao cidadão. WCAG 2.1 AA, linguagem simples, mobile-first.