Design Handoffs: Build a Shared Verification System

A screen can reproduce an approved mock precisely and still violate the product decision. The copy may come from an older review. The service may reject a state the prototype treats as complete.

Calling the mock “final” does not resolve those disagreements. It only hides which answer engineering should trust.

At the build boundary, the design package becomes a release candidate. It identifies an accepted version of the product behaviour, the evidence that can verify it, and the people allowed to change it.

This article uses handoff for that controlled change of authority. It is not the meeting where a designer presents screens, and it is not the point where product and design disappear from implementation.

The handoff starts where authority changes

Before the boundary, the team is still exploring how the product should work. After it, engineering can make implementation decisions against an agreed baseline.

The broader work of bringing design and engineering together starts earlier and continues through build. The collaboration guide owns that operating model.

The handoff has a narrower job. It must answer three questions:

• Which version is eligible to build?
• Which decisions are settled, provisional, blocked, or deferred?
• Who may accept a difference between the baseline and the running product?

A 2009 grounded-theory study of interactive application designers analysed 282 artifacts from five sources. Flow, testing, and communication appeared among the reported design needs.

The authors described designs as boundary objects shared across roles. Their participants also proposed design-centric versioning and connected views as tool ideas, rather than as tested delivery interventions.

That evidence supports a modest claim: a screen is only one view of a cross-disciplinary decision. Treating the complete package as a release candidate is an editorial synthesis, not an industry standard.

One build needs several authoritative answers

No master file can carry every kind of product authority well. A service contract may own validation rules while a content record owns wording and a state model owns the meaning of pending work.

Use an authority map to show where each material answer lives:

Decision	Authoritative artifact	Version	Owner	Acceptance evidence
User intent and scope	Product decision record	Named baseline	Product	Scenario and non-goals
State behaviour	State model or prototype	Named baseline	Design and engineering	Running transition
Service rules	API or domain contract	Release or schema version	Engineering	Response and log evidence
Product copy	Content record	Approved revision	Content or product	Rendered real copy
Visual values	Token or component release	Package version	Design system owner	Implemented component

The map links to authoritative artifacts; it does not duplicate them. When a source changes, its version and affected acceptance evidence become visible.

The design-token guide explains how shared values become governed platform outputs. A handoff should cite the applicable output, not redefine token layers in a ticket.

The information-architecture guide owns how people find objects and recover from wrong turns.

A handoff names the accepted route and its verification evidence. It does not choose the product’s organising principle at the build boundary.

A design-science study with six automotive companies distinguished cross-team boundary objects from artifacts used inside one team. Its guidance favoured stable official versions, links, and deliberate release management.

That setting was large-scale automotive systems engineering. It offers a useful analogy for shared artifacts, not proof that the same practice improves digital product delivery.

Readiness has named states

“Ninety per cent ready” cannot tell engineering which ten per cent may change the product. Assign a state to each material decision instead.

• Accepted: the team can implement and verify the decision against named evidence.
• Provisional: implementation may proceed within a stated boundary while one answer remains open.
• Blocked: required work cannot proceed without a decision, dependency, or valid source.
• Deferred: the decision is outside this baseline and has no hidden implementation obligation.

A provisional item needs an owner, a resolution trigger, and a description of the work that remains safe. A deferred item needs an explicit exclusion so absence is not mistaken for an oversight.

The baseline is eligible when required decisions are accepted, no blocked item prevents the intended slice, and every provisional item has a bounded effect. Acceptance evidence and delta authority must also exist.

This is a decision rule, not a guarantee. A team can satisfy it and still learn that its assumptions, evidence, or implementation were wrong.

The baseline record should name its identifier, date, scope, exclusions, source versions, provisional items, and previous version. “Latest” is not an identifier when links and exports update at different times.

An industrial handover study published in 2025 examined acceptance checklists in one Swedish company. Their use depended on factors beyond the document itself.

Format, location, access, participating people, and prior involvement affected how the checklists functioned. The finding is a warning against treating completion of a form as readiness.

Write acceptance as observable behaviour

“Build according to the design” asks a reviewer to infer what matters. An acceptance contract states the behaviour that must be observable and the evidence that can answer whether it occurred.

For each material scenario, record:

• actor and context;
• applicability and preconditions;
• action or event;
• observable product and system state;
• guardrails that must remain true;
• evidence required for a decision.

The W3C ACT Rules Format provides a rigorous example from accessibility testing. It requires explicit applicability, expectations, assumptions, examples, versions, and defined outcomes.

Its outcomes include passed, failed, inapplicable, untested, and cantTell. Product teams can borrow that honesty when an acceptance question cannot yet be answered.

ACT is a web accessibility test-rule standard, not a general handoff method. A passed rule can also require further testing before an accessibility requirement is satisfied.

The micro-interaction guide owns the design of state changes. The handoff carries its approved interaction contract into implementation and verification.

A fictional dock-slot change

Dockline is a fictional warehouse scheduling product. The situation below illustrates the decision records; it reports no observed delivery or product result.

A dispatcher can move a booked dock appointment. The prototype currently displays confirmation as soon as the dispatcher submits a new time.

