Architecting an AI-ready Design System for Complex Creative Tools

Overview

• I created an internal proof-of-concept for a design system that treats design intent as a contract, not a loose handoff from Figma to code.
• The work connects Figma variables, generated tokens, canonical HTML/CSS components, React references, native platform theme layers, documentation, and automated parity tests.
• The system was built for Avid's reality: dense creative tools, multiple product stacks, long-lived desktop applications, and teams that need to modernize without pretending everything is a greenfield React app.
• It is also explicitly AI-ready, with contribution rules and assembly patterns that help agents generate UI within the system instead of inventing one-off interfaces.

This case study builds on the broader design transformation work I have been leading at Avid. Through cross-product conversations, alignment workshops, and shared-library work with designers and design stakeholders across the organization, we had already started to define the foundations of a more coherent product design practice. This POC became the technical expression of that alignment: what would a modern Avid design system look like if it lived in Figma, code, documentation, tests, and AI workflows from the beginning?

The result was a working POC that demonstrates the operating model, architecture, and governance patterns for a contract-first design system. It is not positioned as a finished production library. The point was to prove the shape of the system and make the investment conversation tangible.

My Role

I led the concept, architecture, and implementation of the POC. That included the token model, component structure, documentation strategy, parity tests, platform output strategy, and the AI contribution rules that tell agents how to work inside the system.

My role was part designer, part systems architect, and part translator. I needed the work to be legible to design leaders, credible to engineering stakeholders, and useful enough that product teams could see how it would fit their actual constraints. We did this without dedicated full-time design system engineering support, so much of the implementation was developed agentically and then shaped for engineering review.

Problem

Avid products are not simple web apps. They are dense, professional tools for media creation, with years of product history and multiple implementation stacks across desktop, web, and native-adjacent environments. A design system that only solves for a Figma library, or only solves for a React package, would miss the harder part of the problem.

The starting point was real design drift. Before the transformation work, designers could not reliably say how many shades of gray existed inside a single application because values had accumulated over time through isolated product decisions. Aligning on a definitive set of shared foundations—color, spacing, typography, radius, elevation, and semantic roles—gave us something stable to build from.

The harder part is trust. If a button looks right in Figma but is rebuilt differently in code, the system drifts. If tokens are named semantically in design but hardcoded in product code, the contract breaks. If an AI agent can generate a polished mockup while bypassing tokens, states, density rules, or accessibility expectations, the system becomes faster at producing inconsistency.

I treated the POC as a governance problem as much as a component problem. The core question was: how do we make design intent durable across tools, platforms, and contributors?

Architecture

The architecture is intentionally layered. Each layer has a job, and the handoff between layers is explicit:

• Figma captures design intent through component properties, semantic variables, and documented decisions.
• Primitive tokens hold raw values for color, spacing, radius, type, icon sizes, elevation, and other foundations.
• Semantic tokens express intent: background roles, content roles, control states, input states, status tiers, light/dark modes, and density-aware decisions.
• Component-scoped tokens turn those semantics into stable implementation APIs such as button fill, border, text, focus, and disabled values.
• HTML/CSS acts as the canonical visual and semantic contract for primitives, independent of any one JavaScript framework.
• React serves as the reference implementation for interaction behavior, Storybook validation, assemblies, and Code Connect mapping.
• Platform outputs extend the same token decisions into SwiftUI, JUCE, and Qt/QML theme layers.

One deliberate choice was making HTML/CSS the canonical visual contract. React is important, but it is not the whole product universe. Starting with a framework-agnostic contract makes it easier to reason about parity, documentation, AI-generated prototypes, and downstream implementations without tying the entire system to one stack.

Governance Through Contracts

The POC uses tests and registries as design-system governance, not just engineering hygiene. A single component registry documents what exists, where the React and HTML/CSS implementations live, which examples and docs cover them, and what native platform hooks are expected.

That registry drives automated checks for the kinds of drift design systems often discover too late:

• Framework parity: shared components cannot quietly exist in React without the corresponding HTML/CSS contract.
• Token parity: implementations need to reference the same semantic token set instead of drifting into local values.
• Size contracts: component heights and modifier combinations are tested against documented expectations, avoiding ambiguous size labels.
• Figma traceability: semantic tokens preserve links back to variable IDs so the design-to-code relationship can be audited.
• Accessibility coverage: semantic color pairs are checked against contrast expectations.
• Platform token references: SwiftUI, JUCE, and Qt theme files can only reference tokens that exist in generated outputs.
• LLM documentation coverage: agent-facing documentation is tested so contribution rules do not fall out of sync with the system.

This is the part of the work I care about most. Components create reuse, but contracts create trust. Without the contract layer, a design system can look mature in screenshots while quietly becoming expensive to maintain.

