AI-Enabled Design Systems

My Role

As Design Ops & Systems Consultant, I developed a future-state operating model for moving from a dual-library design system toward a code-first, AI-assisted system.

​

My work focused on:

• Identifying duplication and synchronization bottlenecks

• Defining the production system as the canonical source

• Structuring components and documentation for AI consumption

• Exploring AI-assisted UI generation

• Repositioning Figma as an optional design and review surface

• Embedding automated QA and accessibility validation

• Redefining the roles of design-system designers and engineers

• Simplifying how product teams consume the system

The Approach

1. Make the production system canonical

The codebase and Storybook became the source of truth for components, tokens, states, rules, accessibility requirements, documentation, and tests.

Instead of maintaining the same system twice in Figma and code, the organization would maintain it once and generate the representations teams need from that source.

​

2. Make the system machine-readable

Component APIs, usage guidance, interaction rules, accessibility requirements, and tests were structured so AI could understand not just what components looked like, but how and when they should be used.

This created a shared system context for both people and AI.

​

3. Migrate incrementally

The transition begins with a small set of mature components rather than replacing the existing workflow at once. The team first strengthens the production library and documentation, then pilots AI-assisted generation against real components, validates the results against the existing Figma workflow, and introduces automated accessibility, interaction, and regression testing. Only after the new workflow proves reliable does Figma move from authoritative component library to an optional surface for exploration and review.

4. Generate from product intent

The workflow shifted from:

Design → Figma → handoff → code → QA

to:

Product intent → AI + system context → working UI + production code → automated validation → human review

​

Figma remained available for exploration and critique, but no longer needed to be the authoritative component library.

5. Automate quality checks

Generated work was validated against:

• approved components and tokens

• supported states and APIs

• interaction and responsive behavior

• accessibility requirements

• automated tests and regression checks

Designers and engineers still made the important judgment calls. AI handled more of the repetitive translation, checking, and synchronization work.

Impact

The new model changed how the team spent its time.

​

• Designers spent less time manually building and maintaining prototypes and could generate working, system-compliant experiences directly in code.

• More design time could shift toward usability testing and iteration, using prototypes with realistic interactions, states, and data rather than simplified representations.

• Engineers spent less time translating static design specifications and more time improving architecture, APIs, and system capabilities.

• QA moved earlier in the workflow, allowing accessibility, component usage, and interaction issues to surface before final review.

• The design-system team spent less time policing parity between tools and more time improving the system itself.

The larger operational shift was from producing and synchronizing artifacts toward testing ideas, improving the system, and validating experience quality earlier.

Lessons Learned

The most important realization was that the core problem was not handoff quality—it was duplication. Maintaining both a Figma library and a production component library meant every meaningful change had to be recreated, reviewed, documented, and synchronized twice. Making the production system canonical removed much of that duplicate work and reduced the need for constant parity checks between tools.

​

Operationally, the workflow changed from designers creating detailed Figma prototypes, engineers translating those designs into code, and QA checking for drift, to teams working from the same production components, rules, tests, and accessibility requirements from the start. Designers could spend less time assembling and maintaining prototypes and more time testing realistic, interactive experiences with users. Engineers spent less time interpreting specifications and more time on architecture, APIs, performance, and system guardrails.

​

The design-system team also changed its focus. Instead of spending so much time updating parallel libraries, chasing documentation changes, and reconciling inconsistencies, the team could concentrate on governing component behavior, system rules, accessibility standards, quality gates, and the structure of the machine-readable context that AI relied on. The operational shift was from maintaining artifacts across tools to managing the system that generates, validates, and governs those artifacts.