Handover is where design intent goes to die. The gap between what a designer built in Figma and what ends up in production is usually not a skills problem — it’s a communication problem. The developer didn’t have enough information to make the right call, so they made a reasonable one that wasn’t quite right.
Here’s the handover process I’ve refined to close that gap as much as possible.
Schema alignment
Before designing a complex flow — especially anything involving product data, user accounts, or dynamic content — I spend time with the API schema.
Understanding the data structure upfront means the design reflects what’s actually possible. Field names, data types, optional versus required fields, edge cases in the data — all of it informs design decisions. A component designed without knowing the schema will almost certainly require rework when it hits development.
The other benefit is credibility. Walking into a handover conversation with working knowledge of the schema changes the dynamic. Developers don’t need to explain the constraints — they can focus on implementation. That’s a faster, more productive conversation.
Pixel-perfect user story journeys
For complex flows, I prototype the complete user story in Figma — not just the happy path, but every state a user might encounter. This means every interaction state (hover, focus, active, disabled), every data state (loading, empty, error, populated), and every edge case in the flow.
The prototype is built to be pixel perfect against the design system — real components, real tokens, real responsive behaviour via variable modes. A developer walking through it should be able to implement directly from what they’re seeing without making design decisions themselves.
This is where the variable systems pay off significantly. Switching a product card to a different plan mode, demonstrating the responsive layout at different breakpoints, showing the light and dark variants — all of it is available in a single frame without parallel maintenance overhead.
Showing state through documentation
Every component handed over includes explicit state documentation. This isn’t just a screenshot of the default state — it’s a systematic walkthrough of every state the component can be in.
For a form field this means: default, focus, filled, error, disabled, read-only. For a product card it means: loading skeleton, populated, out of stock, promotional. For a modal it means: entry animation, content variants, dismissal, error.
The documentation makes explicit what a developer might otherwise have to infer. Inferred decisions create inconsistency — the developer makes a reasonable call that doesn’t match the design intent, and by the time it’s caught in QA it’s been implemented across ten components.
Visual component deconstruction
For complex components, I include a deconstruction view — the component broken apart visually to show its structure, the relationship between its parts, and the different ways it can behave.
This serves two purposes. First, it shows a developer exactly how the component is composed — which parts are separate elements, how they relate spatially, what changes under what conditions. Second, it makes the component’s flexibility legible — a developer can see at a glance what’s configurable versus what’s fixed.
For components with significant interaction logic — accordions, carousels, multi-step flows — this also includes annotated notes on the interaction model. Not a spec of every pixel, but enough to convey the intent behind the behaviour.
Tailwind classes in the spec
Because ABB’s frontend is built on Tailwind, I include utility class references directly in the design documentation. A spacing value isn’t just a number — it’s gap-6. A text style isn’t just a font size — it’s text-sm font-medium. A colour token resolves to a specific utility class that the developer can apply directly.
This removes the translation step. A developer doesn’t need to interpret a spacing value and work out which Tailwind class it corresponds to — it’s already there. The design spec becomes closer to a technical specification without requiring the designer to write code.
What this process assumes
It assumes the design system is the shared language. Without a system that both designer and developer are working from, this level of handover fidelity isn’t really possible — you’d be documenting every decision from scratch every time.
It also assumes a willingness to invest time upfront. Thorough handover documentation takes longer to produce than a set of Figma frames with minimal annotation. The payoff is fewer revision cycles, less implementation drift, and a faster path from handover to production-ready code.
The best measure of a handover is how many questions come back. Aim for none.