The short answer
Good design fails in delivery not because of advocacy failure or stakeholder resistance, but because design decisions are made in one context and implemented in another, and the reasoning that informed those decisions does not travel between the two. What survives into the delivery context is the artefact: the screen, the specification, the prototype. The reasoning behind it is absent. When constraints emerge during build — and they always do — the people responding to those constraints are working from what they can see, not from what they cannot see. That is a structural problem, and it requires a structural response.
The pattern most designers have experienced
A design that is well-researched, well-reasoned, and well-received in review can still emerge from delivery looking, behaving, and functioning differently from what was intended. This experience is common enough that most practitioners have a version of it in their professional history.
It tends to be attributed to a failure of advocacy; the designer did not fight hard enough for their decisions. It can also be attributed to stakeholder resistance; someone with authority overrode the design for reasons unrelated to user need. It can also be linked to development constraints; the technical implementation couldn’t support what was designed. These are real factors, but they are also symptoms of something more fundamental.
The structural problem: reasoning doesn’t travel with the artefact
Design decisions are made in a context where the reasoning is available. The designer who made the decision can explain why a particular interaction was chosen, what user behaviour it was responding to, which aspects of the design are essential and which are flexible. In a design review, that reasoning is present, and it can be discussed, challenged, and revised.
In the delivery context, the reasoning is usually absent. What the delivery team has is the artefact: the screen in Figma, the specification document, the prototype. The artefact shows what the design is, but it does not show why it is that way. It does not distinguish between the aspects of the design that are structurally essential — that exist because removing them would break something important for the user — and the aspects that are considered preferences which could be adjusted without significant consequence.
When constraints emerge during build — and constraints always emerge, because build is where reality imposes itself on design — the team making decisions about how to respond is working from the artefact. They do not have access to the reasoning. They make pragmatic calls based on what they can see, and those calls are often entirely reasonable given the information they have. They are also often wrong given the information they do not have.
Where the designer is when it matters most
The designer is rarely present when these calls are made during build. They may be present in a daily standup where the constraint is mentioned briefly. They may hear about the decision in a sprint review. They may discover it in a release. By the time they know it has happened, the decision has been implemented, the sprint has closed, and reversing it requires effort that nobody has budgeted for and that now competes with the next sprint’s work.
This is not a failure of communication in the ordinary sense. The designer communicated the design, the documentation was clear, and the handover was complete. The problem is not that the delivery team lacked the artefact — it is that the artefact alone was insufficient to make the right call when an unexpected situation arose.
Better presentations will not solve this, nor will clearer documentation fully solve it either. What is needed is for the reasoning behind load-bearing design decisions to be embedded in the work in a form that the delivery team can consult when the designer is not present and a decision needs to be made.
What load-bearing means
Not every aspect of a design is equally consequential. Some decisions are load-bearing — they exist because they address a specific user need, resolve a known behaviour pattern, or prevent a predictable failure. Removing or changing them would produce a service that fails in ways the design was specifically trying to prevent.
Other decisions are considered preferences; decisions made because they were the best available option at the time, but not structurally essential. Adjusting them under constraint is a reasonable trade-off, whereas adjusting a load-bearing decision is not.
The delivery team cannot make that distinction from the artefact alone. Making it requires knowing why the decision was made, what the decision was responding to, and what would break if it changed. That reasoning needs to be available in a form the team can access quickly, in the moment, without the designer needing to be present to explain it.
What a structural response looks like
Addressing this structurally means treating the reasoning behind design decisions as a deliverable, not as context that lives in the designer’s head or in a presentation that was given once.
In practice this means annotating designs with decision rationale rather than just specification: not just ‘this button is here’ but ‘this button is here because users who reached this point in testing consistently missed the action when it was positioned elsewhere, and moving it here reduced hesitation significantly.’ That annotation travels with the design into delivery.
It also means being explicit about which decisions are load-bearing and which are flexible — and communicating that distinction directly to the people who will be making build-time calls. A developer who knows that a particular interaction pattern is essential because it addresses a specific user behaviour will make different decisions when a constraint threatens it than one who treats all design decisions as equally negotiable.
The designer who is not present when a constraint emerges but whose reasoning is available in the work has more influence over the outcome than the designer who is not present and whose reasoning is not.
Instead of asking how to communicate your design decisions more clearly, ask whether the people making implementation decisions in your absence have what they need to make them well.
Frequently asked questions
Why does good design get changed during development?
Good design gets changed during development because constraints emerge during build that weren’t visible during design, and the people responding to those constraints are working from the design artefact rather than the reasoning behind it. Without the reasoning, they cannot distinguish between decisions that are structurally essential and decisions that are flexible. They make pragmatic calls based on what they can see, which is often correct given their information and wrong given what they don’t have.
How do you protect design decisions during delivery?
Protecting design decisions during delivery requires embedding the reasoning behind those decisions in the work itself — not just specifying what the design is, but documenting why it is that way, which aspects are load-bearing and which are flexible, and what would break if a specific decision were changed. This reasoning needs to be accessible to the delivery team in the moment when constraints arise, without requiring the designer to be present to explain it.
What is design intent and how do you preserve it in development?
Design intent is the reasoning behind a design decision — the user need it addresses, the behaviour it responds to, or the failure it prevents. Preserving it in development means making that reasoning explicit and available in the form the delivery team uses: annotations in design files, rationale in specifications, and direct communication with developers about which decisions are essential and which are adjustable. Intent that lives only in the designer’s head is intent that is lost when the designer leaves the room.
Is design handover a communication problem or a structural problem?
It is primarily structural. Better presentations and clearer documentation help at the margins, but the core problem is that design reasoning does not travel between the design context and the delivery context in a form that the delivery team can use when unexpected situations arise. Solving it requires treating reasoning as a deliverable — something that is embedded in the work rather than communicated once and expected to persist.