How manual visual QA works and what it actually takes

How manual visual QA works and what it actually takes

Manual visual QA is the default approach for most teams: someone opens the Figma design and the live implementation side by side and checks whether they match. It sounds straightforward. In practice it is more time-consuming, more inconsistent, and more error-prone than it tends to get credit for.

What the process actually involves

A thorough manual visual check on a single page is not a quick scan. Done properly, it involves working through each element on the page systematically, comparing what is visible in the browser against what the design specifies.

For each element, a reviewer needs to check the properties that are most likely to have drifted: typography, including font size, weight, line height, and letter spacing; spacing between and around elements; colours and opacity; borders and border radius; and component dimensions. None of these can be verified by eye alone with any reliability. They require switching back and forth between the browser and the design file, often zooming into both to compare values at a level where small differences become visible.

On a complex page, a thorough visual check can take an hour or more. Few teams actually make this investment in full.

Where it tends to break down

Most manual visual QA does not look like the process described above. It looks like a developer glancing at the implementation before submitting it for review, a designer checking a few key screens after the fact, or a QA engineer working through a list of pages without a systematic property-by-property approach.

The result is that a lot of visual drift gets through. Not because anyone was careless, but because thorough manual visual QA is slow enough that teams naturally take shortcuts, and those shortcuts leave gaps.

Small spacing differences, font weights one step off, colours close but not exact — these are exactly the differences that accumulate into an implementation that feels slightly off.

The consistency problem

Even when manual visual QA is done carefully, the results vary. Different reviewers have different tolerances for what they consider acceptable. The same reviewer has different tolerances depending on how much time they have and how tired they are. A deviation that gets flagged on Monday might pass on Friday.

This inconsistency is not a character flaw. It is a consequence of asking people to perform a task that requires sustained, calibrated attention across a large number of elements. Human attention is not consistent in that way, and no amount of effort or process can make it so.

What this means for teams

Manual visual QA is not worthless. A careful reviewer with time and attention will catch things that automated tools miss, particularly anything that requires understanding context or intent rather than measuring values. The problem is that the conditions required for it to work well are rarely present in practice.

Most teams end up with a hybrid: some manual checking happens, some drift gets through, and the threshold for acceptable shifts based on circumstances rather than standards.

What happens to the result

A manual visual check produces a judgment, and that judgment rarely stays with the person who made it. It gets passed to whoever has to act on it, usually as a short summary. The reasoning behind it stays with the reviewer.

This is where inconsistency stops being an individual problem. When a reviewer says the spacing is off and the developer does not see it, there is nothing to appeal to except two people's eyes. The conversation turns into whose reading is right rather than what the design specified.

A check that produces values instead of impressions gives both people the same thing to look at.

There is a case for making visual QA systematic that has nothing to do with catching more. When a check records what was compared, and against which version of the design, the reviewer is no longer the evidence. They can point at the comparison rather than at their own attention, and the developer can disagree with the design rather than with the reviewer.