Keeping Figma and code in sync

The Granicus Design System (GDS) is built on a simple promise: what designers see in Figma is what developers build in React.

When component names, prop names, or token scales diverge between design and code, friction grows. Designers create specs that developers have to translate, and small UI inconsistencies creep into production.

What designers see in Figma is what developers build in React.

GDS eliminates this translation step by maintaining a 1:1 structure between the GDS SPECS Figma file and @granicus/gds-core.

The 1:1 Mapping Rule

Every component set in Figma maps directly to a exported Gds* component in React:

Token Alignment

Tokens form the bridge between design primitives and theme variables:

1. Color Tokens: Brand primaries, neutral surfaces, text tones, and semantic feedback colors map directly to GDS theme tokens.
2. Typography Tokens: Font families, font sizes, line heights, and letter spacings are defined once and compiled into theme typography variants.
3. Spacing Tokens: The strict 8 px grid scale (1 = 8px, 2 = 16px, 3 = 24px) is mirrored in Figma auto-layout gaps and React GdsStack / GdsGrid spacing props.

Workflow for New Components

When a new component or variant is needed:

1. Design First: The design team creates component variants and interactive states in the GDS SPECS Figma kit.
2. Review: Design and engineering align on component names, variants, and prop naming conventions.
3. Code Implementation: Engineering wraps the underlying Material UI primitive with GDS tokens in @granicus/gds-core.
4. Documentation: Live interactive examples and code snippets are published to the GDS documentation site.