Resumos de design system costumam ser organizados por empresa, que é o eixo menos útil — você já sabe quem é o Airbnb, e esse fato não diz se o sistema deles ajudará você. Aqui está o mesmo conjunto organizado pelo que você está tentando descobrir.

O restante deste texto analisa cada um deles, detalhando o que está disponível e o que vale a pena adotar.

Analisar Carbon, Polaris e Lightning em conjunto revela algo que nenhum deles discute individualmente. Todos os três foram reestruturados recentemente, de formas diferentes, sob a mesma premissa: o código que consome um design system é, cada vez mais, escrito por máquinas, e não por humanos lendo a documentação.

A Salesforce é a mais explícita, descrevendo o SLDS 2 como a base para seu design system agentic e referindo-se a experiências de usuário geradas dinamicamente. A razão declarada da IBM para o servidor MCP inclui a geração de código com maior fidelidade. A abordagem da Shopify foca em fazer com que os apps pareçam nativos do admin, mas o efeito é o mesmo: componentes que renderizam de forma idêntica, independentemente de quem os montou.

Ninguém coordenou isso. Três empresas com produtos diferentes, restrições diferentes e nenhum motivo para concordar chegaram a conclusões compatíveis no mesmo período — o que geralmente é o sinal de que a mudança subjacente é real, e não apenas moda.

Open source, financiado e construído pela IBM, baseado na IBM Design Language como uma camada separada de fundação de marca, com systems de domínio (IBM Products, Cloud, IBM.com) acima do core. React, Web Components e Elements são mantidos pela equipe do Carbon; Angular, Vue e Svelte são mantidos pela comunidade, e a documentação deixa isso claro — uma transparência honesta que a maioria dos systems ignora.

Adote: a separação em três camadas e a prática de publicar quem mantém cada implementação. Ignore: a adoção integral se a diferenciação visual for importante para o seu produto, pois a densidade e os idiomatismos de interação carregam a identidade da IBM mesmo após a alteração das cores. Leitura completa.

Foundations, tokens, componentes e mais de 400 ícones focados em comércio. A biblioteca React agora está marcada como descontinuada; web components são carregados de um CDN da Shopify e adicionados automaticamente pelo Shopify CLI.

Adote: o conjunto de ícones de comércio se você atua nesse segmento, a abordagem de nomenclatura de tokens e a lógica do modelo de entrega. Ignore: os componentes fora de um app Shopify — eles farão seu produto parecer a Shopify. Leitura completa.

O SLDS 1 foi lançado em 2015 como um framework CSS com a aparência integrada. O SLDS 2 o reconstruiu em torno de propriedades customizadas de CSS, adicionou uma biblioteca Figma cujos nomes de tokens correspondem exatamente ao código e lançou ferramentas de linting que validam a marcação conforme as regras.

Adote: a paridade de nomenclatura entre Figma e código, e o linter como mecanismo de aplicação. Ambos são replicáveis sem adotar uma única linha de CSS da Salesforce. Ignore: o framework em si, a menos que você desenvolva na Lightning Platform. Leitura completa.

O exemplo mais forte de um system construído em torno de uma restrição que ninguém mais leva tão a sério: ele precisa funcionar para todos, incluindo pessoas com dispositivos antigos, conexões ruins, leitores de tela e sob estresse. Os componentes vêm acompanhados de pesquisas publicadas sobre como foram testados e por que têm a aparência que têm.

Adote: a prática de publicar as evidências por trás de cada componente. Quase ninguém faz isso, e é a diferença entre um system que você segue e um com o qual você discute. Ignore: a estética, que é deliberadamente institucional.

Consolidado, minuciosamente documentado e excepcionalmente forte em diretrizes de conteúdo e voz, em vez de apenas especificações visuais — a parte de um design system que a maioria das equipes nunca escreve.

Adote: os padrões de redação e conteúdo. Se o seu system não tem uma seção sobre como as coisas são redigidas, este é o modelo. Ignore: nada em particular; é uma referência geral razoável.

Esta categoria confunde as pessoas, então vale a pena dizer claramente: vários dos design systems mais citados não podem ser baixados. O que existe é a escrita publicada pelas equipes sobre eles, que muitas vezes é mais útil do que o código seria.

Há um padrão naquela tabela que vale a pena notar: os sistemas com as identidades visuais mais fortes são os que menos publicam. Isso não é coincidência nem um segredo competitivo. Um sistema que existe para fazer um produto parecer ele mesmo não tem nada a ganhar sendo instalável, e um sistema construído para ser adotado por milhares de equipes precisa ser neutro o suficiente para sobreviver a isso. Neutralidade e identidade são trocas inversas.

Os sistemas acima são os que valem a leitura atenta. Estes a seguir valem a pena saber que existem, com a única coisa em que cada um é realmente bom.

