A design system QA skill

Role

Lead product designer

Timeframe

May 2026

Team

Atlas Design System

Scope

Figma review workflow and AI skill

Getting to a first version is no longer the hard part.

The hard part is knowing whether the version you made actually belongs to the system.

A component can look right in Figma and still be wrong in code. The variant may not exist. The icon may have been overridden. The content may not follow the pattern. Two primary actions may be competing for attention.

None of these things are hard to fix. They are just easy to miss.

Design-system documentation can answer most of these questions. But documentation has mostly been one way. Someone writes it. Someone else goes looking when they need an answer.

On Atlas, I wanted to see what would happen if the documentation could do more than wait.

A first pass with Atlas

Documentation is already an extension of the system. It holds the thinking behind the components: why they exist, how they should be used, and where their boundaries are.

As a system's lead, I get versions of the same question in Slack and Figma every day. Is this the right component? Does this pattern fit the experience someone is trying to create?

I like being part of those conversations. But a useful answer takes more than a quick yes or no. It takes the context behind it—the kind that helps someone understand the system instead of treating it as a list of rules.

The Atlas QA skill is a plug-in built to make that first pass available earlier. It brings Atlas guidance, and the context I usually provide in a review, into the work while the decision is still being made.

The idea is to change the timing, not the ownership. A designer should be able to get an answer while they are still working. An obvious mismatch should not need to wait for a review. That leaves more of the review for decisions that actually need product context or judgment.

How it works

Figma frame → Atlas component documentation → QA review → Figma annotations or a confident fix

The skill starts with a Figma frame or flow.

It identifies the components and patterns in use, then reads the relevant Atlas documentation: approved options, usage guidance, behavior, and the boundaries of the pattern.

This is not a generic review of a Figma frame. The Atlas documentation is generated into a Markdown file for each component and included with the Codex and Claude plug-ins.

When the skill finds an Atlas Carousel in a frame, it can review the Atlas Carousel documentation specifically. It is not trying to infer the right answer from the visual alone.

That distinction matters. The feedback is grounded in the system's actual decisions, and it can point back to the guidance behind the recommendation.

From there, it compares what is in the frame with what the system says that component is meant to do. The result is a chat-based review: what it found, where the work is aligned, where it may need another look, and why.

What it checks

The skill reviews a few layers at once:

• Component use: Is this the right Atlas component? Are its properties and variants valid? Has anything been overridden in a way that cannot work in code?
• System guidance: Does the content follow the guidelines? Are tokens and layout patterns used as intended?
• UI clarity: Are actions ordered clearly? Are two primary buttons competing? Is there enough hierarchy to make the next step obvious?

That means one review can surface a precise implementation mismatch and a broader experience issue.

From review to resolution

In a real review, the output has two parts. The chat explains what the skill found and why it matters. Figma annotations point directly to the component or pattern that needs another look.

In this review, the skill found two different kinds of problem in the same frame.

The carousel had been detached from the published Atlas component. The cards inside it had a different issue: each represented a single navigation outcome, but used custom card content where AtlasTile was the intended pattern.

The skill explained both findings in chat, then attached them to the relevant parts of the Figma frame.

The last part of this experiment is still in progress. I am exploring what happens when the skill can move beyond feedback and make a correction itself—but only when it has a clear, confident resolution.

When the right fix is clear, the skill can make it. When the decision needs product context or judgment, it should explain the issue and leave the decision with the designer.

The goal is not to let the system make every design decision. It is to remove the obvious fixes so designers and reviewers can spend their time on the decisions that actually need them.

This is still a V1

The QA skill is one example of what this could become. We are already talking about a bundle of skills the team could use in different parts of the work.

A content skill could follow and reference our content guidelines when reviewing fine print, superscript, calls to action, and other patterns that are easy to get almost right.

A research skill could use our team’s MCP servers to find past research readouts, bring the relevant evidence into the conversation, and cite where it came from.

Those are only the first two examples. The useful part is not how many skills we can make. It is how much of the team’s shared knowledge can become available while the work is still being shaped.