The Best QA Is the One That Doesn’t Have to Happen
Strong baselines. Early DQA. Less testing later.
There’s a persistent myth in product teams: quality adds scope.
It doesn’t. What adds scope is discovering misalignment late.
When quality is postponed or assumed, the cost compounds — reopened tickets, regression fixes, eroded trust. It only feels expensive when it isn’t planned. Built into the definition of done from the start, it stops being “extra” and becomes foundational.
The solution isn’t more QA. It’s better baselines.
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.
This is where Design QA (DQA) earns its name. DQA isn’t about catching bugs after the fact — it’s the bridge between design and development, ensuring what ships matches what was intended. It’s also distinct from functional QA: DQA ensures visual consistency and experience alignment, while functional QA handles operations and features. Both matter. They’re not the same job.
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 doesn’t scale. Heroics are exciting; baselines are sustainable.
When Design QA Should Happen
This is the part most teams get wrong.
Todo → In Progress → Design QA → Code Review → QA → Done
DQA is most effective when it happens before code review — not after. By placing it early, visual issues are caught while the code is still in motion. Developers get design feedback before it’s locked in. Problems don’t compound. And by the time a ticket reaches code review and functional QA, the design is already confirmed — not still in question.
When DQA happens late — after code review, buried inside QA — design issues force tickets backward. More churn, more rework, more frustration. Earlier is always cheaper.
In immature systems, QA is reactive. In mature systems, QA is quiet.
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. Heavy QA isn’t always a design problem — often it’s a systems problem. If tickets are constantly reopened, the issue may not be visual fidelity. It may be clarity of intent, shared language, or structural alignment.
Setting baselines early shifts the quality burden upstream. A spacing issue caught during implementation is a quick fix. The same issue caught during QA means a ticket, rework, and re-testing. The earlier the baseline exists, the earlier errors surface — or don’t surface at all.
| 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 |
Quality Is a Cultural Commitment
Quality at this level isn’t a process improvement. It’s a cultural commitment. You can’t bolt it on after the fact. It requires cross-functional respect, shared vocabulary, and a willingness to slow down briefly to move faster later.
When design has a seat at the table during planning, quality becomes strategic. When design enters at the end, quality becomes corrective.
Designers shouldn’t be asking for “more time for QA.” We should be advocating for systems where quality is the default.
