Sevginur Ak Parlak
Apr 12, 2026
8 min read
Design Handoff to Developers: How We Work With Engineering Teams
The question I get most often from a CTO in a first call is not about visual style. It is some version of: if we hire you, how much of my engineers' time will this cost me?
It is the right question. A design file is not a deliverable, it is an input to a build. If it arrives without states, without rules, without token names and without anyone available in week 2 when the API returns something nobody drew, then the engineering team finishes the design themselves, in code, under time pressure. That is where most of the money in a redesign is actually lost.
This post is how we run handoff at Studio Scale: what we deliver, what a complete feature spec contains, how we use Figma variables, how design QA works, and what the whole thing costs in engineering hours.
Where handoff actually breaks
I have been on both sides of this. These are the 5 gaps, in the order they cost time.
Missing states.
The happy path is drawn. Loading, empty, error, no permission, 1 item, 200 items, a name of 60 characters and an offline state are not. The developer invents them at 5pm, and 3 weeks later a designer files them as bugs.
Undefined behaviour.
The screen is drawn but the rules are not written. What happens when the user submits twice, when validation fails on field 3 of 6, when the session expires mid flow, when the list updates while a row is selected. Screens describe appearance, and a build needs decisions.
Unnamed tokens.
The file uses 11 greys and 4 spacing values that appear nowhere in code. The developer picks the nearest existing variable, and the interface drifts from the design in week 1 without anyone deciding to.
No responsive rules.
1 desktop frame at 1440 pixels, nothing else. Every breakpoint becomes an engineering guess, and the guesses are inconsistent because 3 developers guess differently.
No designer during the build.
Handoff treated as a delivery date rather than a phase. Questions queue in a channel, the sprint does not wait, and the team ships something reasonable that is not what was agreed.
None of these is a Figma problem. They are all scope problems, decided before anyone opens the file.
What we deliver at handoff
Our handoff package has 5 parts. This is the list I would ask any design partner to show you, with a real project as the example.
1. The flow
A single map of the feature: entry points, decisions, exits, and what happens on failure at each step. Engineers read this first and it prevents most of the questions later.
2. Screens with every state
Every screen is delivered as a set, not a picture. Below is the matrix I fill in for each one.
3. The behaviour spec
Written rules next to the frames: validation per field, what is required, character limits, sort and default order, permissions per role, what is optimistic and what waits for the server, what is remembered between sessions, and every piece of interface copy, including the error strings.
4. Tokens and components
Colours, spacing, radius, type styles and breakpoints as named Figma variables that match the names used in code. Components with real variants for state and size, so a developer reads a component and knows which props exist.
5. Assets and specs
Icons and images exported at the sizes and formats the platform needs, plus a short note on motion: what animates, how long, and what must not animate.
The states matrix I fill in for every screen
This table is the single highest value artefact in our handoff, and it takes about 20 minutes per screen.
In a normal feature this matrix produces between 15 and 40 additional frames. That sounds like a lot of design work. It is much less work than discovering the same 40 cases in a code review.
Figma variables and naming, so the file matches the code
The handoff is only as good as the naming. We agree the token names with the engineering lead in week 1, before the design is finished, and we use whatever exists in the codebase rather than inventing a parallel vocabulary.
3 rules we hold to:
Semantic names, not literal ones. surface.raised and text.muted, not grey100 and grey400. A literal name is wrong the moment there is a dark theme.
1 source for spacing.
A scale of 4 or 8, and nothing off scale. If a value sits between 2 steps, that is a design decision to make, not a nudge in the file.
Components named as they are used. Table row / selected / compact is readable in a props list. Frame 214 is not.
We wrote separately about how we set this up in Using Variables on Figma: Case Study, and about the wider component library in Design System for Startups.
How the build phase runs
Handoff is not a date, it is about 3 weeks of overlap. This is our default rhythm with an engineering team.
Day 0, the walkthrough.
45 minutes, screen share, the whole feature including the states. Engineers ask questions live and we change the file the same day. This 1 meeting removes most of the asynchronous back and forth.
Week 1, open questions.
A shared channel, answers within the working day, and any decision made there written back into the spec so the file stays the source of truth.
Week 2, design QA on a staging build.
Not screenshots. I open the running product and check it against the spec, then file findings in your tracker with a severity: blocker, major, minor or cosmetic. A typical first QA pass on a medium feature produces 20 to 45 findings, and around 60 percent of them are 10 minute fixes.
Week 3, second pass and sign off.
Re check the blockers and majors, agree what ships and what goes to the backlog with a reason.
What good handoff saves, in numbers
I do not have a laboratory, so these are numbers from our own projects rather than a study, and I mark them as ours.
On features where we delivered the full states matrix, questions during development dropped from around 25 per feature to under 10. Design QA findings on the first pass fell from around 45 to around 20, and almost none of them were structural.
The rework pattern is the part worth knowing. A missing state found in the design file costs minutes. Found in code review it costs a few hours. Found after release it costs a fix, a regression test and a support conversation, and it usually arrives when the team is already working on something else. That is the real argument for spending 20 minutes per screen on a matrix.
Design QA, and what we check
Design QA is a defined pass, not an opinion. The checklist we use, in order:
Spacing and alignment against the token scale.
Type styles, not just size but line height and weight.
Color tokens, especially in dark theme and in disabled states.
Every state from the matrix, triggered in the real build.
Focus order and keyboard operation of the full flow.
Contrast at 4.5 to 1 for body text.
Touch targets at 44 by 44 pixels.
Motion duration and what happens with reduced motion enabled.
Interface copy character by character, since this is where silent edits happen.
Responsive behaviour at 3 widths, not 1.
We file findings with a screenshot, the expected behaviour, the token or component involved, and a severity. A finding without an expected behaviour is a complaint, and engineers are right to ignore those.
FAQ
What is a design handoff?
The point where a designed feature becomes an engineering task. A complete handoff includes the flow, every screen state, written behaviour rules, named tokens and components, exported assets, and a designer who stays available through the build and runs design QA on the staging version.
What should a design handoff include in Figma?
A flow map, screens with all states from the matrix above, behaviour and validation rules written next to the frames, interface copy including error strings, named variables matching the code, components with real variants, responsive rules for at least 3 widths, and exported assets.
How long does design QA take?
Half a day to 1 day per medium feature for the first pass, plus a shorter second pass. We usually run it in week 2 of the build so the fixes land before the sprint closes.
Do you work inside our sprint process?
Yes. We join the planning where the feature is scoped, deliver against your sprint dates, and answer questions in your channel within the working day. We do not need to attend every ceremony, and the walkthrough plus QA are the 2 meetings we ask for.
Can developers just use AI to fill the gaps in a design file?
Partly. Code generation from a Figma frame is genuinely useful now for static layout and component scaffolding. What it cannot do is decide what happens when the request fails, which role sees the row, or what the error message should say. Those decisions are the spec, and if nobody writes them, the model invents them and you find out in production.
Who owns the design system after the project?
You do. We deliver it in your file, with your naming, and we run a handover session with 1 engineer and 1 designer from your side so it can be extended without us.
Working with us
We design features for teams that have to build them, so the spec is the deliverable and the file is only part of it. That means every state, written behaviour rules, tokens named with your engineers, a walkthrough on day 0, questions answered during the build and design QA against the running product.
If you have been through a redesign that arrived as a folder of screens, book a free 15 minute intro call and tell us where the build slowed down. We will tell you what we would have specified differently.
