Evolving DesignOps with AI

Context

Figma files accumulate design debt over time as products evolve: outdated components, fragmented libraries, inconsistent structure, and components broken down into individual layers. I encountered these issues repeatedly while working across Microsoft Security, where designs often needed to align with multiple design systems and libraries.

As AI became part of the design workflow, the structure of the Figma file became increasingly important. A visually accurate design was not enough. For AI to interpret, generate, or work with a design downstream, the file needed meaningful components, variables, tokens, auto layout, and semantic naming.

Problem

Design debt made legacy Figma files harder to maintain and use with AI.

Cleaning up and rebuilding legacy files was slow and repetitive. Maintaining design system compliance across multiple libraries made the work even harder. The challenge was to automate this work, then extend it from cleanup to generating structured, AI-ready Figma files.

Approach

Remediate → Understand → Rebuild → Generate

The workflow evolved from remediating individual components, to understanding multiple design systems, to rebuilding entire Figma files, and finally to generating structured, AI-ready Figma files from an existing file or screenshot.

1. SFE Adoption Assistant (Figma plugin)

To make legacy design cleanup more efficient, I built the SFE (Security Fluent Extension) Adoption Assistant, a Figma plugin that:

• analyzes selected elements
• matches non-SFE components to SFE components
• lets the designer approve replacements

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

2. Compare before replacing Review the proposed SFE component and the attributes used to determine the match.

3. Verify the result Rescan the selection to confirm that components were replaced with valid SFE instances and no replaceable elements remain.

What I learned: Matching against a single library was not enough. To make the tool useful beyond my immediate team, it needed to support multiple design systems and libraries.

2. Design System Calibrator (Figma plugin)

To extend the workflow beyond a single library, I built the Design System Calibrator around a configurable component registry. It lets designers:

• choose a baseline design system
• compare selected instances against that baseline
• identify baseline, non-baseline and orphaned components
• preview, approve or undo replacements

1. Choose the design system Select a library from the available design systems to define the baseline.

2. Select scope Choose which elements to inspect while keeping the selected baseline visible.

3. Review classified results See baseline, non-baseline, local and orphaned instances separately before making changes.

4. Report and undo changes Confirm successful replacements, with options to undo or rescan.

What I learned: A product file could use components from multiple tiered libraries at the same time. Choosing the right components was only part of the problem. The file also needed a consistent structure that reflected which design system each component belonged to.

3. Intune Rebuild (Figma plugin)

Once I saw that file structure was as important as the components themselves, I moved from component replacement to whole-file reconstruction. Since more than 90% of my design work was in Microsoft Intune, I built a plugin that:

• inspects file structure against defined rules
• determines whether a file can be fixed or needs to be rebuilt
• rebuilds the file with consistent structure, auto layout, variables, tokens and semantic naming

When rebuilding a file, the plugin selects components from the correct design systems following a tiered search order: it starts with Intune's recommended components and Intune UI Toolkit, then checks SFE, Security Data Visualization, Fluent 2 Web and Azure Fluent Extension library. A lower tier is used only when a higher tier does not provide the needed component.

1. Select a frame Inspection is read-only and evaluates the selection before rebuilding.

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

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

4. Register component keys (optional) Registered keys connect rebuilt elements back to known library components.

What I learned: rebuilding still depended on having a Figma source. Sometimes the available input was just a screenshot. The next tool needed to generate a new AI-native Figma file from either.

4. AI-Ready Figma (AI agent)

The Intune Rebuild addressed inconsistent structure in existing Figma files. But sometimes the only available source is a screenshot, leaving designers to recreate the design from scratch.

To close this gap, I moved from a Figma plugin to an AI agent that can generate a new, structured Figma file from either an existing Figma file or a screenshot. The agent:

• analyzes the source and identifies the underlying design structure
• uses components, variables and tokens from the specified libraries
• follows the same tiered library order established in Intune Rebuild

A. Creating from a legacy Figma file

When a Figma file exists, the agent first analyzes its components, variables, tokens, layouts, styles and naming to identify design debt and opportunities for refactoring.

B. Creating from a screenshot

When no Figma source exists, the agent infers the layout, information architecture, components and tokens from the screenshot, then rebuilds the design with explicit structure.

## 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 I learned: The quality rules developed across the earlier plugins could become generation instructions. Instead of correcting design debt after a file was built, the agent could apply those rules from the start, creating a structured, AI-ready file and preventing new design debt from accumulating.

Outcome

• Accelerated design by turning repetitive Figma cleanup and reconstruction into an AI-assisted workflow.
• Improved design system compliance by using components, variables, tokens and tiered library rules throughout the workflow.
• Modernized legacy files by inspecting and rebuilding existing Figma files with consistent structure, auto layout and semantic naming.
• Enabled downstream AI workflows by creating structured, AI-ready Figma files that could be interpreted by AI for working prototypes and reusable code.
• Drove adoption across the organization by sharing and enabling the AI-ready Figma workflow across the Security UX org and Autopatch PM team.