Em qualquer empresa que cresce rápido, a primeira coisa a escapar é a consistência visual. Três squads diferentes implementam o mesmo botão de três jeitos, cada um com um azul “oficial” ligeiramente diferente. Alguém corrige o azul no Figma, mas o código continua errado. Alguém corrige no código, mas em sete arquivos — e esquece o oitavo. A marca vira um alvo móvel que nunca é atingido. Foi para atacar esse problema que construímos o Uranus Design System, publicado hoje como referência pública e fonte única de verdade para o ecossistema Uranus.

O que exatamente é o sistema

O Uranus Design System é a implementação em código do Manual de Marca Uranus 2026. Não é uma biblioteca de componentes avulsa, nem um Figma bonito sem backend. É um monorepo que vai da decisão de marca — “nosso azul profundo é `#000328`“ — até o componente React que um desenvolvedor importa e usa em produção, passando por três camadas encaixadas.

A stack é deliberadamente simples: shadcn/ui como base de componentes primitivos, Tailwind CSS v4 como mecanismo de estilização, e Motion para animações. Nenhuma dessas escolhas é decorativa. Queremos que qualquer engenheiro que já tenha tocado Tailwind consiga ser produtivo em uma semana, e que qualquer decisão de marca seja rastreável até um arquivo TypeScript único.

O sistema se organiza em quatro áreas visíveis na navegação:

• Fundamentos — as decisões herdadas por tudo que vem depois

• Componentes — primitivos isolados (botão, input, card)

• Blocos — composições maiores e prontas (header de página, hero, CTA)

• Documentação — princípios, uso, acessibilidade

Fundamentos são as decisões que toda interface herda

A documentação do sistema tem uma frase que vale a pena fixar: “Foundations são as decisões que toda interface Uranus herda”. Isso não é retórica. É a linha divisória entre um sistema que escala e um que vira legado em seis meses.

Os fundamentos cobrem cinco domínios:

Cor. Uma paleta cósmica de quatro valores-base — Azul Profundo (`#000328`), Azul Marinho (`#082d71`), Azul Turquesa (`#5dddfa`) e Lilás Claro (`#f8ddfc`) — que expandem em escalas tonais completas. O gradiente marca-registrada combina os dois azuis e o lilás em uma curva que todo marketing material reproduz.

Tipografia. Uma única família: Poppins. Escolha deliberada: um design system inicial que oferece três famílias tipográficas está oferecendo três opções para o mesmo problema, e inevitavelmente vira quatro. A escala tipográfica é modular, definida em tokens, e cobre de display 72px até caption 12px.

Espaçamento. Uma grade de 4px, com escalas nomeadas (`xs`, `sm`, `md`, `lg`, `xl`, `2xl`…) que se repetem em padding, margin, gap e largura de container. Nenhum valor “mágico” no CSS da aplicação — tudo sai de token.

Motion. Durações, easings e padrões de transição padronizados. Um componente que abre com duração de 320ms e easing `out-cubic` é uma decisão de marca, não uma preferência do engenheiro que escreveu aquela tela.

Acessibilidade. Contraste mínimo, ordem de foco, rótulos para leitores de tela, alvos de toque de pelo menos 44px. Tratada como requisito, não como checklist opcional.

O caminho do token ao componente

A arquitetura do sistema segue um fluxo de três saltos, e entender esse fluxo é entender por que o design system funciona:

packages/tokens/src/*.ts
↓
packages/tailwind-config
↓
packages/ui (componentes consumidos)

Tudo começa em `@uranus-workspace/tokens`, onde cada decisão de marca vive como um valor TypeScript tipado. Mudar o azul profundo significa editar um único arquivo. A mudança flui automaticamente para `@uranus-workspace/tailwind-config`, que expõe os tokens como variáveis Tailwind (`bg-brand-deep`, `text-brand-turquoise`), e daí para cada componente que consome essas classes. Regenera o CSS, publica o pacote, e toda aplicação que atualiza a dependência herda a mudança.

Isso resolve o problema clássico do “azul oficial que mudou, mas só parcialmente”. Não há azul hexadecimal espalhado pelo código. Há uma referência única, e as aplicações consomem essa referência.

Um componente de perto: o botão

Para ver como fundamentos e componentes se encaixam na prática, o botão é o melhor exemplo. É o elemento mais comum de qualquer interface, e é onde inconsistências aparecem mais rápido.

O botão Uranus tem seis variantes, cada uma com um uso específico:

• Primary — a ação principal de uma superfície, uma por tela

• Secondary — ações de apoio que ainda precisam de peso

• Outline — alternativa de menor ênfase, tipicamente pareada com primary

• Ghost — barras de ferramentas, ícones inline, afordâncias terciárias

• Destructive — ações irreversíveis ou de alto impacto

• Link — navegação inline que lê como texto corrido

E quatro tamanhos: `sm`, `md` (padrão), `lg` e `icon` (quadrado, usado quando há apenas ícone e sempre exige `aria-label`).

Por trás disso, as diretrizes são firmes: um único primary por tela, nunca dois primaries lado a lado, ações destrutivas sempre em diálogos de confirmação, rótulos em imperativo (“Salvar”, não “Salvamento”). Ativação por Enter e Espaço, anúncio correto de estado desabilitado, anel de foco visível sempre.

Essas regras não estão no componente como comentários — estão codificadas nas variantes, nos props tipados e nos exemplos que a documentação mostra. Um engenheiro que tenta empilhar dois primaries precisa escrever código que vai contra o grão do sistema.

Blocos: composições que resolvem tela inteira

Componentes isolados resolvem a unidade. Blocos resolvem a tela. O Uranus Design System expõe blocos prontos como Page Header, Hero, CTA de contato, Footer — composições que combinam múltiplos componentes com tokens de espaçamento, responsividade testada e variantes de conteúdo.

A diferença prática é essa: montar uma landing page nova não deveria significar decidir de novo o padding vertical do hero, o alinhamento do título e do subtítulo, ou a relação entre o botão primário e o link secundário. Essas decisões foram tomadas no manual de marca, encapsuladas no bloco, e reusadas em qualquer página que precise de um hero — da landing principal ao blog que você está lendo agora.

Blocos não substituem criatividade. Eles removem retrabalho e deixam a criatividade disponível para o que realmente importa — a mensagem, o copy, a estratégia visual de cada campanha.

Por que construímos em vez de comprar

A pergunta razoável é: por que não usar um sistema existente e pronto? Material Design, Carbon, Radix, até o shadcn puro resolveriam boa parte do trabalho.

Três razões, que valem para qualquer empresa considerando essa decisão.

A primeira é identidade. Um sistema de design é a codificação da marca em software. Usar Material significa parecer com o Google. Usar Carbon significa parecer com a IBM. Para uma empresa que quer ter posicionamento próprio, essa compressão contra concorrentes visuais é cara demais — mesmo que o custo inicial seja baixo.

A segunda é controle de evolução. Sistemas públicos evoluem no ritmo de quem os mantém. Mudanças incompatíveis aparecem em releases major que você vai consumir quando puder. Um sistema próprio evolui no ritmo da sua empresa, com deprecations que fazem sentido para a sua base de código.

A terceira é composição com o resto da stack. Um design system interno pode referenciar o catálogo de serviços, integrar com o i18n do produto, consumir os mesmos tokens que o marketing usa em Figma. Ele encosta em tudo. Um sistema genérico precisa ser contornado para fazer qualquer uma dessas integrações, e o contorno vira dívida.

Nada disso significa reinventar a roda. O Uranus Design System usa shadcn/ui como substrato exatamente porque shadcn é projetado para ser copiado, forkado e tornado nosso — não consumido como dependência opaca. A diferença entre “construir do zero” e “montar em cima do shadcn com Tailwind v4” é a diferença entre seis meses e seis semanas de trabalho.

Onde isso encosta no trabalho real

Se você lidera engenharia em uma empresa que está entre vinte e duzentos desenvolvedores, provavelmente está em um dos três cenários: (a) não tem design system e sente a inconsistência toda semana, (b) tem três bibliotecas internas concorrentes que ninguém consegue unificar, ou (c) depende de um sistema público e sente que a marca está amarrada à estética de outra empresa. Os três cenários têm a mesma solução: centralizar as decisões de marca em tokens tipados, e deixar que a arquitetura distribua essas decisões automaticamente.

A documentação completa do Uranus Design System está em design.uranus.com.br. Ela é pública, consultável, e mostra não só os componentes mas as razões por trás de cada decisão — que é a parte que mais interessa para qualquer engenheiro que está pensando em construir o próprio sistema.

Leia também: Por que automação inteligente não é RPA