Ambos importam por um motivo fácil de ignorar: eles definem as convenções que seus usuários já aprenderam. Mesmo que você não construa nada com eles, eles definem o que significa "o botão voltar se comporta normalmente". O DLS do Airbnb traçou sua linha de divergência de plataforma precisamente em torno do que esses dois detêm.

O Cloudscape é o subestimado. A maioria dos sistemas publicados é otimizada para marketing e UIs de aplicações gerais; pouquíssimos levam a sério interfaces operacionais densas, e os que levam raramente publicam. Se você constrói software de administração ou console, ele está mais próximo do seu problema do que o Material ou o Polaris.

Esta linha merece destaque porque é onde a maioria das equipes realmente está. Adotar Radix mais shadcn mais Tailwind oferece um excelente comportamento acessível, uma camada de tokens e uma estratégia de distribuição — e nenhuma decisão sobre densidade, composição, motivos ou o que é proibido. Essa combinação produz a interface consistente, competente e inteiramente intercambiável que as pessoas descrevem como tendo aparência de gerada por IA. A distinção completa.

Vários catálogos extensos indexam design systems públicos e respondem bem a uma pergunta específica: alguém no meu setor resolveu isso e como chamou? Uma galeria de componentes é genuinamente útil para ver onze abordagens diferentes de um date picker lado a lado antes de você projetar a décima segunda.

O que eles não fazem é dizer qual sistema vale a pena estudar. Uma entrada de diretório é um link e um screenshot; o raciocínio está na escrita da equipe, não no catálogo. Use-os para amplitude e vá à fonte para profundidade.

Cada exemplo acima é uma documentação que você lê. Essa é a limitação intrínseca do formato: um design system só pode ser julgado quando as mesmas decisões são transportadas para telas que não têm nada a ver uma com a outra. Uma landing page prova que um sistema pode parecer bonito uma vez. Uma landing page, um dashboard e uma folha de componentes construídos a partir de um único conjunto de tokens provam que ele se sustenta.

Estes são sistemas completos renderizados ao vivo, não screenshots. Cada um é um conjunto de tokens aplicado em três superfícies não relacionadas — portanto, o que você está verificando não é se gosta das cores, mas se as *mesmas* decisões sobrevivem a um hero de marketing e a uma tabela densa.

A versão mais valiosa deste exercício é aquela que ninguém publicou, sobre um produto do seu próprio setor. Leva cerca de uma hora.

1. 1

   Capture três telas, não apenas uma

   Uma tela mostra a paleta. Três mostram quais decisões se repetem, e a repetição é o que distingue um sistema de uma página.

2. 2

   Leia valores computados, não tente adivinhar no olho

   Abra as ferramentas de desenvolvedor e anote font-weight, letter-spacing, border-width, border-radius e padding. "Espaçamento apertado" é uma impressão; -0.022em acima de 48px é uma regra.

3. 3

   Procure a faixa, não o valor

   A descoberta raramente é um único número. É que cada peso cai entre 400 e 510, ou que o raio é sempre 6 ou 12. Faixas são regras; valores únicos são amostras.

4. 4

   Anote o que está ausente

   Sem sombras. Sem gradientes. Sem segunda cor de destaque. Nenhum peso acima de 510. As ausências são o resultado de maior valor de um teardown e a primeira coisa perdida em qualquer extração automatizada.

5. 5

   Converta cada observação em uma instrução

   "A elevação é um degrau de superfície mais uma borda de 1px, nunca um box-shadow" é executável. "Minimalista e preciso" não é. Este passo é onde um teardown se torna um design system.

O passo quatro é aquele em que se deve insistir. Analisamos 299 arquivos DESIGN.md escritos para dar orientações de design a agentes de IA e descobrimos que 76% não contêm nenhuma proibição, além de 86% especificarem cores como hex puro sem papel semântico e 57% não definirem motivos distintos. Esses arquivos descrevem uma paleta. A identidade que tentavam capturar estava nas ausências.

Existe uma forma de estudar design systems que produz algo pior do que começar do zero. Isso acontece quando o exercício se torna acquisitivo: ao reunir as melhores partes de nove sistemas, você obtém uma interface competente, mas sem nenhum argumento por trás dela.

Cada sistema acima é resultado de uma decisão sobre o usuário. A densidade do Linear é um argumento de que um power user, que utiliza a ferramenta o dia todo, deseja sobriedade e informação. A simplicidade do GOV.UK é um argumento de que o usuário pode estar estressado, com uma conexão ruim e que não se pode presumir que ele tenha qualquer recurso. A neutralidade do Carbon é um argumento de que milhares de equipes irão adotá-lo e nenhuma delas é a equipe de marca da IBM.

Use esses exemplos para calibrar o rigor — o quão específicos os números se tornam, quantas coisas são proibidas, quão estreitos são os intervalos. Depois, construa seu próprio argumento sobre seu usuário e deixe que as regras derivem disso.