Build
Build new systems from scratch in 3 simple steps(Colours, Typography, and Components)
Anchor: Turning design systems into governed infrastructure
A Figma plugin designed to reduce design drift, speed up system adoption, and cut developer rework by making tokens, styles, and components enforceable.
“Design systems fail less from creation and more from drift.”
Overview
Turning design systems into governed infrastructure
The real friction showed up after a system was created: unbound colors, inconsistent spacing, unstyled text, broken component relationships, messy legacy files, and repeated cleanup between design and development. Anchor was designed to move that cleanup upstream by making tokens, styles, and components governable inside Figma.
“The real problem was not setup. It was preserving consistency at scale.”
Registry
An approved source of truth for tokens, styles, components, and policy.
Audit
A way to detect design drift inside real files before handoff turns into engineering cleanup.
Adoption
A way to absorb existing systems, not just generate new ones from scratch.
Problem
Most system work still breaks at the handoff layer
Teams usually have some design system assets, but the actual file state drifts over time. Tokens stop being bound, components detach, styles become manual, and legacy systems become harder to adopt than rebuild. That is where developer rework begins: visual mismatch, CSS cleanup, token translation, and manual alignment between design and code.
Drift
Tokens and styles stop behaving like system primitives.
Rework
Developers normalize what should have been enforced upstream.
Adoption gap
Existing systems are often too messy to trust and too expensive to rebuild.
◔
01 // OPTIMAL STATE
System Created
↓
△
02 // DEVIATION DETECTED
Drift
↓
⌁
03 // INTERVENTION REQ
Rework
↓
◷
04 // PROCESS BLOCKED
Delay
Vision
A design system should act like an operating model, not a static library
Anchor was shaped around three layers: generate a clean starting system, publish an approved registry, and audit files against that registry. That changes the role of the plugin from “design helper” to “design governance infrastructure.”
Product idea
Generator, registry, audit, enforcement, and adoption are treated as connected layers rather than disconnected utilities. The operating model is what makes the plugin durable.
Solution
The interface came after the operating model
Anchor was sequenced to become useful before it became intelligent.
I built the system in stages so each layer could support the next one. The result is a plugin that can generate systems, publish a registry, audit files, adopt existing systems, bind tokens into real files, and help users fix violations inside Figma.
A. Build
Generate colors, typography, foundations, and component foundations inside Figma.
B. Registry
Publish an active version of truth with policy, version history, adoption drafts, and file bindings.
C. Audit
Scan live files for color, text, spacing, and component integrity issues.
D. Enforce
Fix warnings at group level or item level, resolve them, reopen them, or accept exceptions intentionally.
Build
Registry
Audit
Enforce
Decisions
The work was shaped by a few structural choices
I avoided designing Anchor as a generic AI generator. Instead, I used a governance-first structure where every new capability had to strengthen trust, not bypass it.
Registry before AI
I chose to build approval, audit, and enforcement first so future AI outputs could be governed.
Draft before publish
Adopted systems and inferred legacy artifacts become drafts first, not truth.
Design-native first
The plugin works where system drift actually happens: inside Figma files.
Adoption
Anchor was designed to work with existing systems, not only new ones
A major constraint in real teams is that systems already exist in different states of quality. Anchor can ingest structured file data, discover visual legacy artifacts, create a draft registry, and let users review what was found, inferred, missing, or unsupported before publishing a new active version.
Structured found
Variables, styles, and components already present in file.
Visual inferred
Legacy palettes, specimen boards, and reusable groups turned into reviewable draft candidates.
Review gate
Accept, keep raw, skip, or normalize before publish.
AI Strategy
AI comes after trust, not before it
I intentionally did not start with AI generation. The plugin was first built as a functioning system: generation, registry, audit, enforcement, adoption, and file binding. That gives AI something stable to work inside. Without that foundation, AI would only generate more variation, more drift, and more downstream cleanup.
What AI will do next
The AI layer is planned to help users generate cleaner and more effective design systems, not just more screens. It will support better token structure, stronger role assignment, cleaner typography systems, and faster system setup while keeping everything inside a governed registry.
Reduce developer cleanup
AI can generate better starting systems so fewer mismatches reach code.
Lower repetitive work
Users spend less time manually naming, grouping, and structuring primitives.
Stay within constraints
AI should operate inside registry rules, not outside them.
Impact
The real AI value is not prettier output. It is less normalization work later.
The planned AI layer is useful because it reduces repetitive setup and post-design cleanup. Instead of only generating layouts, it will help create cleaner token structures, better semantic grouping, stronger typography systems, and more consistent component foundations. That means less token translation, less CSS rework, fewer manual overrides, and fewer handoff corrections for developers.
Less token mismatch
Cleaner generated systems reduce manual mapping between design and code.
Less visual cleanup
Registry-backed fixes catch drift before engineering absorbs it.
Faster adoption
Existing systems become governable without rebuilding everything from zero.
Current state
Anchor is already useful without the AI layer
Today the product can generate a system, publish an active registry, audit files, fix many violations, adopt structured and legacy systems, create file tokens, and support reviewable versioned updates. That matters because it proves the core operating model before the intelligence layer is added.
Reflection
The strongest systems are shaped as operating models first
This project reinforced a clear lesson: intelligence is more valuable when it sits on top of a stable structure. Anchor is being shaped so AI becomes a force multiplier for system quality, not a shortcut around governance.
What I would take further
AI-assisted system generation, stronger semantic token mapping, more reliable component integrity automation, and deeper design-to-code bridge layers.
Positioning
Where Anchor sits
Most adjacent tools optimize for one of three things: generating interfaces faster, transporting tokens across systems, or documenting components in code. Anchor is being shaped around a different problem: keeping design systems governable inside real Figma files.
That is why I built it as a governance-first product with a registry, audit, enforcement, and adoption workflow before adding AI generation. Internally, I framed the difference as Generator vs Governor: tools like Figr focus on creation velocity, while Anchor focuses on system integrity, deterministic enforcement, and reducing design debt before it reaches engineering.
The long-term moat is the Headless Token Registry and the bridge between Figma truth and production truth, not just another prompt-to-UI workflow.
Anchor is not being built as a faster way to draw screens. It is being built as a design-native governance layer: generate when needed, adopt what already exists, publish approved truth, audit real files, and reduce downstream developer cleanup. That positioning is deliberate because generated output alone is easy to copy, while registry-backed enforcement is much harder to replace.
Why this matters
Speed tools help teams create more. Governance tools help teams keep systems usable. In practice, the second problem is where design debt becomes engineering rework.
Want more? Explore other case studies!
MEConnects: B2B SaaS Procurement Platform
Explore Case Study