Design systems cresceram rápido. Em cinco anos, passamos de pattern libraries artesanais para produtos internos com times dedicados, documentação viva e tokens sincronizados com Figma. Mas em muitas empresas, a ambição ficou maior que o entendimento do que de fato um design system deveria ser.
A confusão mais comum: tratar design system como biblioteca de componentes.
É um erro de categoria. Uma biblioteca resolve um problema de distribuição de código. Um design system resolve um problema de linguagem compartilhada.
O que uma biblioteca resolve
Quando você extrai componentes para um pacote npm e publica no registry da empresa, você resolveu um problema de reuso. Qualquer time pode instalar @empresa/ui e usar o <Button>. Isso tem valor real — consistência visual, menos duplicação, atualizações centralizadas.
Mas é suficiente?
// Isso compila sem erro
<Button variant="primary" size="sm" disabled loading>
Salvar
</Button>
// Mas faz sentido semântico?
// Um botão pode ser disabled E loading ao mesmo tempo?
// O design define isso?
A biblioteca não sabe responder. Ela entrega componentes, não decisões.
O que um ecossistema resolve
Um design system maduro existe em múltiplas camadas:
graph TD
DS[Design System]
DS --> T["Tokens
cores, tipo, espaçamento"]
DS --> C["Core
Button, Input, Modal"]
DS --> P["Padrões
formulários, modais, estados"]
Cada camada tem uma responsabilidade diferente:
- Tokens são as decisões de baixo nível. Cor, tipografia, espaçamento, sombra.
- Core são os componentes primitivos. Sem lógica de negócio, só comportamento de interface.
- Padrões são as composições validadas — como componentes se combinam para resolver problemas reais.
Uma biblioteca entrega Core. Um design system entrega os três.
Por que isso importa na prática
Quando um designer decide que “botões destrutivos devem exigir confirmação”, essa decisão precisa existir em algum lugar além de um comentário no Figma. Ela precisa virar um padrão — documentado, implementado, versionado.
Quando você trata o design system como biblioteca, essas decisões ficam espalhadas: no Figma, em conversas de Slack, nas cabeças dos designers mais antigos.
A documentação de padrão não é luxo. É o contrato entre produto e interface.
O que muda na prática
Adotar essa distinção muda como você organiza o trabalho:
- Tokens primeiro. Antes de construir qualquer componente, defina e exporte os tokens. Tudo deriva deles.
- Documente decisões, não apenas API. “Por que esse componente existe” importa tanto quanto “como usar”.
- Versione padrões separadamente de componentes. Um padrão pode mudar sem alterar a API do componente.
- Meça adoção de padrões, não só de componentes. Um time que usa
<Button>mas ignora o padrão de confirmação destrutiva está usando a biblioteca, não o sistema.
A distinção parece sutil. Mas ela muda o perfil de quem precisa estar envolvido, o que precisa ser documentado e como o sucesso é medido.
Bibliotecas são distribuídas. Sistemas são cultivados.