A maioria dos design systems morre antes de completar dezoito meses, e a causa raramente é técnica. Morre porque foi aprovado como projeto de design e financiado como prioridade estética, até ser abandonado assim que o time de engenharia percebeu que os componentes do Figma não correspondiam ao que estava implementado em código. Já vi essa dinâmica se repetir em pelo menos seis consultorias distintas nos últimos cinco anos, e o padrão é consistente o suficiente pra descrever como falha sistêmica: a empresa investe em uma biblioteca de componentes visuais e celebra o lançamento com um Confluence bem formatado, e seis meses depois descobre que metade dos desenvolvedores está criando variantes próprias porque o sistema não cobria os edge cases que apareceram em produção. Pra mim o problema é o enquadramento organizacional, antes de qualquer coisa. Design systems que funcionam são tratados como infraestrutura de engenharia, com ownership claro, versionamento, testes automatizados e orçamento de manutenção contínua.
Os dados disponíveis sobre retorno de investimento reforçam essa leitura. Um modelo publicado pela Smashing Magazine, publicação especializada em desenvolvimento e design web, baseado em literatura agregada, estima ganho médio de produtividade de 38% pra times de design e 31% pra times de desenvolvimento após a fase de estabilização de um design system. Pra uma empresa hipotética com cinco designers e dez desenvolvedores investindo 30% do tempo durante a fase de ramp-up, o modelo projeta ROI combinado de 135% ao longo de cinco anos, com margem de erro de 25%. O retorno não aparece nos primeiros meses. A curva de eficiência começa negativa, com queda de produtividade durante a construção e adoção inicial, e só cruza o ponto de equilíbrio quando o sistema atinge massa crítica de componentes validados em uso real. Se a organização avalia o investimento com horizonte de um ou dois trimestres, a conclusão será de que o projeto está gerando custo sem retorno. É nesse ponto que a maioria dos design systems perde patrocínio executivo.
A curva de maturidade explica por que o enquadramento como projeto de design falha com tanta previsibilidade. Projetos de design têm entregas discretas: um redesign tem data de encerramento. Um design system se comporta como produto interno, com roadmap, backlog de bugs e necessidade de deprecar componentes antigos sem quebrar o que já está em produção. Quando o time de design entrega a biblioteca inicial e volta pras demandas de produto, o sistema começa a divergir. O Design Systems Report 2025 da Zeroheight, plataforma de documentação de design systems, confirma essa dinâmica: organizações que mantêm times dedicados ao design system, mesmo que pequenos, tipicamente entre cinco e vinte pessoas, reportam adoção e manutenção consistentemente melhores que aquelas onde a responsabilidade é distribuída de forma difusa entre times de produto.
O mesmo relatório mostra que o uso de design tokens saltou de 56% para 84% entre as organizações pesquisadas, o que indica que a ponte entre design e engenharia está se tornando operacionalmente mais concreta. Tokens funcionam como variáveis semânticas que codificam decisões de design em formato consumível por código, e quando são a fonte de verdade compartilhada entre Figma e Storybook, ferramenta de desenvolvimento e documentação de componentes de UI, a divergência entre especificação e implementação se reduz porque ambos operam sobre a mesma abstração. Sem tokens, a consistência depende de comunicação humana e revisões manuais. Com tokens, a consistência se torna propriedade do sistema, verificável por automação.
O trade-off é real. Construir e manter um design system com o rigor de infraestrutura de engenharia custa mais no curto prazo do que entregar componentes ad hoc pra cada feature. O relatório da Zeroheight aponta que limitações de staffing e orçamento são os obstáculos mais citados, e que uma parcela relevante dos respondentes identifica falta de conhecimento e experiência como barreira primária de adoção. Na minha avaliação, o investimento envolve código e componentes, além de capacitação do time e advocacy interna que demonstre o valor do sistema pra quem precisa usá-lo. Organizações que tratam documentação e onboarding como preocupações secundárias acabam com sistemas tecnicamente sólidos que ninguém adota, o que é indistinguível de não ter sistema nenhum.
A mensuração de adoção é onde o enquadramento de engenharia se diferencia de forma mais visível. Medir adoção pela quantidade de componentes na biblioteca é como medir qualidade de software pela quantidade de linhas de código. A métrica relevante é cobertura em produção: qual percentual das interfaces entregues utiliza componentes do sistema, e qual percentual recorre a implementações customizadas. Essa medição exige instrumentação, o que reforça a natureza de engenharia do problema. Cada reimplementação é um sinal de que o sistema falha em atender quem deveria servir.
Na minha análise, o enquadramento correto de um design system determina sua sobrevivência. Quando o sistema é posicionado como entrega de design, ele compete por atenção com demandas de produto e perde invariavelmente, porque a pressão por features novas sempre supera a pressão por consistência interna. Posicionar como infraestrutura de engenharia, com as mesmas práticas de versionamento semântico, CI/CD, code review e monitoramento que se aplicam a qualquer biblioteca compartilhada, integra o sistema ao fluxo de trabalho existente em vez de fazê-lo competir com ele. A diferença é operacional e orçamentária, e determina se daqui a dois anos o sistema ainda existe ou virou mais um item abandonado no Confluence.