You define the problem. You run the research, make the calls, build the prototype, write the requirements. You hand it off.
Then the thing ships — and it isn’t quite what you defined.
Not because anyone did anything wrong. Scope moved. A card got split. A tradeoff got made in a sprint planning session you weren’t in. By the time you see it in QA, the decision that changed the experience is three weeks old and nobody remembers it was a decision.
If you’re a senior designer, you know this feeling. I want to be precise about what it is, because I spent a long time treating it as a people problem when it’s a structural one.
It has a name, and it isn’t yours
Marty Cagan draws a line between empowered product teams and feature teams. An empowered team gets the business context and the autonomy to find the solution. A feature team gets handed a roadmap, told to build it, and measured on delivery. His framing is worth reading directly. He’s been making the case for years and he makes it better than I will.
He’s right about the diagnosis. When design defines but doesn’t control delivery, that’s not a dysfunction unique to your company. It’s a named operating model, and a lot of us work inside one.
His remedy is where I get off. Change the operating model, he says — and that’s a leadership-level move. Most designers reading this can’t order that change. You can advocate for it, and you should. But on Tuesday you still have a handoff to write, inside the org you actually have.
So the question I got interested in isn’t how do I get authority back. It’s narrower and more useful: how do I make intent survive a process I don’t control?
Four things that travel
These are what I’ve landed on. They’re cheap, they don’t need anyone’s permission, and they work whether or not the org ever changes shape.
1. Write acceptance criteria that can fail.
For every criterion, name the observation that would prove it false, before anything gets built. Not “the card resizes correctly.” Instead: “at 672px the tag drops to three columns; if it holds at four, this is wrong.”
A criterion that can’t fail isn’t a criterion, it’s a wish. And the version with a falsification in it survives being read by someone who wasn’t in the room, which is the whole point.
2. Label what’s reversible and what’s breaking, up front.
When scope moves, and it will, the team needs to know which changes are a policy call they can revisit next quarter and which ones lock in a data shape they’ll be living with for two years.
Nobody can make that call from the card. You can make it from the design, before anyone’s under delivery pressure. In practice it’s one extra line per requirement: reversible or breaking, and one clause on why. About twenty minutes of work, and it’s the single highest-leverage thing I’ve found.
3. Decision records, not decks.
A deck communicates a decision to the people in the room. A decision record communicates it to the person who inherits it in April.
The record is short. What we chose, what we rejected, and the fact that killed the alternative. Three lines, dated, in the same place the requirements live so nobody has to go looking. Most of the drift I’ve watched wasn’t disagreement. It was a decision getting re-made by someone who never knew the first one happened, or why.
4. Gates that fail loudly.
If the check can’t fail, it isn’t a check. So for every claim that matters, the handoff carries the command that proves it and what its output looks like when it’s wrong. “Tested at 672px” is a sentence. A screenshot at 672px next to a screenshot at 673px is a gate. I’ve written a whole piece about what this looks like in practice, because it turns out to be the thing that generalizes furthest.
What this doesn’t do
It doesn’t get you authority. I want to be straight about that, because there’s a version of this advice that promises influence and delivers paperwork.
You will still get overruled. Things will still ship differently than you drew them. What changes is that the reasoning is available when someone goes looking, and the expensive mistakes, the ones that lock in a shape, get flagged while they’re still cheap.
That’s a smaller claim than “own the outcome.” It’s also the one I can actually deliver on.
The part I didn’t expect
Doing this made me sharper at the job.
Writing a falsification forces you to know what you actually believe will happen. Labeling reversible-versus-breaking forces you to understand the system underneath the screen. Both are design work. They don’t look like it, because the output is prose instead of pixels, but the thinking is the same thinking.
And it made me bolder, not more careful. Once the falsification is written, I know exactly what a wrong bet looks like, so I can make the bet. I’d rather build the thing, test it against the model and the product, and find out. The record is what lets me do that without anyone else paying for it.
The handoff was never the enemy. Intent that can’t survive one, was.