How design tokens create a translation layer between design decisions and code, enabling consistent styling across any platform.

From Figma to Production

UMD Design System

A token is just a key and a value. That's it. Brand red is #E21833. Base spacing is 8px. Body font is Source Sans. The simplicity is the point: there's nothing to misunderstand, nothing to configure wrong.

We export in every format anyone could need:

The real magic: when the brand team updates Maryland Red from #E21833 to something else (it happens), they change one file. That change cascades through every component, every site, every Storybook story. Nobody hunts through codebases replacing hex codes.

Stupid Simple

Here's a question: how many card variants does a university need? Block cards, list cards, overlay cards, video cards, person cards, event cards... We counted dozens. Building each one from scratch would mean duplicating accessibility logic, responsive behavior, and animation patterns. Maintaining them would be a nightmare.

Instead, we built atomic pieces that compose:

Every card variant is just a different composition of the same primitives. Add a new variant? Compose existing pieces. Fix a bug in the layout primitive? Every card that uses it gets the fix. The atomic approach turned a maintenance headache into a multiplication of capability.

Composition Over Configuration

We built tokens for websites. Then they started showing up in places we didn't plan:

Each platform consumes tokens in its native format. React imports JavaScript objects. PHP reads CSS variables. The email builder pulls from JSON. Same decisions, different implementations: exactly as Brad Frost described.

That's the payoff of treating design decisions as data rather than code: they become portable. Version them. Diff them. Roll them back. Share them across any technology stack without translation errors. The tokens package became the source of truth for the entire university's visual identity.

Tokens Travel

Brad Frost wrote something that changed how I think about design systems: the old separation of concerns (HTML for structure, CSS for presentation, JavaScript for behavior) is the wrong abstraction. The better split is between design decisions and their implementation.

A color isn't CSS. It's a decision. A spacing scale isn't pixels. It's a relationship. We built the entire token layer around this insight: capture the decision once, then let it flow everywhere: websites, apps, kiosks, Figma, wherever.

The New Separation of Concerns

How tree-shaking, modular consumption, and smart bundling keep the design system fast at any scale.

Every Kilobyte Counts

Tree shaking sounds automatic: just import what you need, and bundlers drop the rest. In practice, it's fragile. One side effect in your module, one CommonJS export, one circular dependency, and the whole bundle comes along for the ride.

The test: import one component and check the bundle. If anything else sneaks in, we've failed. This discipline means a simple landing page can use the design system and still score 100 on Lighthouse.

Designed for Tree Shaking

Not every team needs the full component library. Some need design decisions without the UI. Others need UI without the Web Component syntax. We built packages that meet teams where they are:

Each package builds on the layers below it, but you can stop at any level. A native app team using just tokens and a WordPress site using full components both get the same brand consistency—just at different depths.

Packages for Every Use Case

Performance discipline is easy to talk about and hard to maintain. A few rushed pull requests, and suddenly bundles are 50% larger. We removed willpower from the equation with automated gates.

The conversation changed. Instead of 'we should keep bundles small,' it became 'the CI won't let this merge.' Constraints beat intentions. Teams stopped proposing features that would blow the budget because they knew the pipeline would reject them.

Automated Guardrails

Here's the uncomfortable truth about design systems: most of them make sites slower. Import a component library, and suddenly you're shipping 200KB of JavaScript for a button and a card. Teams accept this tradeoff because consistency matters. But it doesn't have to be a tradeoff.

We treated performance as a constraint, not a feature. Every architectural decision got filtered through one question: what's the byte cost? Tree-shakeable exports, granular packages, CDN distribution: each choice earned its place by keeping bundles small.

The Performance Tax

How investing in shared infrastructure creates compounding value for a distributed community of adopters.

The Upstream Advantage

Most shared systems fail not because of bad code, but because of broken trust. A team adopts a library, then an update breaks their site. They fork it, fall behind on updates, and eventually abandon it. The pattern repeats across organizations.

We designed against this failure mode with aggressive automation:

The goal: adopters can update with confidence. When teams trust that updates won't break their sites, they stay on the latest version. When they stay current, they get every improvement automatically. Trust enables the compound returns.

The Trust Problem

Heavy dependencies kill adoption. If using one button means importing a megabyte of code, teams will build their own button. We structured the system so every piece stands alone.

A team can adopt just the tokens package to get brand colors in their existing app. A year later, they might add components. The path from minimal to full adoption is incremental, not all-or-nothing. This patience pays off: teams that start small often become the strongest advocates.

Granular by Design

In a decentralized organization, mandates backfire. Tell autonomous teams they must use a system, and they'll find reasons not to. Show them it solves their problems faster than alternatives, and they'll advocate for it themselves.

The strategy worked. Teams that initially resisted became early adopters once they saw colleagues shipping faster. Word of mouth drove more adoption than any top-down initiative could have. The upstream investment created its own gravity.

Earning Adoption

Here's the math that justified the investment: fix an accessibility bug once, and every site using the component gets the fix automatically. Optimize a bundle once, and every page load across the ecosystem gets faster. The value compounds with every adopter.

We designed for a future we couldn't predict. Would 50 sites adopt, or 500? The answer shaped every architectural decision: build the upstream infrastructure so well that adoption becomes inevitable, and every new adopter multiplies the return on investment.

Invest Once, Benefit Many

Josh Magness is a human-centric leader with proven success as an executive, manager, and software engineer

Recent Case Studies

From Figma to Production

Every Kilobyte Counts

The Upstream Advantage