What a developer really wants from handoff – and why most designers don’t give it away

Ask any frontender what they think of handoff designers and you’ll get a tired sigh. Not because designers are bad. And because between “makeup ready” and “feature in production” there is a chasm that is usually filled with questions in the chat, guesses and alterations on the review.

At the same time, most designers sincerely believe that they do handoff well. The layouts are laid out in Figma, there are tokens, in the comments even states are painted. What else do you need?

We need something else. A developer doesn’t need a beautiful layout – it needs a predictable solution system that can be translated into code without guessing. And that's where the gap begins.

## Where Hendoff Really Breaks

Hendoff is neither a file nor a link. This is the moment of the transfer of responsibility: from this screen, the designer can no longer double-check every detail, and the developer does not yet know the context of the decisions made. Anything that is not recorded will be invented on the spot. Sometimes good. More often than not.

Typical break points:

• Conditions that are not in the layout (loading, empty, error, long text, no data, offline)
• Behavior during resize, between breakpoints, on non-standard screens
• Microinteractions – what does a button do after pressing, how does a toast appear, how does an input behave when focused
• Validation logic and error texts
• What is a component of the design system, and what is a special case
• Accessibility: focus, contrast, tabulation order, aria attributes

When a developer asks a question in a chat, it is already a signal that the handoff was incomplete. One or two questions are fine. If there are ten of them, the layout was not ready for transfer.

## What the developer hears when you say “the layout is ready”

It's worth doing an honest exercise. Take your latest handoff and look at it through the eyes of the person who sees the project for the first time and must pass the task for the sprint.

### What he's waiting for by default

• All state components in one place, not scattered on the screens
• It is clear which indentations and sizes are from the design system, and which are caste
• The adapter is described, not “proportionally.”
• The lyrics are final, not "Lorem ipsum" and "there will be a description"
• Icons are attached in the desired format, and do not need to pull from Figma manually
• There is a reference to a speculator or ticket that describes logic, not just appearance

### Which he definitely doesn't want

• Get a layout in the form of "here's the frame, then figure it out."
• Guess which of the three components is the right one
• Open five files to collect one screen
• Hearing “Oh, that’s irrelevant” after a piece of code is written
• Get edits "for small things" on the day of release

## The difference between “design is drawn” and “design is ready to develop”

These are two different stages, and it is useful to separate them explicitly - at least for yourself.

**Design drawn **: visually solved the main problem, agreed with the product, looks as it should on the main case.

Design ready for development: all states are checked, transitions are described, edge cases are recorded, components are connected to the library, conflicts with the existing system are resolved, there is an answer to "what if...".

In between these stages, there’s usually a day or two of work that designers often skip—because it looks like it’s already done. It is this work that is the real handoff. Not export registration, but bringing the solution to a state where it does not need to be completed in your head.

### Short check before tossing link to development chat

• Default, hover, focus, active, disabled, loading, error, empty
• There is an example with long text and empty data
• Breakpoints or Adaptive Rules Described
• Texts final, agreed with the copywriter/product
• Components - from the library, custom tagged explicitly
• References to related tickets and previous decisions
• It is clear what is in this problem and what is in the next iteration

If at least one item is not marked - handoff will be "finished" in the chat, and the developer will make some decisions for you. Sometimes it's normal. More often than not, it comes back as “why does everything look different here?”.

## Workflow: how to bring the layout to the state of “you can take to work”

A good handoff is not the final spurt on Friday night, but a separate phase in the sprint. It has its own duration, its own checklist and its own result. If you think of it as a “let me down the link,” you’ll get back an interface that’s 80% yours and 20% someone else’s.

### Step 1. Scope freeze

Before preparing the layout for transfer, clearly fix: what is included in this task and what is in the next. Not in my head, but in a comment on a frame or in a ticket.

• What screens get into the sprint
• What conditions are mandatory, what - for later
• What components we use as is, what we change
• What counts as "good enough" for this iteration

Without this, you will finish drawing in the development process, and the developer will rewrite the finished pieces.

### Step 2. Assembling states in one place

