Design

Design handoff that does not lose intent

Handoff fails when it is a moment rather than a collaboration. The fix is mostly about when engineers are involved.

Key takeaways

  • Involve engineers during design, not at the end.
  • Undesigned states are where inconsistency enters.
  • Hand over components with properties, not finished pages.
  • Review the built result together and feed differences back.

Involve engineers before the design is finished

The most common handoff failure is designs arriving complete, with technical constraints discovered afterwards. By then, changing them costs rework and goodwill.

Bringing an engineer into design review early surfaces feasibility, performance and data-shape constraints while they are cheap to accommodate.

Specify the states, not just the screen

  • Loading — skeleton, spinner or progressive content.
  • Empty — first use, and after filtering to nothing.
  • Error — per field and at page level.
  • Permission-denied and partial-access states.
  • Long content, long names, missing images.

Undesigned states get improvised inconsistently. Specifying them is the single highest-return handoff activity.

Components rather than pages

Handing over pages invites bespoke implementation. Handing over components with defined properties and states produces reusable code and consistent results.

Where a design system exists, the handoff is mostly which components to use and what is new — a much smaller conversation.

Review the built result together

Design QA against the implementation catches spacing, state and interaction differences while they are quick to fix. Doing it together rather than as a defect list is faster and less adversarial.

It also feeds back into the system: differences that recur usually indicate a missing component or an ambiguous specification.

Documenting behaviour, not just appearance

Static designs communicate appearance well and behaviour poorly, and behaviour is where most implementation questions arise.

Specify what happens on interaction: does the button disable while submitting, does the list reorder immediately or after confirmation, what happens if the action fails halfway. These decisions get made by whoever implements them if they are not specified.

A short written note beside each interactive component is usually enough. It is faster than a prototype and answers the questions that actually get asked.


Frequently asked questions

Most modern design tools provide inspection and specifications. The tool matters far less than whether designers and engineers talk during the work.

Detailed on behaviour, states and edge cases; less so on measurements if a token system covers spacing and type.

The designer checks intent, the engineer checks implementation, and both look together. Making it solely one side's job produces either nitpicking or drift.

Working on this?

A conversation with our team, no charge and no obligation.

Book a conversation