Thorough manual visual QA is slow enough that teams naturally take shortcuts, and those shortcuts leave gaps.
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.
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.
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.
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.
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.
