Automated design QA uses repeatable checks to find discrepancies between a product's intended interface and its implementation. A useful workflow connects those checks to the changed code, shows enough evidence to verify a finding, and gives someone responsibility for accepting or fixing it.
Start with one important journey, such as creating a project. Define the states and screen sizes that matter, identify your design reference, and decide what evidence a reviewer needs. Adding automation before answering those questions produces findings without a clear decision.
This guide proposes a workflow for teams that already ship frontend code and want design review to become a routine part of that process.
Define what “correct” means
Your reference might be an approved design, an existing component, a documented token, or an explicit acceptance criterion. Record which one applies. The design system consistency audit provides a method for establishing the component and token reference. If a new page intentionally introduces a different layout, a reviewer needs to know that before treating the difference as a defect.
Use references at the right level:
| Question | Useful reference |
|---|---|
| Should this input use the shared component? | Existing component API and usage |
| Is the section spacing intentional? | Approved layout or spacing token |
| Should this content wrap on mobile? | Responsive acceptance criterion |
| Did an unrelated element move? | Previously accepted rendered state |
| Is this interaction understandable? | User task and human review |
Avoid an acceptance criterion such as “make the page look polished.” Describe the observable outcome: “The project name wraps without covering its menu, and the menu remains reachable.”
Give each check a specific job
Source review, visual comparison, and human inspection answer different questions. Build your workflow around the question rather than around a single label such as “AI testing.”
Source review examines the implementation. It is useful for checking component usage, styling choices, and how states are represented. Treat a finding inferred from source as a claim to inspect, especially when its visible effect depends on data or surrounding layout.
Screenshot comparison checks rendered output against an accepted reference. For example, Playwright creates reference screenshots and compares subsequent runs against them. Its documentation also explains that rendering varies across environments, so consistent baselines require consistent test conditions. Playwright visual comparisons
Human review resolves intent and tradeoffs. A changed layout may be approved. An unchanged layout may still be confusing. Assign these decisions to someone who understands the product task.
AI-assisted review can participate in more than one layer. The relevant buying questions are what it inspects, what it compares against, and what evidence it produces. Use the UI design review tools comparison to map those questions to available products. The comparison of visual regression testing and AI design review explains that distinction in more detail.
Build a review packet before running automation
Give each reviewed change a compact set of inputs:
- The exact revision and a reachable preview, when rendering is part of the review.
- The changed routes or components.
- The design references and intentional exceptions.
- The states and data needed to reproduce the interface.
- The selected viewport sizes and themes.
- The person responsible for resolving findings.
For an illustrative project-creation flow, the packet might cover the empty form, a validation error, submission in progress, and success. Include a long project name and a narrow viewport. These are proposed cases, not results from a product test.
Keep the initial matrix small enough to understand. Expand it when a shared component change or a discovered defect provides a concrete reason.
Separate a failed check from a failed setup
A useful result says what ran and what was observed. Make room for at least four outcomes:
| Outcome | Review action |
|---|---|
| A defect was reproduced | Assign a fix and a verification condition |
| A possible defect needs context | Ask the owner to resolve the uncertainty |
| The selected checks found no issue | Record the scope that was inspected |
| The preview or check failed to run | Resolve the setup problem and rerun |
Do not treat a login screen, an empty render, or an unavailable preview as a clean review. Likewise, “no findings” only describes the checks that ran. It says nothing about unvisited routes or states absent from the test data.
The finding itself should name the location, actual behavior, expected behavior, and user impact. Use the UI bug report template to standardize that evidence.
Introduce automation without blocking every change
Begin with a representative set of pull requests and review the findings alongside your existing process. Record which findings were confirmed, which were rejected, and which could not be evaluated. Do not invent an accuracy score from unresolved cases.
Choose any blocking rules from that evidence. A reproducible primary action hidden behind an overlay may justify stopping a release. A disputed spacing preference may need discussion. A preview failure needs a separate decision based on the importance of the unverified change.
For teams reviewing UI in GitHub, Design Bug Bot reports design issues with proposed code changes. Evaluate its findings using the same evidence and ownership rules.
Keep a human release decision
Close each confirmed finding by checking the original reproduction and the relevant neighboring states. A narrower button may solve one overflow case while truncating a longer label elsewhere; include that boundary in the acceptance criteria.
Keep accessibility evaluation in the release process as well. W3C explicitly describes its easy checks as an initial review that can miss significant barriers, not a comprehensive evaluation. A short visual pass should carry the same scope limitation. W3C accessibility checks
Before adopting a new automation layer, your team should be able to answer: what did it inspect, what evidence supports the result, and who makes the next decision? The design QA checklist turns those answers into a repeatable review pass.