Paul Wilshaw · Designed for Humans

Claude skill

UAT: checking live builds against Figma with AI

My user acceptance testing (UAT) skill checks a live web page against its Figma design at desktop, tablet and mobile sizes. It measures the build, compares it with the Figma frame and the design tokens, grades every issue by severity and writes a report. A person reviews and accepts the report before it goes into the ticket.

What problem does it solve?

Design QA gets squeezed on every project. A designer opens the build, squints at it next to Figma, resizes the browser a few times and writes a list of things that look off. It's slow, it depends on who's doing it and how tired they are, and small issues slip through until a customer finds them.

I wanted the measuring done properly every time, so designers could spend their time deciding what matters instead of hunting for 4-pixel differences.

How does it work?

The skill runs as a fixed set of steps:

  • Brief: a short form takes the ticket, the test URL and the Figma frame, plus the breakpoints (393, 768 and 1440 pixels by default).
  • Read the design: Claude pulls the frame's real values from Figma through the Figma MCP connection and checks them against the design tokens. If that connection isn't available, it asks for a screenshot rather than guessing.
  • Test the build: in Chrome it resizes to each breakpoint, takes full-page screenshots, measures the layout and tries 15 interactive states, such as hover, focus, disabled and error.
  • Judge: each item is a pass, fail or note. Positions and sizes must be within 4 pixels, and copy and colour must match exactly. If a value uses the right design token for that screen size, it passes, even if the raw pixels differ slightly from the Figma frame. Issues are graded Breaking, High, Medium or Low.
  • Human review: a reviewer goes through every finding, adjusts severity, adds notes, ignores or retests, then accepts the report.
  • Hand back: the agreed report goes straight into the ticket's testing notes in Azure DevOps.

It works to WCAG 2.1 AA, British English and sentence case in everything it writes, because those are the standards I'd hold a designer to.

Why keep a person in the loop?

Spotting a difference and judging whether it matters are two different jobs. A 5-pixel gap on a marketing banner might be fine. The same gap on a checkout button might not be. The skill does the measuring, and the person makes the calls.

Can it test on real phones?

Not directly. It uses Chrome's device emulation, which is accurate for responsive websites and needs no emulator or access to the codebase. For anything that needs a real device, the report structure still works, and findings are marked as manual.

What's next?

It's grown into a full specification for the Design Systems for Humans app: cost tracking with a budget cap, visual regression, accessibility audits, checks on every deploy and a design system compliance scan.

I'm also reworking it into two modes. One checks a design against the design system and the product context, before anything gets built. The other checks any output, whether that's code, a URL or a preview, against the design, the context and the design system together. And I want to make it friendlier for designers who don't live in developer tools.

Setting this up for your team

At Designed for Humans I set up AI-assisted design QA for product teams, including the UAT skill, the Figma connection and the review process. It works best alongside Design Systems for Humans, so the tokens the skill checks against are the same ones your designers and developers use.

See how we can work together, or browse the other Claude skills I've written.