Verify UI components in the page they ship in

A component can be pixel-perfect on its own and broken inside the page that ships it. Memo’s UI Verifier is built around exactly that gap. It is worth taking apart, because the interesting decision sits in how it verifies, not that it verifies. You can read the UI Verifier automation file on GitHub (opens in a new tab).

It runs on every merge that touches UI

It runs the moment a pull request merges. The trigger is the merge event itself, nothing scheduled. If the merge touched no UI files, it stops right there and does nothing.

First a static pass against the design rules

When UI did change, it goes to work. First comes a static pass: it reads the design rules and checks the diff against them. Color tokens, the type scale, spacing, button variants, loading and empty states, transitions, accessibility, dark mode. No arbitrary hex values, no off-scale font sizes.

Then two screenshots of every changed component

Then it gets visual. It screenshots every changed component in isolation, in the component workbench. Then it screenshots the same component on the live site, at the same desktop viewport, and compares the two.

That comparison is the detail worth copying. The workbench shows you a component drawn under perfect conditions. The live page is where layout constraints from parent containers, the CSS cascade, missing wiring and clipped overflow all get a vote. A datepicker that renders fine alone can fall back to a plain input once it is inside the real form. Only the side-by-side catches that.

If it finds a violation, it files a concrete issue: the file, the line, and what the design spec actually says. If everything holds, it stays quiet.

Users never see the isolated component

Here is the point I keep coming back to with teams building their own checks. Most visual verification tests the component, because the component is the easy thing to isolate. But your users never see the isolated component. They see it embedded, deep in a real page. A check that only verifies isolation verifies a thing that does not ship.

Integration context is part of verification. Isolation testing reassures you. The integration view tells you the truth. Both are cheap to automate once you decide the second one is not optional.

When a UI bug reaches your users, is it usually the component itself that was wrong, or the page it landed in?

Further reading

• The surrounding quality system →
• Agentic Software Factory: Advanced Team Training →