When “Done” Isn’t Done: Why Most QA Misses What Actually Matters
By Brad Holmes
QA should be the final polish the moment everything clicks into place.
But more often than not, it’s where projects go to die in a pile of comments, screenshots, and circular feedback threads.
I work across a lot of teams agencies, dev partners, internal designers and it’s the same every time. QA becomes a box-ticking exercise. Everyone checks what works, but not what feels right.
That’s the gap between functional and finished. And most teams never cross it.
Task-Oriented QA Is the Root of the Problem
Somewhere along the way, QA turned into admin.
“Does the button click?”
“Does the form submit?”
“Is the text readable?”
Check, check, check. But no one stops to ask the only question that really matters:
“Does it actually look and feel right?”
Task-oriented QA tells you something functions.
It doesn’t tell you if it’s good.
And that’s how we end up with pages that technically pass QA but visually feel wrong misaligned buttons, broken hierarchy, uneven padding, micro-interactions that feel off. Stuff that’s invisible to the spreadsheet but obvious to anyone who knows what “done” should look like.
The Hidden Cost of “It Works”
When QA stops at functionality, design takes the hit and the product feels cheaper than it should.
The user might not notice what’s wrong, but they’ll feel it.
A form that jumps slightly on focus.
A headline one pixel off from the grid.
An image that loads just a beat too slow.
Tiny things, but together they make the experience feel untrustworthy.
If it doesn’t feel right, it doesn’t convert, no matter how “correct” the implementation is.
That’s what makes this so frustrating teams spend weeks designing something beautiful, then shave off all the quality in the last 5% because QA stops at “working.”
Why It Keeps Happening
Most QA breakdowns aren’t about talent. They’re about focus.
Developers are focused on logic.
Designers are focused on layout.
PMs are focused on timelines.
Everyone’s doing their job, but nobody’s looking at the whole picture.
So QA becomes an assembly line instead of a feedback loop. Each role checks their piece, but no one’s checking the product experience.
And because QA is usually handled by whoever’s left at the end, it becomes something to “get through” not something to improve through.
That’s why “done” so often means “done enough.”
The Reality of Cross-Team QA
When you work across multiple teams or agencies, this problem multiplies.
Everyone assumes someone else caught it.
Developers check if it compiles.
Designers assume devs followed the spec.
Project managers assume both sides are aligned.
By the time the thing lands in front of me, I can already see the visual drift — the button that’s 4px too low, the hover state that doesn’t match, the type rhythm that’s gone flat.
Then begins the back-and-forth: screenshots, tickets, notes, and polite frustration.
It’s not ego it’s trying to close the gap between “works fine” and “feels right.”
And that gap exists because most QA processes were built by engineers, not designers.
What Good QA Actually Looks Like
Good QA isn’t about proving something works. It’s about validating that it feels finished.
That means:
- Zooming out before zooming in. Start with the whole page. Does it breathe? Does the flow feel balanced? Then dive into details.
- Testing for rhythm, not just rules. Visual design isn’t math. It’s balance. QA should include gut checks, not just grid checks.
- Breaking your own work. Resize, reload, refresh. Use it like a user. If it falls apart under normal behaviour, it’s not done.
- Naming the invisible. Don’t just say “this looks off.” Say why. Is it contrast, spacing, timing, or proportion? It teaches the team to see what you see.
This isn’t pedantic. It’s what separates “good enough” from “worth shipping.”
How to Stop QA from Becoming Chaos
QA fails when it’s treated as the end of the project. It works when it’s treated as part of the build itself.
I’ve stopped waiting for “final QA.” Now, I QA as I go every commit, every visual change. I run quick checks mid-stream, so by the time it’s handed over, it’s already tight.
That small shift saves hours of back-and-forth later because you’re catching the drift early, not retrofitting it after everything’s “locked.”
If I can give teams one rule, it’s this: QA isn’t a task it’s a mindset.
You don’t check work to get it off your list. You check it to make sure it still looks like something you’d be proud to have your name on.
10 Simple Rules for QA That Actually Works
1. If it feels off, it is off.
Don’t talk yourself out of what your gut already knows. QA isn’t just logic — it’s instinct.
2. Don’t trust screenshots.
Open it. Click it. Resize it. Screens hide problems that movement reveals.
3. Never QA in isolation.
If you’re only looking at one screen or one breakpoint, you’re missing context. Products live across devices.
4. Read the page like a human, not a dev.
Forget the spec for a second. Does it flow? Does your eye know where to go next? If not, something’s broken.
5. Test the edges, not the centre.
Everyone checks the hero section. Few people check what happens when the content doubles or when a user breaks form validation. That’s where real issues hide.
6. Name the problem, not the pain.
Don’t just say “it looks wrong.” Say why: spacing, alignment, timing, rhythm. It helps other people learn to see what you see.
7. Don’t assume someone else caught it.
They didn’t. If you noticed it, it’s yours until it’s fixed.
8. Treat QA as part of design, not the end of dev.
QA isn’t a clean-up job — it’s how design intent survives development.
9. Avoid “good enough.”
“Good enough” always comes back. If you spot a problem and let it slide, it’ll find you later — right before launch.
10. Never forget who it’s for.
QA isn’t for the project team. It’s for the user who doesn’t care about your tickets, deadlines, or excuses.
Pro Tip: Do one final pass like a user, not a builder. If you hesitate or squint, fix it. QA isn’t about bugs it’s about friction.
The Bottom Line
QA is supposed to protect quality, not paperwork.
But if all you do is tick boxes, you’re protecting nothing.
The best QA doesn’t just confirm something works — it confirms it feels finished.
Because users don’t care about your Jira board or your task status.
They care whether what you built feels right.
Brad Holmes
Web developer, designer and digital strategist.
Brad Holmes is a full-stack developer and designer based in the UK with over 20 years’ experience building websites and web apps. He’s worked with agencies, product teams, and clients directly to deliver everything from brand sites to complex systems—always with a focus on UX that makes sense, architecture that scales, and content strategies that actually convert.