The Only Design That Exists Is the One That Shipped

Open the file. Now open the product. Compare.

The spacing is different. Two states are missing. The error message says something you never wrote. The empty screen you spent a day on didn't get built at all, because it wasn't in the ticket.

This gap is not a moral failing of engineers, and it isn't proof that you should have specified harder. It's the normal outcome of design being treated as a document that gets thrown over a wall. And closing it is a skill as real as anything in the craft chapters — arguably the one that separates designers whose work reaches people from designers with excellent portfolios.

The file isn't the product. Only what shipped exists.

Engineers aren't executors

The most expensive mistake a designer can make is to design in isolation and then present.

Here's the shape of it: you spend a week on a solution, present it, and an engineer says quietly that this particular part means restructuring how data is stored — about three months. Then they add that a nearly identical version, with one interaction changed, would take two days.

Nobody did anything wrong, and a week is gone. Ask before you design:

"What's cheap here and what's expensive?" The answer routinely reshapes a design for free. Certain things — real-time updates, cross-device sync, undo across sessions, arbitrary sorting on large data — carry costs invisible from the design side.

"What already exists that I could use?" Half of what you're about to invent may already be in the codebase.

"What are you worried about in this?" Engineers have usually spotted the edge case you haven't. That question buys you their whole mental model of the system in one answer.

Bringing an engineer into a rough sketch feels like showing unfinished work. It is showing unfinished work — that's the point, and the prototyping article explains why rough gets honest answers.

Handoff isn't a throw

What a build actually needs from you goes well beyond a screen with measurements:

Every state, not just the ideal one — the five from the flows article.
Behaviour, not just appearance: what's focusable, what happens on error, what's saved when, what's optimistic.
Responsive rules: what wraps, what truncates, what stacks, and at which point.
Content rules: what happens with a forty-character name, a zero, a negative, a hundred rows.
The words: exact strings, including errors — otherwise someone types a placeholder and it ships.

Two habits matter more than any spec format. Be available during the build — most questions are thirty seconds of conversation and three days of wrong guess. And review the built thing, on real devices, before it goes out. Design QA is where the last five per cent of quality lives, and it's the step designers most often skip because the file already looks finished.

Product, priorities and money

A designer who can't hold a business conversation gets treated as a decorator, and then complains about being treated as a decorator.

The vocabulary is not hard. Every product decision is bounded by money, time, legal exposure and support cost. A flow that reduces support tickets is worth real money; a two-week polish that changes nothing measurable is a cost. Learn to say which one you're proposing.

Two moves that change how you're heard:

Bring the problem, not the request. "Six of eight users lost their reference number and two called support" starts a different conversation than "I'd like to redesign the checkout."

State the trade you're proposing. "This version is a week longer and removes the step where 40% drop out." Now the decision belongs to the room, framed in the room's terms, and you're a participant rather than a supplier.

Constraints are the material

New designers experience constraints as the enemy: the legacy system, the brand, the deadline, the legal text that must appear, the performance budget.

But the layout article already made this argument at small scale — constraints delete the part that was never design. At project scale it's the same. An unconstrained brief is not freedom; it's a search space with no edges, which is why "design whatever you like" briefs produce worse work than tight ones.

The professional move is to name constraints explicitly at the start, distinguish the fixed ones from the assumed ones, and test the assumed ones. Half of what a team believes is immovable turns out to be a decision someone made in 2019 that nobody has questioned since.

Shipped beats perfect, except where it doesn't

A design that reaches users at 80% beats a design that reaches nobody at 100%. Real deadlines exist, and refusing to cut scope is not integrity, it's a way of having no influence.

But you must know which 20% is not negotiable. A rough sorting:

Negotiable: polish, animation, the third-priority state, the perfect icon, edge cases affecting a tiny minority this month.

Not negotiable: anything that loses someone's data, anything that misleads about money, anything that excludes people entirely (keyboard access, contrast, labels), anything that damages trust irreversibly.

The distinction to hold in the meeting is between "unpolished" and "broken." The first ships and gets improved. The second shouldn't ship, and saying so clearly, once, with a reason, is part of the job.

Working alone

If you're building your own product, you hold all three roles — and the risk isn't conflict, it's the absence of it. Nobody asks "what's expensive here?", nobody says "that's not what users said," nobody catches the fourth button style.

Three substitutes that work:

Write the brief to yourself. The five questions from the first article, in a file, before you open anything. It's the argument you'd have had with a product manager, held on paper.

Timebox against your own perfectionism. Solo work has no external deadline, so polish expands to fill the project. Decide the box before you start.

Get one outside pair of eyes. One person, once a week, twenty minutes. The specific value isn't their expertise — it's that they don't have your curse of knowledge.

Design debt is real debt

Teams track technical debt and rarely track design debt, which accumulates identically: the inconsistent pattern shipped under deadline, the flow that was never redesigned after the feature changed, the empty state still saying something from two years ago.

Write it down where the team writes things down. Give each item a cost in the terms above — support tickets, drop-off, confusion — and pay it back in slices alongside features. Design debt that lives only in a designer's private irritation never gets paid.

In practice

Show a sketch to an engineer this week. Before it's finished. Ask what's cheap and what's expensive.

Add the missing states to your next handoff. Empty, loading, partial, error — with real strings.

Review one shipped screen against its design. List the differences and ask why each happened. The answers tell you what your handoff is missing.

Reframe one request as a problem. Take something you want to build and rewrite it as the user problem plus the evidence.

Sort your current scope cuts into unpolished and broken. Defend only the second list, and defend it once, clearly.

Start a design debt list. Five items, each with its cost. Put it where the team can see it.

Check yourself

Close the article and answer in your own words:

Why is the design in your file not the design that exists?
What three questions should you ask an engineer before designing?
What does a build actually need from you beyond a measured screen?
What's the difference between bringing a request and bringing a problem?
Why is an unconstrained brief usually worse than a constrained one?
Where's the line between "unpolished" and "broken," and why does it matter in a deadline meeting?
What are the three substitutes for a team when you work alone?

In short

Only the shipped design exists. The gap between file and product is where a designer's real influence shows.
Talk to engineers before designing: what's cheap, what's expensive, what already exists, what worries them.
Handoff includes every state, behaviour, responsive and content rules, and the exact words — plus availability during the build and design QA after.
Speak in outcomes and trade-offs; bring the problem and the evidence, not the request.
Constraints reduce the search space and improve work. Name them, and test which "fixed" ones are actually assumptions.
Shipped at 80% beats perfect and unshipped — but know the non-negotiable fifth: data loss, misleading about money, exclusion, broken trust.
Working alone, replace the missing team with a written brief, a timebox and one outside pair of eyes.
Design debt accrues like technical debt; write it down with a cost or it never gets paid.