Comece pelo problema, não pela lista
Listas de design systems geralmente são organizadas por empresa, que é o eixo menos útil: você já sabe quem é o Airbnb, e esse fato não diz se o sistema deles será útil para você. Aqui está o mesmo conjunto organizado pelo que você está tentando resolver.
| Leia | Porque | |
|---|---|---|
| "Onde ficam os componentes específicos do produto?" | Carbon, Encore | Ambos resolveram com camadas: uma fundação que não pode ser sobrescrita e subsistemas especializados acima dela |
| "Como faço para as pessoas realmente seguirem o sistema?" | Stripe, SLDS 2 | Um remove a capacidade de desviar; o outro usa linting para isso. A documentação é a terceira opção, e ela perde |
| "Como mantenho quatro plataformas consistentes?" | Airbnb DLS | Componentes definidos por contrato em vez de composição: a única coisa que sobrevive a quatro implementações |
| "Como permito que os clientes customizem o tema profundamente?" | SLDS 2, Stripe Elements | Desacoplamento de estrutura e estilo visual, e uma hierarquia de tema→variáveis→regras |
| "Por que meu produto parece genérico?" | Linear | A identidade vem do que um sistema se recusa a fazer, e as recusas são o que a maioria dos sistemas omite |
| "Como devo entregar isso para os consumidores?" | Polaris | Se você ou seus consumidores controlam a versão depende de quem é o responsável pela aparência |
O restante deste texto analisa cada um deles, detalhando o que está disponível e o que vale a pena adotar.
Os três que mudaram nos últimos dezoito meses
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.
| O que mudou | A aposta | |
|---|---|---|
| IBM Carbon | Lançou um servidor MCP que expõe documentação, exemplos de código de componentes, gráficos e componentes experimentais para agentes | Agentes devem recuperar o sistema no momento da geração, em vez de tentar lembrá-lo a partir dos dados de treinamento |
| Salesforce Lightning | SLDS 2: arquitetura CSS desacoplada do estilo visual padrão, styling hooks como custom properties, um linter validando a marcação | Estrutura e aparência devem ser separadas, e as violações devem ser detectadas mecanicamente |
| Shopify Polaris | React descontinuado em favor de web components agnósticos a frameworks, servidos via CDN | A entrega não deve assumir qual framework gerou a página |
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.
Os abertos e instaláveis
IBM Carbon
Open source, financiado e construído pela IBM, baseado na IBM Design Language como uma camada separada de fundação de marca, com sistemas de domínio (IBM Products, Cloud, IBM.com) acima do núcleo. 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 sistemas 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.
Shopify Polaris
Foundations, tokens, componentes e mais de 400 ícones focados em e-commerce. 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 e-commerce se você atua nesse setor, 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.
Salesforce Lightning
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 CSS custom properties, 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 imposição. Ambos são copiáveis sem a necessidade de adotar uma única linha de CSS da Salesforce. Ignore: o framework em si, a menos que você desenvolva na Lightning Platform. Leitura completa.
GOV.UK Design System
O exemplo mais forte de um sistema 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 sistema que você segue e um com o qual você discute. Ignore: a estética, que é deliberadamente institucional.
Atlassian Design System
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 escrita e conteúdo. Se o seu sistema 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.
Os documentados, porém privados
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 teria sido.
| Disponível | O insight que vale a pena ter | |
|---|---|---|
| Stripe | Dois sistemas de integração públicos (Apps UI toolkit, Elements Appearance API); o sistema interno não é publicado | A postura segue o limite de confiança: vocabulário fechado na superfície da Stripe, uma escada de customização na sua |
| Airbnb DLS | Contas de equipe publicadas; sem pacote | Componentes como unidades autossuficientes com elementos declarados, rejeitando explicitamente a composição atômica |
| Spotify Encore | Documentação da equipe de design publicada; sem pacote | Camadas concêntricas e uma admissão pública de que a flexibilidade foi longe demais e precisou de uma nova camada para corrigir |
| Linear | Nada de primeira linha; extrações de terceiros com confiabilidade variável | A identidade é carregada pela restrição: uma faixa de peso estreita, linhas finas em vez de sombras, um único destaque usado com parcimônia |
Cuidado com "extrações" de sistemas privados feitas por terceiros. Um relatório de estilo extraído via scraping pode dizer que uma superfície tem um cinza específico. Ele não pode dizer se esse cinza é um passo deliberado em uma escala ou um acidente em uma página, e nunca captura as proibições, que é a parte que faria o design funcionar.
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 ou segredo competitivo. Um sistema que existe para fazer um produto parecer ele mesmo não tem nada a ganhar ao ser 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 forças opostas.
O restante do campo, brevemente
Os sistemas acima são os que vale a pena ler com atenção. Estes vale a pena saber que existem, com a única coisa para a qual cada um é realmente bom.
Sistemas de plataforma
| Considere | Cuidado com | |
|---|---|---|
| Material Design | O tratamento público mais completo sobre camadas de movimento e estado que existe. Seu modelo de elevação e estado de interação vale a pena ser lido mesmo que você nunca o utilize | Adotá-lo integralmente faz um produto web parecer um app de Android. Suas diretrizes são fortes e legíveis para os usuários |
| Apple Human Interface Guidelines | A escrita mais clara sobre *por que* uma convenção existe, em vez de apenas o que ela é. Excelente em idiomas de plataforma e acessibilidade | É uma orientação, não uma biblioteca de componentes. Não há nada para instalar, e aplicá-la fora da plataforma geralmente não funciona |
Ambos importam por um motivo que é fácil de ignorar: eles estabelecem 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 de voltar se comporta normalmente". A linha de divergência de plataforma do Airbnb foi traçada precisamente em torno do que esses dois dominam.
Sistemas de produtos de grande escala
| Vale a pena por | |
|---|---|
| GitHub Primer | Documentação excepcionalmente boa sobre *quando não* usar um componente, além de uma abordagem madura para entregar o mesmo sistema em Rails, React e páginas estáticas |
| Microsoft Fluent | A maior tentativa publicada de um sistema único para desktop, web e mobile com shells nativos genuinamente diferentes. Instrutivo principalmente por mostrar o quão difícil isso é |
| AWS Cloudscape | O melhor exemplo público de um sistema projetado especificamente para interfaces de console densas e carregadas de dados: tabelas, filtros, listas de recursos. Raro e útil se você constrói esse tipo de produto |
| Uber Base Web | Uma arquitetura de theming robusta e um modelo de override que permite aos consumidores acessar os detalhes internos dos componentes de forma estruturada |
O Cloudscape é o subestimado. A maioria dos sistemas publicados é otimizada para marketing e UI de aplicações genéricas; poucos levam interfaces operacionais densas a sério, 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.
Primitivos e distribuição
| O que é | O que não é | |
|---|---|---|
| Radix Primitives | Comportamento acessível e sem estilização para componentes complexos: menus, diálogos, comboboxes | Um design system. Ele deliberadamente não tem opinião sobre a aparência das coisas |
| shadcn/ui | Um mecanismo de distribuição e uma convenção de tokens: componentes copiados para o seu repo, não instalados como dependência | Um design system também. Ele define os nomes dos seus tokens, não a sua densidade, composição, motivos ou proibições |
| Tailwind | Um sistema de restrições para espaçamento, cor e tipografia aplicados no nível de classe | Opinativo sobre o seu produto. Seus padrões são neutros e amplamente utilizados, e é por isso que soam genéricos |
Esta linha merece destaque porque é onde a maioria dos times 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, sem decisões 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.
Os diretórios e para que servem
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 chamaram? 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 do time, não no catálogo. Use-os para ter amplitude e vá à fonte para ter profundidade.
Como um sistema parece aplicado, em vez de documentado
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, então 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.
Kit showcase · live surfaces
Verdant Finance
Live renderVerdant Finance rendered from its real tokens across 3 surfaces.
A pergunta a se fazer para qualquer exemplo
Não "isso é atraente", mas "eu conseguiria prever a próxima tela?". Um sistema real torna a décima segunda tela previsível a partir das três primeiras. Se você não consegue adivinhar como seria um modal após estudar a landing page e o dashboard, o sistema é um estilo, e um estilo não sobrevive a um segundo designer ou a um agente.
Fazendo sua própria análise técnica (teardown)
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
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
Leia valores computados, não tente estimar visualmente
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
Procure a faixa de valores, não o valor isolado
A descoberta raramente é um único número. É que cada peso fica entre 400 e 510, ou que o raio é sempre 6 ou 12. Faixas são regras; valores únicos são amostras.
- 4
Anote o que está ausente
Sem sombras. Sem gradientes. Sem segunda cor de destaque. Sem peso acima de 510. As ausências são o resultado de maior valor de um teardown e a primeira coisa a ser perdida em qualquer extração automatizada.
- 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 função semântica e 57% não definirem motivos distintos. Esses arquivos descrevem uma paleta. A identidade que tentavam capturar estava nas ausências.
Três quartos das orientações de design no mundo real não proíbem nada. Mas a identidade é construída pela recusa, e uma paleta copiada deixa as recusas para trás.
O erro a evitar
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: reúna as melhores partes de nove sistemas e você terá 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, busca 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 são os números, quantas coisas são proibidas, quão estreitas são as faixas de variação. Depois, construa seu próprio argumento sobre seu próprio usuário e deixe que as regras derivem disso.
Os design kits do Identity Forge são sistemas completos nesse sentido: papéis de cores semânticas para temas claro e escuro, escalas de tipografia e espaçamento, motivos e diretrizes explícitas de 'faça' e 'não faça', serializados em um DESIGN.md que um agente de código pode executar. Explore os kits ou leia o que é um arquivo DESIGN.md.
Quais são os melhores exemplos de design system para aprender?
Depende da sua pergunta. Carbon e Encore do Spotify para camadas (layering), Stripe e SLDS 2 para aplicação (enforcement) e temas, DLS do Airbnb para contratos multiplataforma, Polaris para entrega (delivery), Linear para como a restrição cria identidade, e GOV.UK para a publicação da pesquisa por trás de cada componente.
Quais design systems principais eu posso realmente baixar?
Carbon, Polaris, Lightning, GOV.UK e Atlassian estão disponíveis publicamente. O sistema interno do Stripe, o DLS do Airbnb, o Encore do Spotify e o sistema do Linear não estão: o que existe para eles são os textos publicados pelas equipes, que geralmente são artefatos mais úteis de qualquer maneira.
Devo copiar um design system que eu admiro?
Copie o rigor, não o conteúdo. Todo bom sistema é um conjunto de respostas a perguntas sobre um usuário específico; copiar as respostas sem as perguntas resultará em uma interface otimizada para o produto de outra pessoa. Use análises detalhadas (teardowns) para calibrar o quão específicas devem ser as suas próprias regras.
Por que tão poucas empresas publicam seus design systems?
Porque um sistema construído para tornar um produto distinto não ganha nada sendo instalável, enquanto um sistema construído para adoção ampla precisa ser neutro o suficiente para funcionar em milhares de produtos não relacionados. Publicar empurra um sistema em direção à neutralidade, que é o oposto do que uma marca forte deseja.
Vale a pena usar diretórios de design system?
Para amplitude, sim. Eles são bons para ver várias implementações do mesmo componente lado a lado antes de você projetar a sua. Para profundidade, não. Uma entrada de diretório é um link e um screenshot; o raciocínio que torna um sistema digno de estudo reside nos textos escritos pela própria equipe.