Design System — Origin Story

Every interface, by system.

The story behind FORMA — from a simple need for consistency to a fully audited design system.

FORMA didn't start as a design system.

It started as a simple need for consistency.

Story

Act 01 — Origin

At first, it was only a grayscale palette — a neutral foundation used to keep wireframes, agnostic components, and exploratory layouts visually aligned across every Figma project. No branding. No complexity. Just clarity.

Consistency has a way of exposing everything else.
Act 02 — Evolution

Soon, the gaps became obvious: titles behaved differently from page to page, separators lacked structure, spacing rules changed between documents, and layouts slowly drifted away from one another. What began as a color reference evolved into a growing collection of reusable decisions.

So the library expanded. Shared typography rules, spacing values, paddings, margins, and structural primitives were added directly into the external Figma library connected across every project. Over time, those values became increasingly difficult to manage manually, which led to the next logical step: tokenization.

Act 03 — Intelligence

Then AI entered the workflow. By connecting Figma to Claude through MCP integrations, FORMA evolved beyond a static library into an actively audited ecosystem. Automated reviews, correction plugins, and design audits began surfacing inconsistencies and opportunities that would have otherwise gone unnoticed.

Milestone — The living system

Figma connected to Claude via MCP. Every iteration automatically audited, corrected, and refined. The moment FORMA stopped being a static library and became a living, self-improving system.

Act 04 — Culmination

The more the system improved, the more it demanded its own environment. What started as tokens inside Figma eventually became a fully documented platform — generated, connected, and expanded through code. One layer led to another until the library became something larger than its original purpose.

That system became FORMA.

From design tokens to shipped components,
FORMA is the foundation every interface is built on.

Overview

FORMA operates on a three-layer token architecture — primitives, semantic, and component — that fully decouples raw color values from their application in UI. The 274 design tokens cover 100% of the 7 color families built in OKLCH (neutral, blue, red, green, yellow, orange, purple), guaranteeing perceptually uniform lightness curves between steps. No component consumes raw values directly: every color decision routes through a semantic token that expresses intent, not a hex code.

All tokens follow the canonical color/category/role/state path convention — zero compatibility aliases, zero naming ambiguity. The system passes WCAG AA across all text contexts, with contrast ratios documented per color family and surface combination. Motion is handled exclusively through compositor-layer properties (transform, opacity), avoiding layout recalculation on every frame. The result is a system that scores 100/100 across all four audit dimensions: token architecture, color coverage, token scoping, and naming convention.

Key Metrics

0
Total Tokens
Across 3 collections: base primitives, semantic aliases, and spacing scale.
7
Color Families
Neutral · Blue · Red · Green · Yellow · Orange · Purple — all built in OKLCH.
100%
WCAG AA Pass Rate
All text tokens verified against both light (#F5F8FC) and dark (#090D10) surfaces.
0
Resolved Issues
All 22 audit findings addressed — from token scoping to contrast violations.

Three Pillars

Pillar 01
Token Architecture
A strict three-tier hierarchy separates what a color is from what it means and where it appears. Primitives hold raw values. Semantic tokens express role and state. Components consume only semantic tokens — never primitives directly.
  • Primitives: 70 base color values across 7 families
  • Semantic: 130+ role-and-state aliases
  • Spacing: 13-step scale with Figma→CSS bridge
  • Motion: 3 durations · 3 easing curves
Pillar 02
Naming Convention
Every token follows the canonical color/category/role/state path convention, matching the Figma variable structure 1:1. There are no compatibility aliases, no shorthand names, and no legacy bridges — the CSS variable name is the Figma path.
  • 0 compatibility aliases (removed in v1.0)
  • 100% path convention compliance
  • Figma variable → CSS token: direct mapping
  • BEM modifier pattern on all components
Pillar 03
Accessibility
WCAG AA is a hard constraint, not a checklist item. Every semantic text token has a documented contrast ratio. The system maintains separate token paths for dark-surface interactive color (blue-400) and light-surface interactive text (blue-600), preventing the single-token anti-pattern.
  • 4 P0 contrast violations resolved at root level
  • All touch targets ≥ 44px
  • Focus visible on every interactive element
  • prefers-reduced-motion respected system-wide