Button: {
  react: "components/Button.tsx",
  html: "css/components/button.css",
  examples: "examples.html#button",
  figmaNodeId: "...",
  native: {
    swift: "AvidButtonStyle",
    juce: "AvidButton",
    qt: "Avid.Button"
  }
}

PASS frameworkParity.test.ts
PASS tokenParity.test.ts
PASS componentSizes.test.ts
PASS wcagContrast.test.ts
PASS figmaVariableIds.test.ts
PASS platformTokenRefs.test.ts
PASS llmsTxt.test.ts

AI Readiness

I did not want to frame AI readiness as "let the model generate some components." That is not enough, and in a design system context it can be actively dangerous. The useful version is AI-first delivery with contractual guardrails.

The POC includes agent instructions for how to work with Figma context, how to interpret variables, how to update token files, how to avoid invented variants, how to map components through Code Connect, and how to keep docs, Storybook, tests, and platform outputs aligned when a component changes.

I also defined assembly-level rules for product workflows: density modes, panel anatomy, settings panels, data tables, NLE/DAW workspaces, floating windows, empty states, and gap protocols for anything the system does not cover yet. That gives AI-generated prototypes a product grammar. The goal is not generic UI generation; it is system-aware prototyping that still feels like Avid.

Platform Reach

The multi-platform story is intentionally pragmatic. Generated token artifacts provide a shared base for CSS, SCSS, JSON, TypeScript, Swift, JUCE, and Qt/QML. Then hand-maintained theme layers translate those tokens into each platform's idioms.

That distinction matters. I am not claiming every component is fully shipped across every stack. The POC shows how the system can support multiple platforms without pretending there is one universal implementation model. Some components have native mappings; some are web-first; some are intentionally out of scope. The value is that the coverage is documented instead of implied.

For a company with products like Pro Tools, Media Composer, Sibelius, and web-based experiences, that honesty is important. A credible design system has to meet the product ecosystem where it is, then create a path toward coherence.

AvidTheme.controlFillPrimary
AvidTheme.controlTextPrimary
AvidButtonStyle()

import Avid

Button {
  palette.button: AvidTokens.controlFill
}

What Changed

This work mattered because it changed the internal posture around design systems at Avid. Before the POC, a shared design system was easy to discuss as a theoretical pipe dream. The working system made it concrete enough to evaluate, critique, and socialize with product leadership.

It also reframed the design system as a product design deliverable, not just an engineering library. The product design team could point to working documentation, token outputs, component examples, governance tests, and AI contribution rules as a coherent product surface. That helped move the conversation from whether a system was valuable to what it would take to mature and operationalize it.

The impact showed up before the full documentation story was complete. We heard from engineering partners that the color token work alone saved teams weeks of effort by giving them a clearer, shared foundation instead of forcing every product team to recreate decisions locally. For me, that was an important signal: even an early POC can create real leverage when it turns design intent into usable infrastructure.

Maturity and Proof Points

This is an early-stage proof of concept, and I would describe it that way in any interview. The strongest story is not "this is done." The strongest story is that the POC demonstrates the architecture, operating model, and quality bar needed for a production design system investment.

The system is strongest where the documentation, tests, and implementation artifacts reinforce each other:

• Architecture: the layered model connects Figma, primitive tokens, semantic tokens, component tokens, and implementation.
• Component registry: one source of truth tracks component files, examples, Figma references, and native platform hooks.
• Contract tests: framework parity, token parity, size contracts, WCAG contrast, Figma variable IDs, platform token references, and LLM documentation coverage are enforced automatically.
• Component status: shipped, pending-review, and planned work is documented honestly instead of over-presented as complete.
• Platform outputs: generated Swift, JUCE, and Qt token files are paired with theme layers that translate tokens into platform conventions.
• Assembly guidance: dense workspace patterns, panel anatomy, and domain-specific examples support DAW/NLE-style product surfaces.

There is still real work ahead: density needs final alignment, motion and layering contracts need to mature, some semantic status tokens need complete Figma traceability, and production hardening belongs in downstream product repos. I see those as healthy roadmap items, not weaknesses. They make the maturity model clear.

Reflection

This work helped me clarify what kind of design systems leader I want to be. I am interested in systems that are useful under real product pressure: legacy constraints, multiple platforms, uneven resourcing, design debt, accessibility expectations, and now AI-assisted contribution.

The POC gave Avid a concrete model for how a modern design system could operate: not as a static library, but as a governed pipeline from design intent to implementation. It also gave me a stronger way to talk with engineering leaders about design quality, because the conversation could move from taste to contracts, tests, and operating models.

My biggest takeaway is simple: a design system should make trust easier to maintain. If the system can help a designer, an engineer, and an AI agent all arrive at the same intent through different tools, it is doing more than organizing components. It is creating shared product infrastructure.