The most common mistake is that states are scattered across different frames and screens. Hover button on one screen, disabled on another, loading anywhere. The developer needs to assemble a puzzle.

Collect all component options next to each other: default, hover, focus, active, disabled, loading, error, success. If the state is logically impossible, write it explicitly so that the question “why not” does not arise.

### Step 3. Run by edge cases

Take the layout and run through scripts that break the visual:

• Username of 40 characters
• List of one element and of 200
• Zero balance, negative balance, very large balance
• Long load, network break, repeated request
• Empty state of first input vs empty state after cleaning
• Text with long words (German, Finnish) or with RTL

Half of these cases are more common in production than the “perfect” script from the layout.

### Step 4. Reconciliation with the design system

Before transfer, go through the components and honestly answer: is this from the library, or did I redefined the indentation/color/radius? If you overdetermined, mark it and decide: this is a layout bug, a deliberate exclusion or an excuse to update a component in the system.

The developer needs to know the difference between "Take Button from the library" and "Here deliberately custom padding, don't rule.".

## Diagnosis: how to know that handoff is bad, even before complaints

You don't have to wait for retro. There are signals that are immediately visible.

### Signs that the layout is not yet ready

• In the development chat more than three clarifying questions for one task
• The developer sends a screenshot and asks “right?” – so it was not in the layout
• In PR there are values that are neither in the layout nor in tokens
• On the demo, you first see a state you didn’t think about
• QA makes bugs on 'unclear how it should be'
• A week after the release comes the edit “it really should be different”

Each case is not the fault of the developer. This is a sign that the decision was made without you and without context.

### Questions for self-review before transfer

Ask yourself, and answer honestly

• If I go on vacation tomorrow, can another person assemble this screen without me?
• What happens if there is no data at all?
• What happens if there is too much data?
• What are the three questions the developer will ask first, and is there an answer in the layout?
• What decisions do I have in my head but not fixed?

The last question is the most painful. Usually half the problems are there.

## Typical anti-patterns

### "Final layout v7 Final final"

Ten versions of frames, and it is unclear which is relevant. The solution is simple: one source of truth. Older versions - in the archive or a separate page marked. In the working area, only what goes into development.

### "I'll explain at the call."

Calling is not documentation. In two weeks, no one will remember that you agreed on the behavior of the scroll. If the decision is important, it should be in the layout or in the ticket text. The voice is for discussion, not for transmission.

### "I'll get it going."

It sounds flexible, in fact it means: the developer writes, you then ask to redo. The cost of editing after the code is several times higher than the cost of editing in the layout. It is better to delay the transfer for a day than to deal with a week.

### "It's obvious."

Obviously, because you've been with this screen for a week. A person who sees a layout for the first time does not know that the header should stick when scrolling, and the toast disappears after four seconds. If it's not signed, it's not.

### Pixel Perfection as a Replacement of Systematicity

The designer spends an hour aligning the icon to a half-pixel, but does not describe how the shape behaves when validation error. The developer will copy the indentations from the next screen, and the validation will come up with himself. Priorities are upside down.

## How to build it into a layout rather than keeping it close

Documentation that is separate from the layout is not readable. The goal is to get all the information you need to be where the developer is looking.

### What to put right in the frame

• Signatures to states: what triggers each
• Interactive abstracts: what happens when clicking, focusing, hovering
• Links to Library Components Next to Customs
• Adaptive rules: on which breakpoint what changes
• Texts of errors and empty states - final, not placeholder

### What to Take in Ticket or Speculation

• Business logic and display conditions
• Connections with other screens and flow
• Analytics: what events are tracked and what actions
• Open questions and compromises made

The division is simple: visual behavior in the layout, logic and context in the ticket. If you mix it up, nothing will read the whole thing.

## Segment summary

Hendoff breaks down not because the designer is bad, but because the lead-to-development stage is not singled out as a separate work. It is skipped because visually the layout already looks ready. But it's in this missing phase -- state, edge cases, annotations, system checks -- that the difference between the interface that's going to be sprinted and the interface that's done a month after it's released.

## Advanced scenarios: where the usual handoff no longer works

