Vortex: one foundation for many brands

Starting a digital product often means rebuilding the same foundations: color, type, spacing, buttons, forms and navigation. Existing libraries speed up the first screen, but that advantage disappears when a brand needs to look and behave differently. Vortex began as an internal test: could one system support distinct brands without rebuilding the product layer each time?

Vortex is a design system and Figma library built around one question: could a single system serve multiple brands by changing only its foundations?

Not a theme switcher sitting on top of a fixed look, but a foundation where rebranding means swapping the lowest layer and leaving everything above it untouched- component design, accessibility, and the meaning behind each color.

I led Vortex’s design side end to end: the three-layer token architecture, type and color scales, component design, variants and Figma library. Ugi led design engineering, architecting the React library, component APIs and supporting tooling. We developed the system together rather than passing work across a handoff, testing decisions in Figma and working code before either of us called them done.

Rebrand by changing one layer

Every company structures its design tokens differently, so each new project started as a translation exercise before any real design work began. Vortex uses three layers instead. The global layer holds raw values — the color scales, the spacing steps. The semantic layer gives them meaning: this color is a surface, this one is a border. Most components read those semantic roles directly. Component tokens come in only when a recurring component decision needs its own mapping.

A rebrand usually touches only the global layer, and everything downstream updates with it. Contrast and hierarchy live in the semantic roles, so a palette change doesn’t quietly weaken legibility or force components to be rewired. Three working theme configurations now stress-test that architecture across different color, type, and tonal directions.

Change the foundations by default. Remap the exceptions when the brand requires it.

Speak one language in Figma and Code

A design system fails at its seams, where a designer's name for something and an engineer's name for the same thing slowly drift apart. In Vortex, all 44 component families carry matching names and structures across Figma and React. Tokens, variants and states follow the same vocabulary. Handoff becomes a lookup rather than an interpretation.

Storybook provides a working environment for every component, while the public documentation brings stable components together with their properties, states, implementation examples and accessibility guidance.

That structure turns out to matter for AI tools as well — exposed through an MCP server, the system hands a coding agent the real props and variants to build with, instead of of approximating an interface from a screenshot. The goal is not simply to generate more interface faster. It is to reduce the translation between a design decision and the working product.

Let the system carry the tedious work

This is the point where Vortex stopped being an idea and started giving me hours back. Responsive design used to mean restating the same decision at every breakpoint: a mobile gap, a tablet gap, a desktop gap, then the padding, width and type changes around it. In Vortex, responsive values travel with the component. A heading size carries its mobile and desktop step as one thing, and a layout takes a value per breakpoint as a property rather than a spec I have to redline and hand over.

Accessibility arrives the same way. Focus states, keyboard navigation, dismissing a menu, holding the page still behind a modal — the details that are easiest to leave out of a spec and hardest to retrofit — come with the component instead of depending on me remembering to ask. The rules are strict, but the range is wide: the same primitives compose loosely enough for a marketing page and hold tightly enough for a dense application screen.

“I design the decision, not every place it lands.”

<WorkspaceShell gap={{ sm:16, md:24, lg:32 }} columns={{ sm:1, md:2, lg:3 }} />

Current outcome

Vortex has moved from a token experiment into a working internal system: three theme configurations and 44 component families shared across Figma and React. Every component is represented in Storybook, while 16 are currently documented publicly. The same foundation is now being exercised through the Vortex documentation site and an internal product, giving us both marketing and application contexts in which to test it.

The most important result so far is architectural. A new visual direction can be introduced at the foundation layer while the semantic structure, component design and React APIs remain intact.

Vortex is still evolving, but it has already changed where the work happens: less time rebuilding familiar interface decisions, and more time deciding what is unique to the product.

One system, many places to work and ship

Figma libraryDesign source of truth

React packageCode source of truth

StorybookComponent reference

DocumentationUsage and guidance

Vortex

Foundationswappable

Semantic rolesstable

Componentsshared

I build design systems and reusable foundations that let small teams ship branded products without rebuilding the basics each time. Starting one from scratch? Get in touch