Most project pain lives in the gap between a beautiful Figma file and the thing that actually ships. Designers hand over static screens, developers interpret intent, and the work drifts. By launch nobody quite recognises the original idea, and everybody has an opinion about whose fault that is.
We do not treat design and development as separate phases. They are two halves of the same build, and the bridge between them is structure: a shared vocabulary, agreed before the first screen is drawn, that the design file and the codebase are both held to.
One system, shared early
The fix starts long before handover. We design in systems, not screens: spacing steps, a typographic scale, colour roles rather than colour names, and named components with defined states. When the design file and the codebase share one vocabulary, translation stops being interpretation. A c-card in Figma is a c-card in the build, with the same padding, the same states and the same rules.
That shared language does two practical things. It removes the “is this 22px or 24px?” class of question entirely, and it means a decision made once propagates everywhere instead of being re-made, slightly differently, on every screen.
The naming matters more than it looks. Tokens named for their role, such as surface, ink, accent and muted, survive a brand refresh. Tokens named for their value, such as grey-3 or orange, do not, because the day the orange changes you either rename fifty references or live with a name that lies. The same applies to spacing. A scale of steps both sides count in is worth more than a set of numbers that happen to agree today.
What a dev-ready design file actually contains
A dev-ready file is not a tidy file. Tidy is table stakes. Dev-ready means the file already answers the questions a developer would otherwise have to stop and ask:
- Components with variants that match real behaviour, so one component covers every state. Default, hover, focus, active, disabled, loading, error. If the build has to support it, the file has to show it.
- Breakpoints that reflect how the layout actually reflows, with the narrow case drawn as well as the wide one. A single desktop artboard is a guess about mobile, and the guess is usually wrong in the places that cost most: long headlines, three-column grids, tables.
- Annotations where intent is not obvious. What happens on an empty list, on a slow response, on a validation failure, on the twelfth item in a menu designed for six.
- Real content, or content at its worst. Placeholder text set at the length you wish the client would write is the most reliable source of post-launch layout bugs there is.
- Colour pairs already checked for contrast. Contrast is a design decision, made before anyone has to remediate it. Checking it in the file costs a minute. Finding it in an accessibility audit costs a rebuild of everything the failing colour touches.
What a design-aware build actually does
On the other side, a design-aware build respects the system instead of approximating it. Tokens go into the CSS as custom properties rather than hard-coded values, so the scale stays single-source. Components are built once and reused, so consistency is the default rather than a matter of anyone’s discipline. Layout uses the same spacing steps the design does, which means a section can be rebuilt from the file without measuring anything.
It also means the build says no in the right places. If a screen introduces a fifth button style, the right response is a conversation about why. Systems decay one exception at a time, and every exception is reasonable on its own.
Where drift creeps back in
Even with a system in place, three things pull the two sides apart, and all three are predictable.
Late content. The copy arrives after the layout is built, it is longer than the design assumed, and someone quietly drops a font size to make it fit. The fix is to design against real or realistic copy, and to agree what happens when text overflows before it does.
One-off requests. A campaign needs a slightly different card. It ships as a special case, it gets copied, and six months later nobody can say which card is the real one. The fix is to decide whether the request is a new variant of an existing component or genuinely a new component, and to put it into the system either way.
The last ten per cent. Feedback at the end of a project tends to be pixel-level, which is exactly the level at which a system is easiest to break. The fix is to route late feedback through the system: change the token, and every instance follows.
How the handover runs in practice
There is no single handover moment, which is the point. The build starts while the design is still being made, on the parts that are settled: the tokens, the type scale, the page shell, the components every page needs. Design continues on the parts that are not.
Three habits keep that honest. We review the built component against the file rather than against a screenshot of the file, because a screenshot hides states. We keep one running list of open questions visible to both sides, rather than a thread per question in three different places. And we walk the built pages at the breakpoints that were drawn, on a real phone, before anyone calls anything done.
Where a client’s own team will maintain the site afterwards, the same discipline decides what gets handed over: the components, the tokens, plain-language notes on when to use which, and a page inside the build that shows every component in every state. That page is the thing that keeps the system alive after we step back from it.
Why it matters commercially
Structured workflows are not an aesthetic preference. They are how projects stay on budget. Fewer revision rounds, no rebuild of drifting screens, and a handover the client’s own team can work with later. When design understands the constraints and development understands the intent, the work ships faster, and it ships as designed.
It also changes what the second project costs. A business that owns a system adds a page, a campaign or a product area by assembling parts that already exist and are already tested. A business that owns a set of screens starts again, and pays again for decisions it has already made once. That compounding is most obvious on web and mobile app projects, where the same components have to survive two platforms and several releases.
