How to Build a Design System in Airtable

Design systems are the part of product work that's easy to start and hard to maintain. You build a component library in Figma. You write documentation in Notion. You implement components in code with their own constants for tokens. Three months in, the three are out of sync. The button's hover color in Figma is one shade, in code another, in the docs a third. Someone has to pick which is right, and nobody has the time.

The pattern that actually keeps design systems aligned uses a structured database as the canonical source. Figma syncs from it. Code consumes from it. Documentation is generated from it. Airtable is a good fit for this because the same tables serve every consumer with the right export.

This guide is for design system teams considering or building this approach.

Why Airtable Specifically

A design system has multiple audiences:

• Designers in Figma need tokens and components rendered visually
• Developers in code need the same data as JSON, CSS variables, or framework configs
• Content writers need copy and microcopy in their CMS
• QA testers need the canonical list of states and variants
• Stakeholders need browsable documentation

Each consumer wants the data in a different format. The classic mistakes:

• Figma-only: Designers happy. Developers reimplement everything from screenshots. Drift is constant.
• Notion-only: Documentation exists. Nobody can build from it. Drift is constant.
• GitHub-only: Developers happy. Designers can't get to it. Drift is constant.

A structured database — like Airtable — solves this by being the canonical source that exports cleanly to each consumer's preferred format. Figma syncs via Tokens Studio. Code syncs via Style Dictionary or direct export. Documentation generates from the same tables.

The pattern showed up first in large companies with mature design systems (Shopify, Atlassian, Adobe). It's now spreading to mid-sized teams who want one source of truth without forcing every contributor into Figma.

The Schema

Five tables form the core. Add more as your system grows.

Design Tokens

The foundational layer. Each token is one record with:

