When "done" means two different things to two teams, QA pays for it. Here's the shared checklist that pulled visual review earlier.
On most teams, a ticket is "done" when it passes the engineer's tests. It is also "done" when the designer confirms it matches the intent. The trouble is that those two moments don't happen at the same time — and the gap between them is where rework lives.
I watched this play out repeatedly on a large SaaS team. An engineer would close a ticket, confident the logic was right. Days later, in a release review, a designer would flag a spacing or state issue. Now the work reopened, context had to be rebuilt, and the fix competed with new sprint commitments. The visual issue wasn't caught late because anyone was careless — it was caught late because nobody had agreed on what "done" included.
The fix wasn't a new tool. It was a single, shared Definition of Done — a short checklist that both design and engineering sign off against before a ticket can close. Not two checklists that hand off to each other; one checklist that two disciplines own together.
The point of sharing it is subtle: it makes the visual criteria a precondition for closing, not a post-hoc review. Design stops reviewing screenshots after the fact and starts reviewing the built component as part of the definition of finished.
"Done" should be the same word for the person who built it and the person who designed it.
The checklist stayed deliberately short — long checklists get skimmed. Four items, each one binary:
Two of the four criteria are only checkable because of the token pipeline behind them — "no hard-coded values" and "matches Figma at the token level" are objective when design and code share one source of truth. A Definition of Done is only as strong as the systems that make its items verifiable rather than subjective.
The result was less dramatic than it sounds, which is the point: fewer reopened tickets, visual issues caught while context was still warm, and far fewer late-stage surprises in release reviews. The team spent less time arguing about whether something was done and more time deciding what to build next.