When the screen is one, and a team of three, you can drag it on your fingers. When the feature is ten, the developers are fifteen, and half in another time zone - the fingers run out. And then you start to work with connectivity: how your solution fits in with what's already in the code, with what the next team is doing, and with what a contractor you'll never see will pick up tomorrow.

### Scenario: The feature lives between two teams

Authorization – platform team, profile – product. You draw a profile screen, but logging out and handling an expired session is not yours. Here the handoff breaks at the junction: each side thinks the other holds the boundary.

Which helps:

• It is obvious to note on the layout which elements are a foreign component and which are yours
• Coordinate behavior at the junction before transfer, not after
• Name the person responsible for each piece right in the ticket, not in the chat

### Scenario: the design system has not yet matured

You are using a component that is not in the library. Option two: add to the system or leave local. Both are legitimate, but the decision must be made, not silently. If you leave it locally, mark it in the layout so that after six months, no one considers it a new system pattern.

### Scenario: dark theme, locales, densities

These three things break layouts most often because they are remembered at the end. German is longer than Russian, Arabic goes from right to left, in a dark topic you suddenly disappear the shadow on which the hierarchy was held. To check it out at the end is to redo it. To test in parallel is to catch problems where they are cheap.

## AI and MCP in Transmission: What Really Works and What Is Illusion

Now it is fashionable to connect an agent to Figma and get a “ready code”. It looks magical on the demo. Not so much in production, and it’s important to understand why.

### What AI Really Accelerates

• Turning the layout into a primary JSX/HTML skeleton
• Generation of repetitive layout of lists and cards
• Reconciling indents with tokens and searching for deviations
• Description of states and empty screens, if the developer is lazy to list them

That is, a routine where the structure is already set and the decision is made. Where AI doesn’t have to speculate, it saves hours.

### Where AI consistently fails

• Logic of behavior: what happens after a click, what status goes to the store
• Edge cases that are not in the layout - he will think and think past
• Binding to existing components: generate your div instead of your Button
• Availability: tricks, roles, order of navigation from the keyboard

The main risk of AI handoff is not that the code is bad. That it looks ready, and no one checks the decisions the model has made for you. The designer thought “it’s obvious,” the model came up with it, the developer accepted it, the QA didn’t notice it, and there’s behavior that no one consciously chose.

### Practices that reduce risk

• Transmit to AI not a naked layout, but a layout along with a description of states and links to components
• On the review, check in a separate line: do the components used match the library
• Any logic that the model has generated “in meaning,” talk to the developer aloud
• Don’t let AI make decisions about error texts and empty states – it’s a product, not a layout

## How to check the quality of handoff before he goes to work

A good way is to give the layout to a colleague who was not involved in the project and ask for a retelling. Not to “evaluate”, but to retell: what kind of screen, what the user does, what happens in extreme cases. All my colleague couldn’t say was a hole.

### Mini-checklist before transmission

• All states are named and visible in one frame next to each other
• Empty, download, error, partial data – there is for each zone of the screen
• Each custom element is either labeled as a caste or replaced with a component
• Texts are final, not lorem or text placeholder
• The adapter is described for at least two breakpoints
• Analytics and display conditions - in the ticket
• Name of the person responsible for open questions

If one item is not closed, it is not a disaster. But this should be noted explicitly, and not left as "later we will figure it out.".

## How to explain the decision to the team

Hendoff is not just a file. It's also a five-minute explanation, after which the team understands not "how it's drawn," but "why it is." Without this, the developer will not be able to make small decisions along the way - and he makes them every day.

Useful format - three levels:

• What are we doing? ** One sentence about the screen itself
• Why so. What product or user restriction does this cover
• What we don't consciously do. Scripts we've considered and postponed

The third point is more valuable than the first two. It removes half of the future questions, "Why didn't we do more and more like this?" If the answer is fixed, the dispute is closed before it begins.

## Segment summary

