From Figma to Flutter: Designing a System That Scales Across 30 Apps

We've shipped 30+ Flutter apps at Xenotix Labs across D2C commerce, real-time sports, edtech, healthtech, legaltech, marketplaces, and more. Each project starts the same way: Figma file, design system, component library, then code.

The non-obvious insight from doing this 30 times: the Figma design system and the Flutter component library should be the same artifact, conceptually. Tokens, components, layouts, type ramps — designed once, expressed in both Figma and Dart, kept in sync mechanically. When they drift, your designers and engineers stop trusting each other, and "Figma to production" becomes a punch line.

Here's the workflow we've converged on.

The single source of truth: design tokens

Design tokens are the atomic units. Colors, type sizes, spacing, radii, elevations, motion durations. We define them once in a JSON-like format and generate both the Figma library and the Flutter ThemeData from that single file.

{
  "color": {
    "primary": { "value": "#3F51FF" },
    "surface": { "value": "#FFFFFF" },
    ...
  },
  "space": {
    "xs": { "value": 4 },
    "sm": { "value": 8 },
    ...
  },
  "radius": {
    "card": { "value": 12 },
    ...
  }
}

A build script generates a Flutter tokens.dart file with strongly-typed constants. Designers import the same JSON into Figma via the Tokens Studio plugin. When a designer adjusts color.primary, both Figma and the Flutter app pick up the change automatically.

With this in place, there is no gap between "the design says" and "the app implements". They can't disagree. They share a parent.

The component library

On top of tokens sit components. Buttons, inputs, cards, list items, modals, tab bars, snackbars. We build each component twice: once as a Figma component with variants and properties, once as a Flutter widget with named parameters that mirror those properties.

The Flutter widget always uses tokens, never raw values. padding: EdgeInsets.all(tokens.space.sm), never padding: EdgeInsets.all(8).

The layout primitives

Most projects re-implement the same layouts in slightly different ways: a screen with an app bar, a body, a primary action at the bottom. A modal sheet with a title, body, and dismiss button. A list page with a search bar and infinite scroll.

We pre-built these as Scaffold-style layout widgets in our internal package:

• XScaffold(title, body, primaryAction)
• XBottomSheet(title, body, dismissAction, confirmAction)
• XListPage(searchBar, items, onLoadMore, emptyState)

New projects start at the layout level, not the widget level. A login screen is two widgets, not twenty.

The package structure

One shared package, multiple apps:

xenotix_design/
  lib/
    tokens/         (generated from JSON)
    components/     (XButton, XCard, XInput, ...)
    layouts/        (XScaffold, XListPage, ...)
    icons/          (custom icons + lucide passthroughs)
  test/
  pubspec.yaml

Every app pulls xenotix_design as a path or git dependency. Updates to the package propagate to every app on next pubspec update.

We version the package strictly. Breaking changes go in major versions. Minor versions add components or non-breaking improvements. Apps pin to a major version and update minor versions on their own cadence.

The handoff workflow

Figma to Flutter handoff is the friction point on most teams. Ours:

1. Designer designs in Figma using the shared library (built on shared tokens)
2. Designer publishes a Figma frame with notes (interaction states, copy, edge cases)
3. Engineer opens the frame, identifies which existing components are used, and which new ones are needed
4. If a new component is needed, designer + engineer co-design it in the shared library first, then both the Figma and Flutter implementations are updated
5. Engineer implements the screen by composing existing components

No handoff document. No "can you make this padding 14 instead of 16?" because padding is a token, and tokens are shared.

The design system as a Storybook

We maintain a Flutter implementation of the design system as a runnable Storybook app: every component, every variant, every state, on a single navigable surface. Designers can scroll through it on a phone. Engineers can show "yes, this exact button in this exact state already exists, here's how to use it."

Storybook also doubles as the regression-test surface. Visual snapshot tests on every component, run on every PR.

What we'd tell a team starting their first Flutter design system

• Tokens first, components second. A component built without tokens is a tax you'll pay later.
• One package, not three. Don't split tokens, components, and layouts into separate packages until you have a real reason. Premature splitting creates dependency-graph pain.
• Storybook from week one. It's the fastest way to catch component drift.
• Visual diff tests in CI. Catches "the button is 1 px taller in this PR" before a designer notices.
• Don't customize per app. Resist the urge to fork the design system per project. Push customization through tokens (color overrides, spacing adjustments) rather than forking widgets.

Stack summary

• Tokens: JSON, generated to Dart and synced to Figma via Tokens Studio
• Component library: custom Flutter package
• Layouts: custom Flutter package
• Storybook: runnable Flutter app per package
• Distribution: internal git monorepo, pinned versions per app
• Tests: flutter_test + alchemist or golden_toolkit for visual snapshots

Building a multi-app product family?

One design system across many apps is the difference between a coherent brand and 30 disconnected products. If you're scaling across multiple apps and need them to feel like one product, Xenotix Labs has the playbook. Reach out at https://xenotixlabs.com.