Evolving DesignOps with AI

The problem

This self-initiated work began as a personal hackathon project to address a pain point I and many other designers repeatedly experienced: existing Figma files mixed outdated components, multiple libraries and inconsistent file structure. I did not solve all of that at once. I started with one component-level task, then expanded the scope as each stage showed me what the next tool needed to understand.

Four stages, one learning loop

The scope grew from a component, to multiple libraries, to a whole file, and finally to any input that could be used to generate a new file.

1. SFE Adoption Assistant (Figma plugin)

Scope: Component · Core shift: Automate the swap

I built the Security Fluent Extension (SFE) Adoption Assistant, a Figma plugin that analyses selected elements, matches non-SFE components to SFE components and lets the designer approve replacements.

What I learned: matching against one library was not enough. Product files used components from multiple libraries, so the next tool needed to understand which design system each component belonged to.

Before analysis Start from the designer’s selection The scope stays visible and deliberate: select an element, then ask the plugin to inspect its component usage.

Match Compare before replacing The plugin shows the proposed SFE component and the attributes used to match it.

After replacement Verify the result, not just the action A second scan confirms that all three buttons resolve to real SFE instances and no replaceable elements remain.

2. Design System Calibrator (Figma plugin)

Scope: Multi-library · Core shift: Understand which system a thing belongs to

I expanded the plugin around a configurable component registry. It compares instances with a selected baseline library, separates baseline and non-baseline components, and shows which items have a replacement.

What I learned: using the right components did not make the file structure right. The next tool needed to work at the whole-file level instead of swapping individual instances.

1 · Set baseline Choose the design system The designer chooses which available library defines the baseline.

2 · Select scope Analyse the chosen elements The plugin keeps the baseline visible while the designer chooses what to inspect.

3 · Review Classify and select matches Baseline, non-baseline, local and orphaned instances stay separate before swapping.

4 · Complete Report and undo changes The final state reports successful swaps and keeps undo and rescan available.

3. Intune Figma Rebuild (Figma plugin)

Scope: Whole file · Core shift: Rebuild structure, not just contents

I moved from component replacement to whole-file reconstruction. The plugin inspects file structure against explicit rules, reports whether it is parseable, and ranks the structural problems that need to be addressed in the rebuild.

It also introduced a tiered search order for multiple libraries. The tool starts with Intune’s recommended components and Intune UI Toolkit, then checks SFE, Security Data Visualization, Fluent 2 Web and Azure Fluent Extension Icons. A lower tier is used only when a higher tier does not provide the needed component.

1 · Inspect Start with the selected frame Inspection is read-only and evaluates the selection before rebuilding.

2 · Review Read the complete inspection One merged capture shows the verdict, all seven checks and the ranked fixes from the same scrollable screen.

3 · Configure Choose the rebuild pattern The designer selects the target page pattern and can add contextual hints.

4 · Register Extract component keys Registered keys connect rebuilt elements back to known library components.

What I learned: rebuilding still depended on having a usable Figma source. Sometimes the available input was a legacy file or only a screenshot. The next tool needed to generate a new file from either.

4. AI-Ready Figma (AI agent)

Scope: Any input → new file · Core shift: Generate, not remediate

I moved the workflow from a Figma plugin to an agent. Given a Figma file or screenshot, the agent generates a new file using library components, variables, tokens, auto layout and semantic naming. It carries forward the same tiered library order from Intune Figma Rebuild rather than choosing among subscribed libraries arbitrarily.

Creating from a legacy Figma file

When a Figma file exists, the prompt asks the agent to analyse its components, variables, tokens, layouts, styles and naming before identifying transformations and refactoring opportunities.

Creating from a screenshot

When no Figma source exists, the prompt asks the agent to infer the layout, information architecture, components and tokens from the image, then rebuild the screen with explicit structure.

What I learned: the quality rules developed across the earlier plugins could become generation instructions. Instead of correcting a file after it was built, the agent could create the new file with those rules from the start.

## Component Search Order

Step 0: Follow the Intune Component List […]
Step 1: Search Intune UI Toolkit […]
Step 2: Search SFE […]
Step 3: Search Security Data Viz UI kit […]
Step 4: Search Fluent 2 Web UI Kit […]
Step 5: Azure Fluent Extension Icons […]
Step 6: If no component is found […] report the gap and build with
primitives + tokens from the highest-priority library.

## Core Principles

1. Library only. Before creating any frame, text, or shape, call
`search_design_system` (or `get_libraries` to confirm what's
subscribed) for an existing component. If a component (or component
set) exists, instantiate it via `use_figma` using its component key
— never hand-build a lookalike.

2. Tokens always. Colors, type, spacing, radii must come from
library variables/styles. Resolve token names via
`get_variable_defs`. If a token isn't found, surface that gap rather
than hardcoding hex/px silently.

[…]

7. Preserve component provenance. Note which library/key/variant
a result came from, and warn the user when detachment severs the
link to library updates.

8. No invented data. Headers, rows, labels come from the user's
source (screenshot, code, extraction). If data is missing, leave the
library's placeholder text and flag the gap — never paper over with
sample literals.

What evolved

The work did not begin with an agent plan. The scope changed as I learned what each tool could not solve.

• Scope: component → multiple libraries → whole file → any input.
• Method: swap → classify → rebuild → generate.
• Form: three focused Figma plugins → one agent that can work from files or screenshots.