The larger the team and the more complex the product, the less “the layout speaks for itself” works. Another thing works: clear boundaries between teams, honest notes about caste and system, early testing of dark topics and locales, careful use of AI as a routine accelerator - not as a substitute for solutions. And above all, a brief explanation of why it was done this way and what was deliberately left behind. This is the kind of work that's hard to show in a portfolio, but it's what separates the designer the team wants to work with again from the one whose layouts have to be translated.

## Anti-Hendoff patterns that occur most often

Most of the failed gears look the same. Not because designers are lazy, but because under the pressure of deadlines, people cut the same corners. If you recognize them in the face, half the problems are removed before the layout goes into the sprint.

### "Final layout," which is actually a draft

The file has one screen, one state, perfect data, a neat header of two lines. The developer opens and returns an hour later with twenty questions. The sign is simple: if there is not a single long line in the layout, not a single “empty” state and not a single validation error, this is not the finale, this is a presentation for the stakeholder.

### Twin component

The library has Button/Primary, but the layout has its own rectangle "almost like Primary, only padding another." The developer either puts a library button and loses your pixels, or produces another local variant. Both are debt. If you really need a new option - it's a separate task in the system, not a quiet edit in the product layout.

### "Logic will be in Jira."

Ticket refers to Figma, Figma refers to a ticket, and there’s not a single phrase between them about what happens after you click. The developer is restoring the behavior of comments in Slack for the past month. Any logic that cannot be seen in the layout must be in one place – and this place is indicated in the layout itself.

### We'll figure it out later

The desktop is licked out, the mobile is one screen "to understand the idea." Mobile accounts for 60-80% of traffic. The developer makes all the decisions on touch-targets, transfers, hiding speakers himself, and this is normal only if you agreed in advance that this is how you work.

### A dark topic on the last day

The light palette is reviewed, the dark one appears the day before the release, and there are suddenly unreadable statuses and missing borders of cards. Dark is not a filter on top of light, it is a separate set of solutions, and it should be checked simultaneously with light, not catching up.

### Residual localities

The layout is in one language, the text is just enough to fit. German, Arabic, long Russian cases - all this pops up on the market. At least one screen with the longest of the real locales saves weeks of edits.

## Questions to Ask Yourself at a Review

These are not questions to the customer or questions to the developer. These are self-questioning questions before clicking "transfer to development.".

• If I get sick tomorrow, can the other designer on the team protect this layout without me?
• What are the three states of this screen I didn’t draw, and why?
• What decisions have I made without talking to the developer or the product?
• Where in the layout did I use "almost a component" instead of the present - and was it consciously so?
• What happens if the data isn’t there, there’s too much of it, or it comes with a mistake?
• What is the longest real text I checked in this interface?
• What scripts have I considered and deliberately put aside - and is it recorded somewhere?

If the answer to any question is “I don’t know” or “I have to see” – this is where the questions from the team will return. Better close now.

## Extended checklist: everything that should be in the transmission

Not every screen needs a whole list, but it’s helpful to walk through it.

### Contents of layout

• All states are collected in one frame and signed
• Boundary data: empty, one, many, very many, error
• Long texts on the real locale, not the one where it is more convenient
• Dark theme tested in the same scenarios as light
• Adaptive for at least two breakpoints, clearly indicated points

### System binding

• Each element is either from the library or marked as a caste
• Recesses and radii are tokens, not magic numbers
• Icons from one set, not three different ones
• Colors through variables, not hard code

### Context and logic

• Behavior after actions described next to the layout
• Display conditions and role restrictions are fixed
• Analytics Events Are Posted or Delayed
• Accessibility: focus, order of tabulation, roles - thought out
• Responsible for open screen questions

## Short practical outcome

Hendoff is not the moment when a designer “gives the job.” It's an interface between two disciplines, and the quality of that interface determines how many times a team returns to the same screen. The developer does not need perfect pixels and a beautiful file cover. He needs three things: to see all states, to trust component binding, to understand logic without investigation. Everything else is jewelry.

The designer who understands this, stops arguing about “who should think about edge cases” and begins to close them themselves – because otherwise they will be closed by the developer, and close as convenient to him, not the user. It’s less visible than a beautiful dribbble-style layout, but it’s what turns design into product.