The carrier service may reject a change after its cutoff. Recipient notification completes through a separate service and may remain pending after the carrier has accepted the slot.

The authority map assigns the booking state to the carrier contract. The interaction model owns what the dispatcher sees, the content record owns the wording, and the token release owns visual values.

The baseline accepts three distinct states: change requested, carrier accepted, and recipient notified. Calendar export is deferred and explicitly excluded.

Notification fallback copy is provisional. A content designer owns it, and it must be resolved before the notification integration can pass acceptance.

One acceptance scenario reads as follows:

• Actor and context: a dispatcher viewing times in the warehouse time zone.
• Precondition: the booking is open and carrier cutoff status is available.
• Action: the dispatcher selects an offered slot and submits the change.
• Observable state: the product shows requested until the carrier confirms; it does not present notification as complete while that service is pending.
• Guardrails: the time zone remains visible, duplicate submission is unavailable, and status changes are conveyed without relying on colour alone.
• Evidence: a running vertical slice, the carrier response, the displayed state, and a manual keyboard and status-message review.

During implementation, engineering discovers that the carrier accepts only 30-minute slots. The baseline allowed arbitrary minutes, so the discovery changes product behaviour rather than implementation detail.

The team opens a delta. Product owns the effect on the scheduling promise; design owns the revised selection behaviour; engineering owns the service constraint and its evidence.

The accepted decision is to show service-provided slots. The baseline, prototype, state model, and acceptance scenario receive the same new version reference. The example ends there; no outcome is claimed.

When implementation changes the decision

A difference is not automatically a defect. It may be a better implementation, a newly discovered constraint, an invalid assumption, or a change to the product promise.

Record a material delta with:

• current baseline and affected decision;
• new constraint or evidence;
• consequence for the user, system, or operating model;
• viable options and their trade-offs;
• decision owner and disposition;
• artifacts, tests, and consumers that must change.

Engineering can choose technical details that preserve the accepted contract. A change to observable behaviour needs the authority named in the map. Local team titles should determine that owner, not a universal RACI.

Useful dispositions are to change the implementation, change the design, revise the contract, or accept a bounded exception. An exception needs an owner and a trigger that reopens it.

Silent divergence is the dangerous state. Design may continue to depict one promise while code, copy, analytics, and support procedures each encode another.

Review the running product against the contract

Visual comparison can find useful defects, but pixel identity is weak evidence of product behaviour. Review the states and guardrails that made the baseline eligible.

Exercise real content, permissions, latency, failure, recovery, responsive layouts, focus order, keyboard access, status communication, and instrumentation where they affect the scenario.

The GOV.UK Design System offers one public example of a demanding acceptance gate. Its team asks for representative user research, including disabled users, and testing across browsers, assistive technologies, and devices.

It also discloses the contexts in which a component has been tested. That is an organisational contribution policy, not causal evidence or a universal release standard.

Automated checks can support this review, but they do not prove accessibility or product correctness. Record what was tested manually, what remains untested, and what the evidence cannot determine.

Each material difference should end with a disposition. The reviewer can fix code, update the accepted design, revise the contract, or record a bounded exception. Leaving the versions inconsistent is not a disposition.

Audit the unanswered decisions

Meeting count and document completion say little about whether the boundary works. Inspect the places where decisions remain implicit or inconsistent.

Useful operating signals include:

• build questions whose answer changes observable behaviour;
• work implemented against a stale baseline;
• material deltas without an owner or disposition;
• failed, untested, or indeterminate acceptance scenarios;
• exceptions that have passed their reopen trigger;
• authoritative artifacts that disagree on the accepted version.

These are diagnostic signals, not evidence that the handoff improved delivery. A team seeking that claim must define and measure a separate outcome, then allow for the possibility that the operating model had no effect.

The handoff is doing its job when the team can identify what it agreed to build, what remains uncertain, what the running product proves, and who can accept a change. That is a shared verification system.

Sources

• Grigoreanu et al., What Designers Want: Needs of Interactive Application Designers — IEEE VL/HCC 2009 grounded-theory study of 282 artifacts. Validation was limited to Microsoft employees across 13 product teams.
• Wohlrab et al., Boundary Objects and their Use in Agile Systems Engineering — accepted 2019 journal article using design science with 53 practitioners from six automotive companies and 31 valid questionnaire responses. Cross-domain transfer was not tested.
• Wlazlak and Säfsten, Development of a Boundary Object Assessment Framework — 2025 research article developed with five Swedish industrial partners. Its handover case used 17 interviews, two steering-manager interviews, and a 21-person workshop; the framework was not a causal trial.
• W3C, Accessibility Conformance Testing Rules Format 1.1 — W3C Recommendation dated 5 February 2026. It specifies accessibility test-rule structure rather than a general product handoff method.
• GOV.UK Design System contribution criteria — an official organisational review policy. It reports no participant sample or comparative evaluation of the policy itself.

Read next

• Design and Engineering Collaboration: Keep Intent Executable
• Design Tokens as a Versioned Product Interface
• Information Architecture Patterns: Design for Findability, Not Menus
• Micro-Interactions: Design the State Change
• Design Critiques: Test the Decision, Not the Designer