Product discovery and UX design: a buyer's guide / Own the result
Design handoff without losing the product
Every team has lived this: the design was strong, the build was competent, and the released product is somehow neither. The file says one thing, production says another, and no single decision made it so. Handoff failure builds up over time: fifty small gaps in the design, each filled by whoever was closest, under deadline, without context. The fix is in how the work is organised: design the states designers do not show in a portfolio, put engineers in the review before the file is finished, and make matching the design part of the definition of done.
Published August 8, 2026. Editorial.
Key takeaways
- Products move away from the design through dozens of small unspecified moments. The empty, loading, error, and overflow states are where it starts.
- A design is finished when an engineer can build it without inventing anything.
- Engineers belong in design reviews while the design is still cheap to change. They know which details cost hours and which cost weeks.
- Name accessibility up front (WCAG 2.2), and check the released screens against the design as part of done, or the differences become permanent.
The phrase "design handoff" describes the cause of the failure. A handoff implies a moment: the file is finished, it changes hands, design is done and building begins. Products built through that moment move away from the design, reliably, because a static file cannot answer the hundreds of questions a build asks, and someone answers them anyway, one Slack message and one rushed decision at a time.
We build products with designers and engineers on one team, so we see the handoff problem from both sides, including on projects that arrive after a handoff elsewhere has gone wrong. The patterns are consistent enough to list.
How products actually move away from the design
Nobody decides to diverge from the design. The differences build up on their own.
The design covered normal use: a populated dashboard, a reasonable user name, data that fits its container. The build meets everything else: the brand-new account with nothing in it, the fifty-character name, the table with ten thousand rows, the network that fails mid-save. Each unspecified moment gets resolved by whoever hits it, usually an engineer at speed, whose job at that moment is to release the feature. The individual resolutions are defensible. Their accumulation is a product that no longer matches anyone's intent.
Then there is the less visible category: spacing approximated, a near-enough gray substituted, a hover state skipped, an animation dropped because the deadline arrived first. None worth a meeting. Together they are why the released product feels cheaper than the file, without anyone being able to say why.
A design is finished when nothing is left to invent
The standard that fixes the first category is simple to state: a flow is designed when an engineer can build it without inventing anything. That means every screen comes with its less attractive related states: the empty state, the loading state, the error state, the permission-denied state, the overflow case. It means interactive behavior is specified: what exactly happens on failure, what is disabled while saving, where focus goes when the dialog closes.
This sounds like more design work, and it is, which is why it gets skipped when design is bought by the screen. But the work is not optional; the only choice is who does it. Either a designer does it with context and intent, or an engineer does it at midnight with a deadline. The states get designed either way. The technical spec discipline is the same idea from the engineering side: reduce uncertainty where it is cheap to reduce, before it becomes expensive.
Sometimes a single one of these unusual-case decisions decides how the product is used. In document extraction, the design decision that changes how people use the product is exactly the kind that is lost in a bad handoff: showing the model's confidence score on each extracted field, so high-confidence results are processed quickly and uncertain ones get checked by a person. That is a state design, and it is the difference between users re-checking everything and users trusting the system.
Put engineers in the review before the file is finished
The cheapest fix in the whole handoff problem is scheduling: engineers review the design while it is still a draft. Their job is to answer the questions only they can: which of these is a component we already have, which detail takes an hour and which takes two weeks, what does the API actually return here, what happens on a slow connection.
Designs reviewed this way get built faster and closer to intent, because the expensive surprises appear while changing the plan only takes a conversation. Designs that skip this review get cut down during the build instead, by one side, under deadline, which is the worst possible time and personnel for design decisions. When the same team designs and builds, as ours does in full product build engagements, this review is just how work happens; when design and engineering are separate organizations, it has to be scheduled deliberately, and it is worth being deliberate about. If you are vetting a design partner, ask them to show you how engineering feedback changed a design mid-engagement; the test is similar to the others in how to choose a product design agency.
Name accessibility before the build
Accessibility is the clearest example of a quality that cannot be handed off, because it is decided in both places: contrast, focus order, and labels in the design; semantics, keyboard behavior, and announcements in the build. If neither side owns it explicitly, each assumes the other has it, and the product is released inaccessible, while both sides believe they did their job.
The fix is one sentence in the working agreement: this product meets WCAG 2.2, the W3C's current recommendation, and both design review and build QA check against it. Designed in from the start, contrast and focus states and labels are close to free. Retrofitted, they are a project with a backlog of their own. A design partner who delivers unreadable contrast or icon-only controls with no labels is delivering rework that only looks finished.
Make matching the design part of done
The last structural fix is the least glamorous: someone checks the released screens against the design, state by state, before the work is called finished. Design QA belongs in the definition of done exactly as functional QA does, and for the same reason: quality that is not checked gets worse, slowly and permanently. The mechanics are lightweight, a review pass by the designer on the built feature, differences either fixed or explicitly accepted, and the discipline is the same one that makes code review work: a second person checking, against a stated standard, before release.
Teams sometimes resist this as designers controlling engineers. Run well, it stops fifty unspoken compromises from adding up to a product nobody chose, and it protects engineers from owning design decisions they never wanted to make.
The whole subject comes down to one sentence: the gap between design and build is an ownership problem, and it closes when one team, or two teams working like one, owns the product all the way to production.
Common questions
Why does the released product look different from the design?
Because the design specified normal use and the build met everything else: empty states, errors, overflow, slow networks. Each unspecified moment got resolved by an engineer under deadline, and the accumulation of those small inventions is the difference. The fix comes earlier: design the full set of states, review with engineers before the file is final, and check released screens against the design as part of done.
What should a design handoff include?
Every state of every screen (empty, loading, error, permission-denied, overflow), specified interactive behavior (what happens on failure, what disables while saving, where focus goes), the components and tokens used, and the accessibility expectations, ideally WCAG 2.2 named explicitly. The working test: an engineer should be able to build the flow without inventing anything. If they must invent, the design is not finished.
How do you keep design and engineering aligned during a build?
Three mechanisms: engineers review designs while they are drafts, so cost surprises appear while change is cheap; questions during the build go to the designer instead of being improvised; and the designer reviews built screens against the design before the work is called done. Teams that design and build as one group get these by default, which is a real argument for that model.
Whose job is accessibility, design or engineering?
Both, and that is exactly why it gets dropped: each side assumes the other owns it. Contrast, focus order, and labeling are design decisions; semantics, keyboard behavior, and announcements are build decisions. Name the standard once for both sides, WCAG 2.2 is the current W3C recommendation, and check it in design review and build QA. Designed in, accessibility is nearly free; retrofitted, it is a project of its own.
What does design QA involve, and who does it?
The designer reviews the released screens against the original design, state by state, before the work is called finished, and either fixes differences or explicitly accepts them. It belongs in the definition of done for the same reason functional QA does: quality that is never checked gets worse, slowly and permanently. Run well, it protects engineers from silently owning design decisions they never intended to make.
What does it cost a product when design handoff goes wrong?
The cost shows up as a released product that feels cheaper than the file it came from, without anyone able to say exactly why: approximated spacing, a near-enough gray, a dropped hover state, an animation cut for the deadline. None of these individually justifies a meeting, but their accumulation is a product that no longer matches what anyone actually intended, and fixing it later costs far more than designing the states correctly the first time.
What is the definition of done for a design handoff?
A flow is done when an engineer can build it without inventing anything: every state is specified, including empty, loading, error, permission-denied, and overflow, interactive behavior is defined for failures and disabled states, and the accessibility standard is named. It also requires the released screens to be checked against the design afterward, because a specification that is never verified against what was actually released still allows differences to build up.
Is a smoother design handoff safer with design and engineering on one team?
Yes, because of how the work is organised. When the same team designs and builds, engineers review designs while they are still drafts, the cheap surprises appear before they are expensive, and checking the released product against the design becomes part of daily work rather than a separate step someone has to remember. When design and engineering sit in different organizations, all three of those checks have to be scheduled deliberately or they stop happening without anyone noticing.
Related reading
What a good technical spec looks like when a model writes the code
The old advice was to keep specs short and stop where writing the code is faster. That advice assumed a person was reading it. When a model writes the code, the cost of an unanswered question changes, and so does the right length of a spec.
What good code review looks like when nobody wrote the code
With human code, the author is the first check and review is the second. With generated code, review is the only check. That one change alters most of what a reviewer should be doing.