Design QA Is Not a Gate, It's a Habit
Design QA isn't a destination at the end of the process. It should be a discipline that runs through the whole design and development lifecycle.
Design QA isn't a destination at the end of the process. It should be a discipline that runs through the whole design and development lifecycle.
How the "Gate" Model Fails
The appeal of a design QA gate is obvious: it creates accountability, it's visible in the workflow, and it gives design a formal moment to catch issues before they go to production.
The problem is what happens upstream. If designers know there's a gate at the end, there's an implicit assumption that quality will be verified then. Work gets delivered. Bugs and deficiencies surface. And suddenly the gate becomes a bottleneck, because there isn't enough time to fix what's been uncovered.
The real question isn't "did we catch it at the gate?" It's "why did it make it to the gate in the first place?"
Key reframe: the gate isn't where quality happens. It's where you confirm quality already happened.
What Continuous Design QA Actually Looks Like
Continuous design QA means building quality checks into the natural rhythm of the work — not as separate events, but as integrated moments throughout the epic and story lifecycle.
During design: Checking designs against the design system before sharing with the team, not as a final step, but as a working habit. Does this use the right components? Are tokens applied correctly? Is this consistent with adjacent flows?
During implementation: Reviewing work in a proper environment as stories move through development, not just checking the Figma file. Designers should be checking their own work against what's actually being built, on a real device, in a real environment, early enough that engineering has time to respond.
During review/test: Design participates in the review stage as an active verifier. If a story is in test and a designer hasn't looked at it in a proper environment, that's too late.
At the gate: The final sign-off is a confirmation, not a discovery. If continuous validation has happened, there should be no surprises. The "gate" becomes a lightweight verification that the work meets the standard, not a triage session.
Defining the Standard
One of the hardest parts of design QA isn't the process — it's the standard. "High quality" means different things to different designers, engineers, and PMs. Without a shared definition, QA becomes subjective and inconsistent.
The central question your team has to answer: What needs to be true for design QA to pass?
A working framework accounts for:
- Consistency with the design system — Are the right components, tokens, and patterns being used?
- Completeness of states — Are all interaction states covered: empty, loading, error, success, edge cases?
- Experience coherence — Does the implemented experience match the intended design?
- Risk calibration — Not everything needs the same level of scrutiny. Higher-risk stories (new interactions, novel patterns) warrant more verification effort.
Design QA and the Design System
Design QA and design system health are inseparable. When designers do QA, they're also auditing the design system — seeing where components are misused, where the system has gaps, where documentation is unclear. That signal, fed back into the system, makes future work more consistent and future QA faster.
Making It Sustainable
Common failure mode: when designers are stretched across multiple epics, QA is the first thing deprioritized. A few things that help:
- Make QA tasks visible. If design QA isn't tracked — as subtasks, acceptance criteria, a Jira step — it's invisible labour. Making it explicit creates accountability.
- Calibrate effort to risk. A lightweight checklist for low-risk stories, a more thorough review for high-risk ones.
- Treat QA as a shared responsibility with engineering. Designers catch experience and visual issues. Engineers catch implementation divergence.
- Use QA to inform, not just correct. Recurring issues signal root causes to address, not just symptoms to fix.
Design QA is not a gate that protects quality. Quality doesn't arrive at a gate — it's either built into the process or it isn't. The teams that do this well aren't the ones with the strictest final check. They're the ones where validation is continuous, the standard is shared, and the gate at the end is genuinely just a formality.