• Name (primary, e.g. color-primary-500)
• Category (color, spacing, typography, motion, shadow, radius)
• Value (the actual value, e.g. #3B82F6)
• Type (specific subtype — for color: brand/semantic/system)
• Description (when to use this token)
• Status (Active / Deprecated / Beta)
• Aliases (other names this is referenced by, multi-select)
• Used By (rollup of Components that reference this token)

Tokens organize hierarchically. Primitive tokens (color-blue-500) feed semantic tokens (color-primary-default) feed component tokens (button-primary-background).

For the relational patterns that make this work, see our linked records guide.

Components

The component library. Each component is one record with:

• Name (primary, e.g. Button)
• Type (single-select: atom / molecule / organism)
• Status (Draft / Active / Deprecated)
• Description (what it is, when to use)
• Tokens Used (linked record → Design Tokens, many)
• Variants (linked record → Component Variants table)
• Code Path (where this lives in the codebase)
• Figma Component Key (reference to the Figma component)
• Storybook URL (link to the Storybook page)
• Documentation (long text — guidelines, do's and don'ts)
• Image (attachment — preview)
• Last Reviewed (date)
• Owner (collaborator)

A separate Component Variants table holds variant-level data: size, state, default-ness — anything that varies within one component.

Patterns

Combinations of components for common UI scenarios. Each pattern is one record with:

• Name (e.g. Empty State, Form with Validation, Confirmation Dialog)
• Components Used (linked → Components)
• Description (when to use this pattern)
• Image (attachment)
• Code Example (long text)

UI Copy

Strings used across the product. Each copy item is one record with:

• Key (primary, e.g. button.submit.label)
• Value (the actual copy)
• Context (where this appears)
• Tone (single-select: helpful, professional, casual, urgent)
• Status (Draft / Active / Deprecated)
• Localizations (linked → Localization table if multi-language)

Documentation

Long-form principles, guidelines, governance. Each doc record:

• Title (primary)
• Section (single-select: Principles, Patterns, Accessibility, Governance)
• Content (long text in markdown)
• Last Updated (date)
• Owner (collaborator)

The same record can be rendered in a Notion-style internal doc, exported to a public docs site, or surfaced inside an Airtable interface.

Syncing to Figma via Tokens Studio

Tokens Studio is the Figma plugin that consumes design token JSON and applies it as Figma Variables. This is the bridge.

The workflow:

1. Tokens live in Airtable as records on the Design Tokens table.
2. A Make scenario exports them as a Tokens Studio JSON file. Run on schedule (daily) or on-change.
3. The JSON file lives in a sync location — a GitHub repository, a Tokens Studio sync, or a public URL.
4. In Figma, Tokens Studio reads the JSON and applies tokens as Figma Variables. Designers reference the variables in their work.

When a token value changes in Airtable, the next sync updates the JSON, and Figma re-syncs the next time Tokens Studio is refreshed. Designers see the new value immediately.

The Make scenario shape:

1. Trigger: Schedule (e.g., daily at 6am) or Watch Records on the Design Tokens table.
2. Search Records to pull all active tokens.
3. Iterator over tokens.
4. Aggregator that builds the Tokens Studio JSON structure.
5. GitHub Create File (or Cloud Storage write, or HTTP POST to a sync URL) to publish the JSON.

For Make patterns, see our Make automation guide.

Syncing to Code

The same pattern for code consumers. Tokens get exported as one or more of:

• Style Dictionary input for teams using that tool
• CSS variables for direct consumption
• Tailwind CSS config for Tailwind-based projects
• JavaScript constants for component library use
• Platform-specific formats (iOS .json, Android XML)

A second Make scenario (or branches of the same one) produces the right format for each consumer. The exported file lives in your code repository — typically auto-committed via a GitHub Action triggered by a webhook from Make.

Developers consume the exported tokens. They don't edit Airtable directly. The cycle stays clean.

The Airtable Interface for Browsing

The structured data is great for sync, but humans want a browsable view. Build an Interface Designer on top with:

• Tokens page: filterable list of all tokens grouped by category, with values visible
• Components page: Gallery view of all components with previews, drilling into detail
• Patterns page: browseable list of common patterns with images
• Copy page: searchable UI strings
• Documentation page: rendered long-form documentation

This becomes the internal browseable design system site, accessible to designers, developers, and stakeholders alike — all backed by the same data that feeds Figma and code.

For external-facing documentation (public design system site), the same data can feed a Softr portal, a custom Next.js site, or a Notion database — all via the same export pattern.

Workflow Integration

A typical design system change flows like this:

1. A token or component change is proposed — e.g., a new shade of brand color
2. A team member adds or edits the record in Airtable
3. The change goes through review — Status moves from Draft to Active when approved
4. The next sync (manual or scheduled) pushes the change to Figma via Tokens Studio
5. The next code sync pushes the change to the repository
6. A release notes record is created in the Documentation table summarizing the change
7. A Slack notification to the design and engineering channels announces the change

Every consumer gets the update through the same source. No retyping. No drift.

AI Augmentation Opportunities

Airtable's AI features and Make's AI modules add useful augmentation:

• Component description generation — use AI to draft documentation copy for new components based on the component name and properties
• Accessibility check — AI evaluation of color tokens against WCAG contrast requirements
• Pattern suggestion — given a new screen, suggest which existing patterns apply
• Copy variants — generate alternative phrasings for UI copy in different tones
• Migration help — when deprecating a token, AI scans the codebase via API and suggests replacements

These are real now. The cost is incremental and the time savings on routine design system maintenance work add up.

When This Approach Is Overkill

Three signals that you don't need this:

1. Your design system has fewer than 20 components. Maintaining them in Figma is fine. The Airtable overhead doesn't pay back at this scale.

2. Your team is 1-3 designers and 1-3 developers. You don't need centralized governance. Drift can be fixed by a quick conversation.

3. You don't have a real code component library yet. If your developers reimplement everything from screenshots, the Airtable-as-source pattern doesn't help — there's no second consumer to sync to.

The pattern shines when you have:

• 50+ components and growing
• Multiple platforms (web, iOS, Android) consuming the system
• A real design systems team with governance responsibilities
• Established Figma usage AND established code component library
• Existing pain from drift between sources

For teams below that threshold, Figma-as-source is fine.

Tools That Support This Pattern

• Airtable as the source database (this guide)
• Tokens Studio for Figma sync
• Style Dictionary for code token export
• GitHub Actions or Make for sync automation
• Storybook for component documentation in code
• Supernova or Knapsack as alternative design-system-platform tools (some explicitly support Airtable as input)

The combination you pick depends on your existing stack and the scale of your system. Start simple — Airtable + Tokens Studio + a Make scenario — and add more as the system grows.

Where to Go Next

For the relational patterns underneath the schema, our linked records guide is the foundation. For the Make scenarios that drive the sync to Figma and code, the Make automation guide covers the iterators and aggregators you'll need.

For the official Tokens Studio documentation on sync sources, tokens.studio is the canonical reference.