Existe um culto no mundo de produto que precisa ser questionado: a ideia de que design system sério é aquele com 200 componentes, documentação impecável, três níveis de tokens e um time dedicado só para mantê-lo. Startups pequenas olham para o Material Design ou para o design system da Shopify e concluem que precisam construir algo daquele tamanho para serem levadas a sério. Aí gastam meses montando uma biblioteca que ninguém usa por inteiro, enquanto o produto que paga as contas fica esperando.
Esse texto é contra esse dogma. Não contra design system — a favor da versão certa dele para o seu tamanho. Para a esmagadora maioria dos times pequenos, o que resolve o problema de consistência não é uma biblioteca gigante; é um punhado de decisões bem tomadas: alguns tokens e os poucos componentes que de fato se repetem. O resto é vaidade de portfólio, custo disfarçado de boa prática. Vamos separar o que gera valor do que só gera trabalho.
Design system enxuto é o mínimo viável para dar consistência a um produto: um conjunto de tokens — cores, espaçamentos, tipografia — e os poucos componentes de fato reutilizados, sem biblioteca inflada, documentação exaustiva nem time dedicado para mantê-la.
O problema real que um design system resolve
Antes de decidir o tamanho, vale lembrar qual é a doença. Design system não é a meta — é remédio para um sintoma específico: inconsistência que custa dinheiro. Três tons de azul diferentes porque cada dev pegou o hex de um lugar. Botões com paddings ligeiramente distintos em cada tela. Um formulário que valida de um jeito aqui e de outro ali. Isso confunde o usuário, envelhece o produto e faz cada mudança visual custar o triplo, porque você precisa caçar as dez cópias da mesma coisa.
Se o seu produto tem esse sintoma, você precisa de sistematização. Se não tem — porque é pequeno, novo, tocado por uma ou duas pessoas que se coordenam de cabeça — talvez você ainda não precise de sistema nenhum. O erro clássico é construir o remédio antes da doença aparecer. A pergunta certa nunca é “quero um design system?”, e sim “a inconsistência já está me custando algo?”. Só quando a resposta for sim é que vale investir — e, mesmo aí, na menor dose que cura.
Comece por tokens, não por componentes
Quando a hora chega, quase todo time começa errado: pelo componente bonito. Desenha um botão lindo no Figma, implementa, comemora. Mas botão bonito sobre valores soltos ainda produz inconsistência, porque a próxima tela vai usar um cinza levemente diferente, um espaçamento improvisado. A raiz do problema não é o componente — são as decisões visuais espalhadas sem fonte única.
É por isso que se começa pelos tokens. Tokens são pares chave-valor que guardam as decisões visuais — cores, tipografia, espaçamento — como fonte da verdade, para serem reutilizados de forma consistente. A documentação de design tokens do Material Design 3 descreve bem o papel deles: são o contrato entre design e desenvolvimento, o que fica na base da pilha, com todo o resto construído em cima. Você edita num lugar e a mudança se propaga por todo o produto.
Tokens sem overhead: o bom e velho CSS
E aqui vem a parte que o dogma esconde: para um time pequeno, tokens não exigem maquinaria complexa. Você não precisa de uma pipeline de build de tokens multiplataforma, de Style Dictionary, de sincronização entre Figma e código. Para um produto de uma plataforma, um conjunto bem mantido de variáveis CSS ou SCSS já entrega o essencial: uma fonte única para cor, espaçamento e tipografia. Essa maquinaria toda só se paga quando você cresce para além de uma plataforma ou de vários times — aí ela recupera o investimento rápido. Antes disso, é solução para um problema que você não tem. Um punhado de custom properties bem nomeadas resolve 90% da dor de consistência com 5% do esforço.
O mínimo viável de componentes
Com tokens no lugar, os componentes viram consequência natural. E o conjunto necessário é bem menor do que o culto sugere. A regra é brutal e simples: um componente só entra no sistema quando se repete. Se ele existe em um lugar só, não é sistema — é só um componente vivendo a sua vida. Sistematizar o que aparece uma vez é overhead puro.
Para a grande maioria dos produtos, o núcleo que de fato se repete é curto:
- Botão (com suas variantes: primário, secundário, desabilitado)
- Campo de formulário (input, select, textarea, com estados de erro)
- Card
- Modal / dialog
- Navegação (header, menu)
- Feedback (toast, alerta, loading)
Seis famílias de componentes cobrem o esqueleto de quase qualquer aplicação. Não é subestimar o produto — é reconhecer que o Pareto do reuso mora nesses poucos elementos. Tudo além disso deve provar que se repete antes de virar peça de biblioteca. A pergunta para cada candidato é “quantas vezes isso já apareceu?”. Duas ou mais, sistematize. Uma só, deixe quieto até que se repita.
Enxuto vs. completo: quando cada um faz sentido
Nada disso é contra design system grande em absoluto. É contra design system grande no contexto errado. A diferença é escala, e escala é medível. Segue o mapa honesto:
| Sinal | Design system enxuto | Design system completo |
|---|---|---|
| Nº de produtos | Um | Vários, compartilhando marca |
| Nº de times | Um ou dois | Muitos, precisando de contrato comum |
| Plataformas | Uma (web) | Web, mobile, nativo, e-mail |
| Governança | Convenção informal basta | Versionamento e processo de contribuição |
| Documentação | README e comentários | Site dedicado, exemplos, guidelines |
| Custo de manter | Marginal, embutido no dev | Time ou pessoa dedicada |
Leia a tabela de baixo para cima: se você não tem escala para justificar um time dedicado à manutenção, você não tem escala para um design system completo. Simples assim. Uma biblioteca robusta com governança formal só se paga quando há muitos produtos, muitas equipes e várias plataformas puxando da mesma fonte. Sem isso, você está construindo um produto paralelo que compete por recursos com o produto que gera receita.
Quando NÃO vale a pena — dito sem rodeio
Vamos ser explícitos, porque é aqui que o dinheiro se perde. Não vale a pena um design system grande quando:
- Você tem um produto, uma plataforma e um time pequeno. Convenção mais tokens resolve.
- O produto ainda está buscando product-market fit e muda de cara toda semana. Sistematizar algo instável é congelar o que precisa mudar. Nesse estágio, foque em tirar o MVP do zero à produção, não em documentar componentes que vão morrer.
- Você está montando o design system “para quando crescermos”. Otimização prematura. Construa quando a dor chegar, não antes.
- Ninguém no time quer mantê-lo. Design system sem dono vira cemitério de componentes desatualizados — pior do que não ter, porque o time confia numa fonte que mentiu.
Reconhecer isso não é preguiça técnica. É a mesma competência de saber a hora certa de qualquer investimento de infraestrutura: cedo demais é desperdício, tarde demais é dívida. O enxuto existe justamente para você não cair em nenhum dos dois extremos.
O enxuto também acelera performance e SEO
Há um bônus que raramente entra na conversa. Um design system enxuto não só custa menos para manter — ele costuma produzir um produto mais leve. Menos componentes, menos abstração, menos dependência significa menos JavaScript enviado ao navegador. E menos JavaScript conversa direto com performance e conversão: páginas mais rápidas, melhor Core Web Vitals.
Bibliotecas de componentes gigantes têm o vício oposto: arrastam peso, camadas de abstração e estilos que você não usa. Para um site institucional ou uma landing, esse peso vira lentidão que custa ranqueamento — algo que detalhamos em SEO técnico para software houses. O enxuto, ao contrário, mantém a superfície pequena e o bundle magro. Consistência e performance, no tamanho certo, andam juntas em vez de brigar.
Como um time pequeno constrói o seu
Se a doença já apareceu e você decidiu agir, o caminho enxuto tem uma ordem clara:
- Tokens primeiro. Defina cor, espaçamento, tipografia e raio como variáveis CSS/SCSS. Uma fonte só.
- Refatore o que já existe. Aponte os componentes atuais para os tokens antes de criar coisa nova. Você resolve inconsistência retroativa de graça.
- Sistematize só o que se repete. Comece pelo núcleo curto — botão, campo, card, modal. Deixe o resto provar que reaparece.
- Documente o mínimo. Um README com os tokens e um exemplo de cada componente. Nada de site dedicado no dia um.
- Deixe crescer sob demanda. Cada novo componente entra quando a segunda ocorrência aparecer, não antes.
Repare que nenhum passo pressupõe um time dedicado nem meses de trabalho. É trabalho de dias, embutido no fluxo normal de desenvolvimento. Essa é a natureza do enxuto: ele se paga rápido porque nunca cobra caro. E vale lembrar a fronteira de sempre — sistematizar componente de interface não é o mesmo que arquitetar um produto complexo; se o que você faz é mais app do que site, a conversa muda, e vale distinguir os dois casos em site vs. web app.
Onde a Pixelize entra
A gente constrói produtos com o design system do tamanho certo — enxuto quando o time é pequeno, robusto só quando a escala justifica. Tokens primeiro, componentes que de fato se repetem, e nada de biblioteca inflada consumindo o orçamento do produto que paga as contas. É desenvolvimento web em que consistência vem sem overhead, e a decisão de quanto sistematizar é tomada olhando a sua escala real, não o dogma dos 200 componentes.
Perguntas frequentes
O que é um design system enxuto?
É o mínimo viável que dá consistência a um produto: um conjunto de tokens (cores, espaçamentos, tipografia) e um punhado de componentes realmente reutilizados. Nada de biblioteca com 200 peças, documentação exaustiva e time dedicado. O foco é resolver inconsistência com o menor overhead possível.
Quantos componentes um design system precisa ter?
Só os que se repetem. Botão, campo de formulário, card, modal, navegação — o conjunto que aparece em toda tela. Se um componente existe em um lugar só, ele não é sistema, é só um componente. A quantidade certa é a menor que elimina a duplicação real, não um número de vitrine.
Por que começar por tokens e não por componentes?
Porque tokens são a fonte da verdade das decisões visuais — cor, espaçamento, tipografia — e todo componente se apoia neles. Com tokens, você muda uma cor num lugar e ela se propaga por todo o produto. Componentes bonitos sobre valores soltos ainda produzem inconsistência; tokens primeiro resolvem a raiz.
Quando NÃO vale a pena um design system grande?
Quando você tem um produto, uma plataforma e um time pequeno. Aí uma biblioteca robusta com governança, versionamento e documentação vira overhead que consome mais do que devolve. Design system grande se paga com escala: muitos produtos, muitas equipes, várias plataformas. Sem essa escala, é solução para problema que você não tem.
Design tokens servem para time pequeno ou só para empresa grande?
Servem para time pequeno também, na versão simples. Para um produto de uma plataforma, um bom conjunto de variáveis CSS ou SCSS bem mantido já entrega o essencial dos tokens. Você só precisa da maquinaria de tokens multiplataforma quando cresce para além de uma plataforma ou de um time — aí ela se paga rápido.
Design system atrapalha a velocidade de um time pequeno?
O grande atrapalha; o enxuto acelera. Uma biblioteca pesada com processo de contribuição formal freia quem só quer entregar uma tela. Já um conjunto pequeno de tokens e componentes reusados faz o oposto: cada tela nova reaproveita o que existe, decide menos e sai mais rápido, com consistência de brinde.