Anatomy of a design system

At Integral, we’ve created design systems from scratch for fast-moving startups and helped right the ship for enterprise systems that have slowly drifted out of sync. No matter the size of your org, the problems are familiar. (We cover that in Design Systems 101 — the what, why, and ROI behind it all.)

‍

In this article, we’re diving into the anatomy — the essential parts that make a system effective, usable, and maintainable across teams.

1. Foundation: The Visual Language

‍

Every system starts with the basics — color, type, spacing, iconography, motion. These aren’t just aesthetics. They’re the building blocks of perception.

‍

• Color tokens: Accessible palettes, usage rules, contrast guidance
• Typography scale: Roles for each type size (headlines, body, UI labels)
• Spacing scale: A consistent rhythm (8pt systems are popular for a reason)
• Elevation & shadow: For layers, hierarchy, and interactive clarity
• Motion principles: When and how things animate — and when they shouldn’t

‍

Pro tip: Define the why behind each choice. Naming something “primary blue” is fine. But knowing it’s “Integral Blue” and why it builds trust? That’s system storytelling.

2. Components: The Building Blocks

‍

This is where the system gets real. Buttons, inputs, dropdowns, modals, cards — each defined, documented, and connected to code.

‍

• Variants: States (hover, active, disabled), sizes, icon options
• Usage guidelines: When not to use that component
• Do/Don’t examples: Screenshots go further than words
• Tokens + Props: Tie components back to your foundations and dev values

‍

Your component library should feel like a well-stocked kitchen. Ingredients ready to go, clearly labeled, and designed to play well together.

3. Patterns: UX in Context

‍

Patterns are combinations of components that solve common problems — sign-in flows, error handling, empty states, onboarding, filtering.

‍

They reflect real-world behavior and edge cases. If components are the Lego bricks, patterns are the instructions for making the Millennium Falcon.

‍

• Form patterns: Validation, helper text, success/fail states
• Navigation: Sidebars, top nav, tabbed menus, mobile toggles
• Feedback: Alerts, snackbars, loading states, skeletons
• Data display: Tables, cards, metrics, graphs

‍

Patterns are where UX meets product strategy. They’re built to reflect what your users actually do.

4. Tokens: The Glue Between Design and Code

‍

Design tokens are the shared language between design and development. They’re essentially variables — reusable named values (like color.primary or font.size.body) that define the look and feel of your product.

‍

They allow you to define values once, then apply them consistently across platforms — from Figma to React to CSS variables.

‍

• Color tokens: --color-primary, --color-bg-surface
• Spacing tokens: --space-sm, --space-lg
• Typography tokens: --font-size-body, --line-height-title
• Component-level tokens: --button-radius, --card-padding

‍

Tokens reduce redundancy, enable theming, and make system updates easier to manage. When design and engineering teams use the same set of tokens, you get tighter alignment and faster implementation — no more guessing at pixel values or trying to match hex codes.

“Design token” = variable used to store reusable design decisions (color, spacing, type, etc.)

‍‍
Next-level systems go further:

‍

They sync component libraries between design and development tools — so what’s built in Figma is directly connected to what’s rendered in code.

‍

Tools like Chromatic Storybook, and Figma Dev Mode let teams validate, version, and review components in real time. This makes handoff less “throw it over the wall” and more “build it together.”

5. Documentation: The Source of Truth

‍

If your design system lives only in your head — or worse, just in Figma — it’s not a system.

‍

Good documentation tells people how and why to use what you’ve built. It creates alignment, reduces questions, and encourages adoption.

‍

• Design guidelines: Linked directly from your Figma files
• Code snippets: Copy/pasteable or linked to component libraries
• Live examples: Interactive components in Storybook or similar
• Voice, tone, and brand principles: Design systems aren’t just visuals

‍

Documentation should be a conversation — not a wall of text. Use examples. Keep it updated. And make it easy to find.

6. Standardization: The Hidden Glue

‍

Design systems aren’t just components and spacing tokens — they’re also about how your product speaks, formats, and presents itself at every level.

‍

This often-overlooked layer creates the consistency users feel but can’t always name. When standardized, these micro-decisions build trust. When ignored, they introduce friction and doubt.

‍

Here are a few things to standardize:

• Date formatting: January 12, 2025 vs Mon, Jan 12 vs 12/01/25
• Time units: 12 days vs 12d vs 2 wks
• Phone numbers: (555) 123-4567 vs 555.123.4567
• Casing: Contact us vs Contact Us vs CONTACT US
• Microcopy: Submit or Continue? Okay or OK?
• Punctuation norms: Do you use serial commas? Ellipses in buttons?

‍

Pro tip: A simple standards doc is one of the most-used parts of a system once it exists. Include it in onboarding. Link it often.

7. Governance: Keeping It Alive

‍

Design systems aren’t one-and-done projects. They’re living products.

‍

Governance ensures the system evolves with your product, not against it.

‍

• Contribution model: Who can suggest or add to the system?
• Review process: How are updates proposed, reviewed, and approved?
• Changelog: Track what changed, when, and why
• Adoption metrics: Usage tracking, design-to-dev parity, team feedback

‍

Your governance model doesn’t need to be heavy. But it does need to exist. If no one owns the system, it eventually dies.