Creative workflows often add QA on the assumption that more review means fewer mistakes. But when the requirement is already clear, additional review can introduce a different problem: interpretation.
Production works to the client reference, an approved standard, or a defined technical requirement. Then someone reviews the result and says it “doesn’t quite match” or “feels different.”
Unless they can identify what requirement failed, production now has a different problem to solve: figuring out what the reviewer means.
That creates an open loop—more questions, more handoffs, more opinions, and more opportunities for the original requirement to get diluted.
The answer isn’t less QA. It’s defined QA.
A useful QA check should be able to answer three things:
What was required? What failed? What needs to change?
If those questions can’t be answered, we’re no longer simply checking the work. We’re introducing another creative decision.
QA should close the loop, not open another one.
The Telephone Effect
This is a familiar problem in creative production: a clear client requirement passes through several people, and each handoff creates another opportunity to reinterpret it. What started as a specific request can become an internal discussion about whether something “matches,” “feels different,” or looks right to someone else.
The problem isn’t necessarily that anyone is acting maliciously or that QA shouldn’t exist. The problem is that every additional interpretive handoff can move the workflow further away from the original requirement. Instead of checking whether the work meets an agreed standard, people start trying to work out what everyone else thinks the standard should be.
That’s the creative version of the telephone game. The more people who reinterpret the message, the less certain everyone becomes about what the original message actually was.
And that’s where QA can become counterproductive: instead of reducing uncertainty, it creates it.it.
QA Is Not the Problem
I don’t have a problem with QA. If I miss the requested image, extract the wrong room, leave an object in that should have been removed, introduce a stitching error, or fail to follow a client reference, I want someone to catch it.
That’s useful.
The difference is that those problems can be pointed to. There is something specific to fix.
If the exterior is too dark, say the exterior is too dark. If the wrong image was used, show me which one. If the client asked for something warmer, tell me that.
What doesn’t help is feedback like “it feels different,” “it doesn’t quite match,” or “something seems off.” Maybe the person reviewing it is seeing something I don’t. That’s fine. But if we’re going to send work back, we need to be able to explain what we’re asking to change and why.
Otherwise the editor is left trying to guess what the reviewer means.
That’s not QA closing a loop. It’s opening another one.
When QA Has No Finish Line
The trouble starts when QA doesn’t have a clear definition of what it’s checking.
“It doesn’t seem to match” might be a legitimate concern, but it leaves the person doing the work to figure out what “match” actually means. Is it the color? The exposure? The composition? The view? Something else?
That’s where the extra loop starts. Instead of fixing a known problem, production has to investigate the feedback itself. Someone asks for clarification, someone else weighs in, and the original request gets further away from the conversation.
And because nobody has clearly defined what needs to change, nobody has clearly defined when the work is finished either.
That’s the irony of undefined QA:
It’s supposed to catch problems, but it can create a problem that didn’t exist in the first place.
And there is a deeper tension underneath it.
The existential crisis of QA is making sure QA still has a job.
If the process is expected to find mistakes, but nobody has defined what counts as a mistake, there is always room to find something. A preference can become a defect. A difference can become an issue. An uncertainty can become another review cycle.
The result isn’t necessarily bad-faith behavior. It’s what happens when a process has a responsibility to find problems but no objective condition for stopping.
The more people brought in to resolve it, the longer it takes and the less certain everyone becomes about what “right” actually means.
QA needs a finish line too.
The Cost Isn’t Just Time
An open QA loop doesn’t just add another step. It changes what the work costs.
1. More opportunities for error
Every additional handoff is another chance to misunderstand the original requirement. The more people interpreting the work, the more chances there are for the message to drift.
2. Longer turnaround
A simple correction can become a long conversation when nobody can agree on what actually needs correcting. Five minutes of editing can turn into thirty minutes of messages, questions and escalation.
3. Moving goalposts
Something can meet the original brief and still get sent back because someone has introduced a new preference that was never part of the brief. Now the target has moved, but nobody has formally said that it has.
4. Reduced ownership
When several people start making informal creative decisions, it becomes unclear who actually owns the final call. The editor is responsible for the output, but someone else is influencing what that output should be without necessarily owning the result.
5. Unnecessary cognitive load
Instead of solving the client’s problem, production starts trying to solve an internal one: What does this person actually want me to change?
“Make the exterior view brighter” is easy to act on.
“Something feels different” isn’t.
The second one doesn’t give production a problem to solve. It gives production another problem to interpret.
When the Workflow Becomes the Work
There is another problem with too much QA: eventually, people stop questioning the process itself.
When a workflow has enough steps, checks, approvals and handoffs, it becomes easy to slip into process mode. Everyone knows what they’re supposed to do next, so they do it. Check the image. Send it back. Ask someone else. Get another opinion. Recheck it. Upload it. Review it again.
At some point, we’re no longer asking whether the step is useful. We’re just following the sequence because that’s how the work is done.
That’s where the cookie jar analogy comes in. Everybody can have a role, and everybody can contribute. But if everyone keeps reaching in to check, adjust, approve and recheck the same thing, eventually the cookie gets handled more than it gets made.
The goal isn’t to remove people from the workflow. It’s to make sure each person has a reason to be there.
The client defines the requirement. The coordinator communicates it and keeps things moving. The editor makes the creative and technical decisions. QA checks the agreed requirements. Delivery closes the loop.
Then everyone moves on.
The danger is when the process becomes more important than the outcome. We start optimizing for “Did I do my step?” instead of “Did we solve the client’s problem?”
That’s how a team can become very good at following a workflow that nobody is stopping to question.
The Rule: Know Who Owns the Decision
QA doesn’t need to be complicated. It needs something objective to work against.
Before sending work back to production, there should be a clear answer to one question:
What requirement does this fail?
That requirement usually comes from one of three places: the client brief, an approved company standard, or an identifiable technical defect.
If the client wants the image warmer, that’s the requirement. If there is a stitching error, that’s the defect. If the work doesn’t follow the approved style, point to the standard it missed.
What it shouldn’t come from is someone’s personal preference appearing halfway through the process and quietly becoming a new requirement.
An image can always be warmer, cooler, brighter, darker, cleaner or “better.” But if nobody asked for that change, it isn’t QA identifying a failure. It’s someone introducing a new creative direction.
And this is where experts matter.
We’re paying professionals because they know how to make the right decisions within their area of expertise. The client should be listened to because they define the outcome they want. The specialist should be trusted because they understand how to achieve that outcome. QA should make sure the agreed requirement has actually been met.
Those responsibilities are different.
The client shouldn’t have to dictate every technical decision. The specialist shouldn’t have to defend every creative choice to people who aren’t responsible for making it. And QA shouldn’t become a second creative director simply because it has been given permission to send work back.
When those boundaries blur, everyone starts making the same decision from a different perspective. A coordinator becomes a reviewer. A reviewer starts directing the work. A specialist starts responding to preferences that were never in the brief. The client may ultimately get something different from what they asked for, while everyone involved believes they’re simply doing their job.
That’s when the goalposts start moving.
A good workflow doesn’t require fewer people. It requires clear ownership of decisions:
Client: What do we want?
Expert: How do we achieve it?
QA: Did we achieve what was agreed?
If QA finds a failure, it should be able to point to the requirement, standard or defect.
If the requirement has changed, someone needs to own that change.
If there is no requirement, standard or defect to point to, then QA shouldn’t invent one.
We’re paying experts to make expert decisions. We’re listening to clients because their requirements matter. QA exists to protect both—not to become a third source of creative direction.
Closing the Loop
The answer isn’t to remove QA or strip people out of the process. It’s to stop adding decision points that don’t have a clear purpose.
A good QA loop should make the work clearer: something is checked against an agreed requirement, a problem is identified, it gets corrected, and the loop closes.
When the feedback is vague, another person is brought in, then another interpretation, then another review, the process starts generating its own work. The work may still be moving, but nobody is quite sure who is deciding what—or what they’re deciding against.
That’s where process theatre creeps in. People are checking because checking is what the process tells them to do, even when nobody can clearly explain what they’re checking for or what decision they’re supposed to make.
The goal isn’t fewer people.
It’s fewer unnecessary decisions, fewer overlapping responsibilities, and a clear reason for every review.
Everybody can get a cookie. The trick is not having everyone reach into the jar at the same time.
Let the client define what they want. Let the expert decide how to achieve it. Let QA verify what can actually be verified. And when the requirement is met, close the loop and move on.
Leave a Reply