Gestão
Do Manual de Marca 2026 ao componente em tela: o caminho que uma decisão visual percorre no design system público da Uranus, e por que cada peça existe.
Em qualquer empresa que cresce rápido, a primeira coisa a escapar é a consistência visual. Três squads 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, em sete arquivos, e esquece o oitavo. A marca vira um alvo móvel. 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 os produtos da Uranus.
O Uranus Design System é a implementação em código do Manual de Marca Uranus 2026: um monorepo que sai da decisão de marca ("nosso azul profundo é #000328") e chega ao componente React que o desenvolvedor importa e usa em produção, passando por três camadas encaixadas. Não é biblioteca de componentes avulsa nem Figma bonito sem backend.
A stack é deliberadamente simples: shadcn/ui como base de 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 seja produtivo em uma semana, e que qualquer decisão de marca seja rastreável até um único arquivo TypeScript.
O sistema se organiza em quatro áreas visíveis na navegação:
A documentação do sistema tem uma frase que vale 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 material de marketing reproduz.
Tipografia. Uma única família: Poppins. A 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 é 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 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. Requisito, não checklist opcional.
A arquitetura do sistema segue um fluxo de três saltos. 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 arquivo só. 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á hexadecimal espalhado pelo código. Há uma referência única, e as aplicações consomem essa referência.
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 a inconsistência aparece primeiro.
O botão Uranus tem seis variantes, cada uma com um uso específico:
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.
Componentes isolados resolvem a unidade. Blocos resolvem a tela. O Uranus Design System expõe blocos prontos como Page Header, Hero, CTA de contato e 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 entre título e 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 liberam a criatividade para o que importa: a mensagem, o copy, a estratégia visual de cada campanha.
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 posicionamento próprio, essa compressão contra concorrentes visuais sai cara, mesmo quando o custo inicial é 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 foi projetado para ser copiado, forkado e tornado nosso, em vez de 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.
Se você lidera engenharia em uma empresa entre vinte e duzentos desenvolvedores, provavelmente está em um destes 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 a marca amarrada à estética de outra empresa. A saída é a mesma nos três: centralizar as decisões de marca em tokens tipados e deixar a arquitetura distribuir essas decisões automaticamente.
A documentação completa do Uranus Design System está em design.uranus.com.br. É pública e consultável, e mostra não só os componentes mas as razões por trás de cada decisão. Essa é a parte que mais interessa a quem está pensando em construir o próprio sistema.
Leia também: Por que automação inteligente não é RPA