Design QA can be a challenge
There are other fundamental flaws that can make Design QA a challenge:
Teams or companies do not understand or value design enough to create a process that fosters good design outcomes → “the feature works”
People don’t see the difference between a design and a poorly coded version of it → “looks good enough to me”
The focus of teams is on speed and feature delivery — and visual integrity is easier to cut than coding → “we don’t have time for it”
Speed vs. quality
To elaborate on the last point, as a product team works together, they sometimes run the risk of getting into feature delivery mode and shipping.Teams can lose sight of the bigger picture and attention to detail while trying to close as many tickets as possible before the Sprint ends. As a team races to the end of the Sprint and increases velocity, this may create a scenario where the integrity of the design implementation can fall to the wayside as a “time-saving” measure.
Collaboration is good, but it’s not enough
I’ve written before about how teamwork and collaboration are necessary requirements for product teams to do great work together. Co-designing at the conceptual stage, designer and developer pairing, using tools like Zeplin to create transparency and bridge the gap between design and CSS; these are all great and do help, but they don’t take the place of having a designer formally sign-off on coded designs before they are shipped.