What is the most time-consuming part of comparing Figma designs with implemented websites?

For people doing website QA or design QA: when comparing a Figma design with the implemented website, what part usually takes the most time or feels the most annoying?

I’m curious about the real workflow more than the “ideal” workflow. Do you usually compare things by eye, screenshots, browser devtools, visual regression tools, or something else?

Also, what kinds of differences do you end up catching most often?

If the figma protoype is built correctly, it saves a lot of time. Also, devs can now pick exact values from figma designs and AI makes it even more accurate so design matching should effectively be easier now.

In my opinion more responsibility should lie with the dev to not make any errors in design implementation, I mean its right there what could go wrong.

I catch component height issues very often.

I last did this over a year ago, the most annoying thing is the designers are often using a wrong version of the product to base their designs on. Second-most time consuming is designers often have no concept of which screens users will see most often and which ones they will not. And that has to scale because screens with more information need to be screens people rarely have to see. If not, the workflow is impacted, because a busy screen slows users down. It’s easy enough to highlight to the designers though.

Devs do make mistakes, but usually because the designs changed after they started (that’s just to be expected) and then working out what exactly has changed is incredibly hard unless designers make notes in actual “text” after a notable change.

Regression tests with Figma designs that change often really are a pain :sweat_smile:

Comparing the font size of the implemented website with the Figma design is one of the most time-consuming and tedious tasks for me. Sometimes the developer doesn’t inform that the font used in Figma is not available, and they implement it with whatever is available, and in such cases it becomes a time-consuming task to first ask the PM to check the current implementation and then share their feedback on the ticket.

I had the font thing once, and I found it was the most fun task ever, because you only want to have a few fonts in use and you need licenses and guess what licenses is not the responsibility of the engineering team. The fun part was writing a bit of automation code to check the font and size in a script. And then going afterwards to a meeting and just asking politely if the font changes I spotted were intended or in-progress. You can actually get browser plugins to do this for you too, but my java is not good enough to really go down that route. So glad I work in embedded software now, none of this happens at such scale.

Would you say the Dev mode is an essential seat or can you all typically extract the right details from a standard viewer seat?