Você Não Precisa de um Design System
A maioria dos times que lança um design system está fazendo LARP de maturidade. O custo de manutenção supera o retorno, a geração por IA destrói a conta, e uma stack de tokens + primitivos + bom gosto vence um sistema totalmente especificado para 95% das empresas.
Você provavelmente não precisa de um design system. Você precisa de alguns design tokens, uma pequena biblioteca de componentes e uma pessoa no time com bom gosto. Aquilo sobre o que o seu perfil favorito de design no Twitter não para de postar, o arquivo do Figma com 400 componentes publicados e 12 temas, é um produto de tempo integral que a sua startup de oito pessoas está pagando e não está colhendo.
Essa é a opinião que todo mundo na indústria sabe que é verdade e ninguém diz em voz alta. A conta de manutenção é real. O retorno é, na maior parte, imaginado. A geração por IA só piorou a distância entre os dois.
Os 95% dos times que lançam um design system estão fazendo LARP de maturidade. Os 5% que realmente precisam de um geralmente não são os times que fazem a pergunta.
Um design system é um produto, não uma missão secundária
Um design system de verdade tem seu próprio roadmap, seu próprio changelog e seus próprios clientes. Esses clientes são as pessoas engenheiras e designers que lançam o produto de fato. Se ninguém está alocado para manter o sistema, ele não é um sistema. É um instantâneo.
Olhe para quem lança design systems bem. A Stripe tem um time de infraestrutura de design dedicado. O Shopify Polaris tem uma organização própria. O GitHub Primer tem um repositório público com releases versionadas.
A Atlassian tem anos de investimento em um sistema cujo escopo a maioria dos times nunca vai alcançar. Cada um desses é um time de produto construindo ferramentas para uma base interna de clientes que chega aos milhares.
Agora olhe para a versão típica. Uma designer sênior passou seis semanas no Figma, publicou 80 componentes, escreveu uma página no Notion que nenhum engenheiro lê e lançou dois temas. Seis meses depois, metade dos componentes está desatualizada, os tokens divergem do código e o time voltou a copiar classes do Tailwind. O sistema não falhou. O time falhou em alocar gente para ele.
A conta de manutenção que ninguém coloca no slide
O discurso do retorno é: construa uma vez, reutilize para sempre. A conta real: construa uma vez, depois mantenha para sempre, e reutilize um pouco às vezes.
Todo design token que existe precisa ser mantido em sincronia entre o Figma e o código. Toda variante de componente precisa ser testada quando o framework atualiza. Toda breaking change no Radix, no React ou no Tailwind se propaga por todos os produtos dependentes. A documentação apodrece em um trimestre.
A instância do Storybook quebra num bump de dependência e ninguém percebe por três semanas. A biblioteca publicada no Figma fica uma release atrás do código. Os temas divergem. Os componentes do sistema não são os componentes do produto.
A contabilidade honesta é esta. Um "sistema" de seis componentes pode economizar tempo de verdade. Um sistema de 200 componentes numa empresa de 12 pessoas é um imposto. As horas de retorno são lineares, as horas de manutenção se acumulam, e em algum ponto as linhas se cruzam. A maioria dos times cruza as linhas sem perceber, porque a manutenção aparece como mensagens de Slack na sexta à tarde em vez de uma linha no P&L.
A geração por IA acabou de destruir a conta
Todo o argumento a favor de um design system se apoiava em um único número: o custo de produzir um novo componente bem estilizado. Esse número agora é um erro de arredondamento.
Uma engenheira júnior pode digitar "me dê uma página de configurações com uma sidebar, três seções e uma barra de salvar que segue o padrão de estado de carregamento" e lançar um componente funcionando em vinte minutos. O v0 gera saída no formato Shadcn por padrão. O Cursor e o Claude conseguem refatorar um fluxo inteiro em cima de primitivos existentes. O retorno que um design system costumava oferecer, geração rápida de UI com aparência consistente, agora é um serviço gratuito entregue por todas as IDEs do mercado.
O imposto do sistema não mudou. O retorno despencou. Essa é a história toda. Times que construíram design systems em 2022 para ter saída mais rápida agora são mais lentos que times que lançam Shadcn + Tailwind + um prompt, porque toda ferramenta de IA foi treinada nesse último e ignora o primeiro.
Os 5% que realmente precisam de um design system
Um design system de verdade só se paga quando um conjunto específico de condições é verdadeiro ao mesmo tempo. Falhou uma, a conta desmorona.
- Vários produtos compartilhando uma identidade. A Atlassian tem Jira, Confluence, Trello e mais uma dúzia. Uma identidade, muitas superfícies. O sistema é a camada de unificação.
- Headcount na casa das centenas, não das dezenas. Abaixo de 50 engenheiros de produto, todo componente está a uma mensagem de Slack de ser corrigido. Acima de 200, isso não escala e o sistema vira o único caminho.
- Um time de design ops ou de infraestrutura de design alocado. Um design system sem dono é um cemitério. O dono precisa ser um papel real, não um projeto de 20% do tempo.
- Consumidores externos. Design systems open source como o GitHub Primer ou o Shopify Polaris também são produtos voltados a desenvolvedores. O custo de manutenção se justifica pela adoção externa.
- Um domínio regulado ou pesado em acessibilidade. Saúde, finanças, governo. O sistema codifica conformidade e prontidão para auditoria, um retorno que nenhum time individual consegue replicar.
Se um time cumpre os cinco, um design system é a decisão certa. Se cumpre um ou dois e lança um produto com 40 engenheiros, design system é cosplay. O texto sobre o anti-dashboard aborda um padrão parecido: construir infraestrutura para um tamanho de organização que você ainda não tem.
O sistema visual mínimo viável
Para os 95%, a resposta é uma stack de três camadas que custa quase nada para manter e produz quase o mesmo resultado.
| Camada | O que é | Ferramentas | Custo de manutenção |
|---|---|---|---|
| Tokens | Cor, tipografia, espaçamento, raio e sombra como variáveis | Config do Tailwind, variáveis CSS, variáveis do Figma | Baixo. Um arquivo. Atualizado a cada trimestre. |
| Primitivos | Componentes headless ou estilizados, acessíveis por padrão | Shadcn, Radix, Headless UI, primitivos do Cal.com | Baixo. Copiados para o projeto, não mantidos. Atualize sob demanda. |
| Bom gosto | Alguém que sabe quando quebrar as regras | Um designer sênior ou engenheiro que entende de design | De graça se você contratar bem, infinito se não. |
Essa é a stack inteira. Tokens dão consistência. Primitivos dão acessibilidade e comportamento. Bom gosto dá a camada que nenhum sistema consegue codificar: o julgamento sobre quando as regras devem ceder.
Os times que lançam os produtos mais limpos em 2026 usam uma versão disso. A Linear roda com um conjunto minúsculo de tokens, primitivos próprios e um gosto obsessivo. A Vercel lança uma config pesada de Tailwind mais seus próprios primitivos.
O Cal.com publica seus primitivos abertamente. Resend e Loops lançam UI no formato Shadcn com tokens da casa por cima.
O Notion roda com um pequeno conjunto de tokens e um vocabulário de componentes deliberadamente enxuto. Nenhum deles tem um "design system" no sentido da Atlassian. Todos têm uma stack de site de marketing que parece mais coerente do que a de empresas dez vezes maiores.
Por que o Shadcn está engolindo a categoria de design system
O Shadcn não é uma biblioteca de componentes. É um mecanismo de entrega do novo padrão. Os primitivos são copiados para o código, estilizados com Tailwind e acessíveis porque o Radix faz o trabalho pesado por baixo. Quem usa é dono dos componentes, pode editá-los livremente e nunca fica bloqueado por releases upstream.
Esse é o golpe de misericórdia na maioria dos design systems internos. O motivo pelo qual os times construíam o seu era controle. O Shadcn dá o controle de graça. O motivo pelo qual os times lançavam Storybooks era descoberta.
O Shadcn publica sua documentação abertamente e as ferramentas de IA a indexam. O motivo pelo qual os times publicavam bibliotecas no Figma era consistência. Os primitivos do Shadcn são consistentes o bastante para que qualquer prompt em cima deles produza uma saída que o time já sabe avaliar.
Shadcn + Tailwind + um conjunto de tokens é a stack visual padrão de 2026. É o que toda ferramenta moderna de codegen com IA produz por padrão. É o que todo time novo de produto lança primeiro. É o modelo de primitivos + bom gosto em dois repositórios e um arquivo de config. O design system como artefato separado, com seu próprio pipeline de publicação e seu próprio time, agora é o caso especial.
Quando um sistema de verdade finalmente se paga
A versão honesta da pergunta "precisamos de um design system?" é "já cruzamos o limite da manutenção?"
| Sinal | Precisa de um sistema? |
|---|---|
| Dois engenheiros lançam botões inconsistentes na mesma semana | Não. Adicione um arquivo de tokens. |
| Três produtos compartilham uma marca e divergem visualmente | Talvez. Comece com tokens compartilhados. |
| Vários times lançam o mesmo componente de formas diferentes a cada trimestre | Sim. Hora de ter primitivos compartilhados. |
| Um componente específico é reconstruído por quatro times em seis meses | Sim. Promova-o para o sistema. |
| Integrar um novo designer leva duas semanas porque as convenções são tribais | Sim. O sistema agora dá retorno. |
| Desenvolvedores externos consomem seus componentes | Sim. O sistema é um produto. |
| Auditorias de conformidade ou acessibilidade chegam ao seu roadmap | Sim. Codifique uma vez. |
Se um time bate três ou mais desses sinais, um sistema de verdade se justifica. Se bate um, um arquivo de tokens basta. A mesma lógica aparece na forma como o problema da página de preços e onboarding sem onboarding resolvem a coordenação no nível da superfície em vez do nível do sistema.
O padrão e depois a piada final
O flex de maturidade está de cabeça para baixo. Os times que lançam os produtos mais coerentes em 2026 não são os que têm os maiores design systems. São os que têm a menor dívida visual. Conjunto enxuto de tokens, camada fina de primitivos e um designer com bom gosto que diz não com frequência.
Design systems de verdade são infraestrutura para organizações que superaram a alternativa. Não são um marco que todo time deveria atingir. Não são símbolo de status. Não são a resposta para "queremos parecer mais profissionais".
Um time que constrói um antes de merecer o orçamento de manutenção lança o mesmo produto num relógio mais lento e com um arquivo mais pesado. O que lança tokens + Shadcn + bom gosto lança o mesmo produto num relógio mais rápido e usa o tempo economizado para consertar o problema da página de configurações.
A pergunta não é "temos um design system?". É "estamos pagando manutenção no nível certo de abstração?"
FAQ
Qual é a diferença entre um design system e uma biblioteca de componentes?
Uma biblioteca de componentes é um conjunto de peças de UI reutilizáveis. Um design system é uma biblioteca de componentes mais tokens, mais documentação, mais governança, mais um dono, mais uma cadência de releases. A maioria dos times lança uma biblioteca de componentes e chama de sistema. As duas coisas não são iguais, e a segunda tem um custo de manutenção que a primeira não tem.
O Shadcn é um design system?
Não. O Shadcn é um mecanismo de entrega de primitivos. Os componentes são copiados para o código e pertencem ao time. Não há biblioteca central, nem calendário de releases upstream, nem governança.
Esse é o ponto. Ele dá ao time o retorno de um sistema sem a conta de manutenção.
Quando uma startup deve investir em um design system?
Quando pelo menos três destas coisas forem verdadeiras: vários produtos compartilhando identidade, cinquenta ou mais engenheiros lançando UI, um papel de design ops alocado, consumidores externos dos componentes ou um domínio regulado. Abaixo dessa régua, lance tokens + primitivos + bom gosto e invista as horas economizadas no produto de verdade.
CTA
Quer um produto em que o sistema visual combine com o tamanho do time? A Brainy entrega stacks de tokens + primitivos para os 95% e design systems completos para os 5%, calibrados para o orçamento real de manutenção. Contrate a Brainy. Vamos dizer de que lado da linha você está antes de você gastar um trimestre no artefato errado.
Want a product where the visual system matches the team size? Brainy ships tokens-plus-primitives stacks for the 95% and full design systems for the 5%, calibrated to the actual maintenance budget.
Get Started
