Management
From the 2026 Brand Manual to the component on screen: the path a visual decision takes through the Uranus design system, and why each layer exists.
In any fast-growing company, visual consistency is the first thing to slip. Three squads build the same button three ways, each with a slightly different "official" blue. Someone fixes the blue in Figma, but the code stays wrong. Someone fixes it in code, across seven files, and misses the eighth. The brand becomes a moving target. We built the Uranus Design System to attack that problem, and it ships today as a public reference and the single source of truth for Uranus products.
The Uranus Design System is the code implementation of the Uranus 2026 Brand Manual: a monorepo that starts at a brand decision ("our deep blue is #000328") and ends at the React component a developer imports and ships to production, with three interlocking layers in between. It's not a standalone component library, and it's not a good-looking Figma file with nothing behind it.
The stack is deliberately plain: shadcn/ui for primitives, Tailwind CSS v4 for styling, Motion for animation. None of those choices are decorative. We want any engineer who has touched Tailwind to be productive within a week, and any brand decision to be traceable to a single TypeScript file.
The system is organized into four areas, visible in the navigation:
The system's documentation has one line worth pinning up: "Foundations are the decisions every Uranus interface inherits." That's not rhetoric. It's the line between a system that scales and one that becomes legacy in six months.
The foundations cover five domains:
Color. A cosmic palette built on four base values: Deep Blue (#000328), Navy Blue (#082d71), Turquoise Blue (#5dddfa) and Light Lilac (#f8ddfc), each expanded into a full tonal scale. The signature gradient combines the two blues and the lilac in a curve that every marketing asset reproduces.
Typography. One family: Poppins. The choice is deliberate. An early design system that offers three type families is offering three answers to the same question, and it inevitably becomes four. The scale is modular, defined in tokens, and runs from 72px display down to 12px caption.
Spacing. A 4px grid with named scales (xs, sm, md, lg, xl, 2xl...) reused across padding, margin, gap and container width. No magic values in the application CSS: everything comes from a token.
Motion. Standardized durations, easings and transition patterns. A component that opens over 320ms with out-cubic easing is a brand decision, not the preference of whoever wrote that screen.
Accessibility. Minimum contrast, focus order, screen-reader labels, touch targets of at least 44px. A requirement, not an optional checklist.
The architecture follows a three-hop flow. Understanding that flow is understanding why the design system works:
packages/tokens/src/*.ts
↓
packages/tailwind-config
↓
packages/ui (consumed components)
Everything starts in @uranus-workspace/tokens, where each brand decision lives as a typed TypeScript value. Changing the deep blue means editing one file. The change flows automatically into @uranus-workspace/tailwind-config, which exposes the tokens as Tailwind variables (bg-brand-deep, text-brand-turquoise), and from there into every component that uses those classes. Regenerate the CSS, publish the package, and every application that bumps the dependency inherits the change.
That solves the classic "the official blue changed, but only partly" problem. There's no hex scattered through the code. There's one reference, and applications consume it.
The button is the best example of how foundations and components fit together in practice. It's the most common element in any interface, and it's where inconsistency shows up first.
The Uranus button has six variants, each with a specific use:
And four sizes: sm, md (default), lg and icon (square, for icon-only buttons, and always requires an aria-label).
Behind that, the guidelines are firm: one primary per screen, never two primaries side by side, destructive actions always behind a confirmation dialog, labels in the imperative ("Save", not "Saving"). Activation by Enter and Space, correct announcement of the disabled state, a visible focus ring at all times.
Those rules are not comments in the component. They are encoded in the variants, in the typed props and in the examples the documentation shows. An engineer who tries to stack two primaries has to write code that goes against the grain of the system.
Isolated components solve the unit. Blocks solve the screen. The Uranus Design System ships ready-made blocks such as Page Header, Hero, contact CTA and Footer: compositions that combine several components with spacing tokens, tested responsiveness and content variants.
The practical difference is this: building a new landing page shouldn't mean re-deciding the hero's vertical padding, the alignment between title and subtitle, or the relationship between the primary button and the secondary link. Those decisions were made in the brand manual, encapsulated in the block and reused on any page that needs a hero, from the main landing page to the blog you are reading now.
Blocks do not replace creativity. They remove rework and free that creativity for what matters: the message, the copy, the visual strategy of each campaign.
The fair question is: why not use an existing, off-the-shelf system? Material Design, Carbon, Radix, even plain shadcn would cover a good part of the work.
Three reasons, and they hold for any company facing the same decision.
The first is identity. A design system is the brand encoded as software. Using Material means looking like Google. Using Carbon means looking like IBM. For a company that wants its own positioning, being visually compressed against competitors is expensive, even when the upfront cost is low.
The second is control over how it evolves. Public systems move at the pace of whoever maintains them. Breaking changes arrive in major releases you adopt when you can. Your own system moves at your company's pace, with deprecations that make sense for your codebase.
The third is composition with the rest of the stack. An internal design system can reference the service catalog, integrate with the product's i18n, consume the same tokens marketing uses in Figma. It touches everything. A generic system has to be worked around for any of those integrations, and the workaround becomes debt.
None of this means reinventing the wheel. The Uranus Design System uses shadcn/ui as its substrate precisely because shadcn was designed to be copied, forked and made ours, rather than consumed as an opaque dependency. The difference between "building from scratch" and "assembling on top of shadcn with Tailwind v4" is the difference between six months and six weeks of work.
If you lead engineering at a company with twenty to two hundred developers, you're probably in one of these situations: (a) you have no design system and feel the inconsistency every week, (b) you have three competing internal libraries nobody can unify, or (c) you depend on a public system and feel the brand tied to another company's aesthetic. The way out is the same in all three: centralize brand decisions in typed tokens and let the architecture distribute those decisions automatically.
The full Uranus Design System documentation is at design.uranus.com.br. It's public and browsable, and it shows not just the components but the reasoning behind each decision. That's the part that matters most to anyone thinking about building their own.
Read also: Why intelligent automation is not RPA