Moss Studio
All entries

Design that survives the handoff

The work does not end at approval. It ends when someone who was not in the room ships it correctly.

Published
January 27, 2026
Reading time
5 min read
Topics
Design Systems, Product, Process
Written by
Moss Studio
Design that survives the handoff

Every studio has seen it: a launch that looks nothing like the file that was signed off. Not because anyone was careless, but because the design described a happy path and production is made almost entirely of everything else.

Approval is the middle of the project

A design file is a proposal. It becomes a product when an engineer implements it against real data, in a real browser, under a real deadline. The gap between those two states is where quality is lost, and it is almost never lost to a lack of skill.

It is lost to unanswered questions. What happens when this name is sixty characters long? What does this list look like empty? What is the focus order? Which of these two elements wins when both are visible on a narrow screen?

Design the states, not the screens

The single highest-return change a design team can make is to stop delivering screens and start delivering states. For every component:

  • Empty — before there is any data, which is what every new user sees first.
  • Loading — including the slow case, not just the spinner.
  • Error — with real copy, written by someone who has read the failure modes.
  • Overflow — the longest plausible string, not the one that fits.
  • Focus — visible, ordered, and tested with a keyboard rather than assumed.

A component delivered with those five is implementable without a single clarifying message. One delivered without them is a negotiation.

Specify in the units the code uses

Handoff friction is often just a translation problem. If the system is built on a spacing scale, the spec should name steps on that scale rather than pixel values that happen to match this week. If colour has semantic roles, the spec names the role — surface, line, muted — not the hex.

This sounds pedantic until the first theme change, when every hardcoded value has to be found by hand and every semantic one updates itself.

A specification that has to be interpreted will be interpreted differently by each person who reads it.

Sit in the build

We stay in the repository through implementation. Not to write all of it, necessarily, but to be present when the first real content lands and the layout behaves in a way nobody predicted.

The alternative — reviewing a staging link two weeks later — turns every finding into rework with a cost attached, which is how design feedback ends up negotiated away.

What good handoff feels like

Nobody notices it. There is no launch-week scramble, no list of thirty visual bugs, no meeting about whether the padding was meant to be like that. The team ships the tenth screen faster than the first, because by then they are assembling rather than deciding.

That is the whole goal of a system: to move the decisions to the front, once, so that everything after it is execution.

Next step

Let’s build something worth keeping

Tell us where the brand is today and where it needs to go. We’ll come back with a route, a timeline and a number.

Where we work

Brooklyn — United States

Lisbon — Portugal

Osaka — Japan

Booking from

Q1 2027