The best QA is the one that doesn’t have to happen
There’s a persistent myth in product teams: quality adds scope. What adds scope is discovering misalignment late.
I learned that on a project with somewhere between fifty and sixty open UI defects. QA had assumed someone upstream was checking the visual layer, so they had stopped looking at it. Nothing said what the design was supposed to be, so every defect was an argument about what “correct” meant before it could become a fix. More testing wouldn’t have helped, because there was nothing to test against. (Friction is the longer story of that project.)
When quality is postponed or assumed, the cost compounds — reopened tickets, regression fixes, eroded trust. It only feels expensive when it isn’t planned.
What baselines and DQA actually are
A baseline is a shared, approved starting point, a snapshot of what “correct” looks like before anyone has had a chance to deviate. When you set design baselines before implementation begins, developers have a clear reference. QA has a clear standard. The whole team shares the same definition of done. Questions like “Is this the right spacing?” or “Does this match the design?” have definitive answers from day one.
Design QA (DQA) is the bridge between design and development, checking that what ships matches what was intended. It’s distinct from functional QA: DQA covers visual consistency and experience alignment, while functional QA handles operations and features. They’re not the same job.
I’ve come to think of design review as validation work, not approval work. Signing off means confirming the experience works as designed, not that it looks right. Do the flows that worked in a prototype still work in code? Did the edge cases that were designed for actually get built?
When a strong baseline exists, DQA stops being a hunt for problems and becomes a simple confirmation that the baseline was followed. Many teams skip this and rely on sharp designers or attentive engineers to “catch things” instead. That works until those people are busy, or gone.
When design QA should happen
Todo → In Progress → Design QA → Code Review → QA → Done
DQA is most effective when it happens before code review, not after. Visual issues get caught while the code is still in motion, and developers get design feedback before it’s locked in. By the time a ticket reaches code review and functional QA, the design is already confirmed.
When DQA happens late (after code review, buried inside QA) design issues force tickets backward. A spacing issue caught during implementation is a quick fix. The same issue caught during QA means a ticket, rework, and re-testing.
How much QA a team needs is inversely related to its maturity. Mature teams deviate less, communicate earlier, and self-correct quickly. Less mature teams discover constraints late and rely on review cycles to surface what should have been aligned upfront. If tickets are constantly reopened, the issue may not be visual fidelity. It may be clarity of intent, shared language, or structural alignment.
| Without a baseline | With a baseline |
|---|---|
| Quality depends on memory and vigilance | Quality becomes automatic |
| QA is discovery | QA is confirmation |
| Issues compound late | Errors are caught, or prevented, early |
| Teams rely on heroics | Systems do the work |
Where it starts
You can’t bolt this on after the fact. It takes cross-functional respect, shared vocabulary, and a willingness to slow down briefly to move faster later.
On that project, what finally cleared the defects was pulling the design out into one source of truth the team could build against. Once the defects had somewhere to resolve to, there was far less left for QA to find.