The Delta Design System

Details

Deliverables
Figma
HTML
Storybook

Skills
Design Systems
Figma
Responsive Design
Design Tokens
Auto-Layout
Variable Modes
Accessibility
Documentation

Summary

I build design systems the way I build everything: with intention, efficiency, and a bias toward things that actually work.

The Delta Design System started years ago as a bespoke HTML and SCSS framework — a personal toolkit I built because I was tired of fighting against other people's code. I loved frameworks like Bootstrap and Foundation, but I always ended up spending more time customizing them than building with them. The Delta Design System was my answer: something simple, semantic, and wicked efficient.

The name comes from the mathematical symbol for change (Δ). Design systems are living things. They have to evolve as practices, patterns, and tools evolve — or they become dead weight.

The current Figma library is the latest evolution. Though it was built from the ground up in Figma, it is based on the legacy code system and informed through years of practical experience. Nothing was thrown away — the principles, the architecture, and the lessons all carried forward.

A Decade of Integration

I specialize in the connection between design and development. The Delta Design System is the culmination of more than a decade of that integration work.

I'd always planned to bring the system into a design tool. I started a version in Sketch, but could see that Figma was on the horizon — and I needed time to understand it deeply before committing. Through professional client work involving complex Figma builds with auto layout, variable modes, and multi-brand token systems, I built the fluency I needed. When I was ready, I rebuilt The Delta Design System as a Figma-native library with the same foundational thinking that made the original code system work.

The result is a system where design decisions and code decisions speak the same language — because that's always been the point.

Everything Has Purpose

One of the core principles of The Delta Design System is that everything is named by its purpose, not its appearance.

Colors aren't named red or dark-blue. They're named brand/primary, text/default, page/background — names that describe what the color does, not what it looks like. Layer names in Figma map directly to class names in code. Variable names describe their role in the system. This purpose-driven naming convention runs through components, layers, variables, and documentation.

The benefit is practical: someone picking up the system for the first time doesn't need to memorize a color palette or decode abstract naming schemes. They look for what they need by what it does, and the name tells them which one to use.

Figma color variables panel showing semantic token names like text/default, text/link, and status/invalid with light and dark mode columns

The Token Architecture

The foundation of The Delta Design System is a responsive token system built entirely with Figma variables and variable modes.

Every design decision — color, spacing, typography, border radius — is encoded as a variable with mode-specific values. A spacing token like md resolves to 0.5rem / 8px on mobile and 1rem / 16px on widescreen. A color token like text/default resolves to black in light mode and white in dark mode. The system handles the complexity so the components don't have to.

Tokens are organized in layers: global values feed into semantic aliases, which feed into component-specific bindings. A component's font size doesn't reference a hardcoded pixel value — it references a token like p/font-size, which the system resolves differently at each breakpoint. Change the token once, and every component that references it updates automatically.

This is the kind of infrastructure that should be invisible. When it works, nobody thinks about it. They just use the components, and the components do the right thing at every size and in every mode.

Figma variables panel showing spacing and border-radius tokens with mobile, tablet, and widescreen columns

Figma variables panel showing typography tokens for headings h1 through h4 with mobile and widescreen columns

Component Architecture

The Delta Design System's documentation follows an atomic design hierarchy — a methodology developed by Brad Frost — organizing components as atoms, molecules, and organisms.

Atoms are the fundamental building blocks — badges, buttons, chips, icons, inputs, links, lists, and blockquotes. Each one is fully specified with responsive tokens, light and dark mode support, and documented states.

Molecules combine atoms into functional units — cards, content blocks, feedback indicators, fieldsets, messages, pagination, and tables. They reference their child atoms rather than duplicating specifications, keeping the system DRY and maintainable.

Organisms are the largest structures — banners, footers, headers, and tab systems. These are complex assemblies with their own layout logic, but they still inherit the same token system all the way down.

In the Figma library itself, components are organized alphabetically for fast access. Within each component family, elements are grouped by their atomic level where applicable. The atom/molecule/organism framework governs the documentation structure and the conceptual relationships between components — not the file organization.

Every component is built with auto layout, so responsive behavior is structural — not cosmetic. Components don't just shrink at smaller viewports. They reorganize.

Figma canvas showing the Button component set with 18 variants across color, style, and state

Figma sample page showing a Tabs component and content card in light mode

The same Figma sample page shown in dark mode with teal background and inverted colors

Figma Documentation page zoomed out showing Foundations, Atoms, Molecules, and Organisms sections — The full documentation set: Foundations, Atoms, Molecules, and Organisms — organized by Brad Frost's atomic design methodology.

The Documentation Pipeline

A design system is only as good as its documentation. If people can't find and trust the specs, they'll make it up — and the system stops being a system.

The Delta Design System's documentation pipeline runs from Figma to comprehensive HTML specification documents. Each component gets a full write-up: anatomy, variants, states, typography, spacing, border radius, colors (light and dark), accessibility guidance, usage guidelines, and code reference. Every value in every table traces back to a verified Figma variable — nothing is assumed, nothing is guessed.

The HTML documents follow a strict standard with consistent structure, terminology, and formatting across all components. This consistency is the point. A developer who reads the Button spec knows exactly where to look in the Card spec, because the structure never changes.

The purpose-driven naming conventions carry through from Figma into the code. Layer names become class names. Variable names become CSS custom properties. A developer reading the rendered code in Figma sees the same names they'll write in their stylesheet — no translation required.

A Storybook integration is in progress to provide a living code reference alongside the Figma library — the developer-facing counterpart to the design tool. The goal is a single system with two views: Figma for designers, Storybook for developers, both telling the same story with the same values.

Buttons documentation page rendered in a browser showing the title, anatomy, and variants sections — Each component's HTML specification follows a consistent structure: anatomy, variants, states, token tables, accessibility, usage, and code reference.

Storybook interface showing the Tabs component documentation story with an accessibility testing panel — Storybook provides the developer-facing view of the same system — same specs, same values, same structure — with built-in accessibility testing.

What The Delta Design System Demonstrates

This isn't a portfolio exercise. It's a working system built with the same rigor I bring to professional projects:

Systems thinking — Every decision propagates. Token architecture, alias chains, and mode-aware variables mean a single change cascades correctly across hundreds of components.
Design-engineering bridge — The pipeline from Figma to code is intentional and documented. Designers and developers reference the same source of truth. Layer names in Figma match class names in code match selectors in Storybook.
Responsive design at the variable level — Responsiveness isn't bolted on with media queries alone. It's built into the token system itself. Components inherit responsive behavior from the tokens they reference.
Purpose-driven naming — Everything is named by what it does, not what it looks like. This makes the system intuitive to learn and consistent to use, from Figma layers to CSS custom properties.
Accessibility as infrastructure — WCAG compliance, keyboard navigation, ARIA patterns, and color contrast requirements are documented for every component — not as an afterthought, but as part of the specification.
Craft — Standards and templates are efficiency tools. They're invisible infrastructure that people trust without unpacking. The goal is to simplify and standardize so that the next person — the developer picking up a component, the designer referencing a doc page — can just use it and move forward.

My father was a carpenter. He taught me that good craft disappears — the doors close flush, the drawers slide true, and you just trust it. That's what a design system should be. Not a showcase of how many tokens you can define, but invisible infrastructure that lets the next person build something good without thinking twice about the foundation underneath.