Working with Developers: How to Collaborate Without Throwing Designs Over the Wall
How designers can collaborate with developers: involve them early, name the file well, document the states that don't show in mockups, and handle changes.
What does working with developers really mean?
For a long time the model was sequential: design, hand off, build. Figma describes that model as one where final screens and assets had to be tossed over a fence for developers to catch (Figma, “Guide to Developer Handoff”). The problem is that every late handoff brings surprises.
The alternative is to treat collaboration as a continuous process. Handoff is not a moment. It is a series of conversations that start before the final design and continue while the product is being built.
Why should a designer care?
Because many product problems surface late, when changing them costs more. A developer can tell you in ten minutes that an animation is expensive or that a data field doesn’t exist. If you learn that during wireframes, you adjust the design without drama.
Figma recommends asking for feasibility feedback with wireframes, while ideas are still flexible, rather than with a polished screen that nobody wants to touch (The Designer’s Handbook for Developer Handoff).
How is the work organized day to day?
These are practices recommended by the Figma and Built In guides:
- Involve people early. Hold an early kickoff meeting with engineering, so they can define technical requirements and propose a high-level architecture, and run joint brainstorming sessions (Built In, “Designer-developer collaboration”).
- Ask precise questions. Ask about data constraints, missing states, and reusable components that already exist. Specific questions get useful answers.
- Organize the file by status. Figma describes how some teams split their work into pages: what is still in progress, what is ready for feedback, and what is ready to build. That way nobody has to guess what is finished.
- Name with intent. A frame called “Frame 123” is a generic div. Figma recommends giving color, type, and effect styles clear names, which makes it easier to match what is in Figma with what is in code. Figma’s code syntax and Code Connect reinforce that link.
- Mark the status. Tag finished sections with “Ready for dev”, and define what “ready for handoff” means on your team. Before handing off, open the file in Dev Mode to see what the developer will see.
- Mention people by name. Tag each developer by name in the file’s comments to get asynchronous feedback.
Built In points out that designer-developer interaction should not be limited to the handoff phase, and recommends collecting developer feedback directly and regularly. A useful clue: analyze the questions developers ask after reviewing the specifications, because they show what the file was missing.
If a practice keeps repeating, write it down in the team’s design handoff notes, not in one person’s memory.
What should you annotate that doesn’t show in the mockup?
A mockup shows the happy path. Developers also build the edge cases. Annotate:
- Responsive behavior: which values are fixed and which adapt to screen size.
- Success, error, empty, and loading states.
- The difference between a link and a button when they look alike.
- Transitions with their durations and their behavior with reduced motion.
- Long text, low-resolution images, and incomplete profiles.
If you detach an instance from the design system, explain why. That record stops someone from “fixing” it later, thinking it’s a mistake.
What should you ask at the kickoff meeting?
The kickoff meeting lets developers define technical requirements and propose a high-level architecture. Bring questions, not locked screens:
- Which data exists today, and which would have to be created?
- Which design system components can we reuse?
- Which parts of the idea are expensive to build, and which are cheap?
- Which states or odd cases do you already know from working with the product?
Note the answers in the file itself, next to the screens they affect.
Example
Illustrative example: a designer hands off a checkout screen with a centered “Pay” button and nothing else. During development, three questions come up: what happens if the payment takes more than ten seconds, what happens if the card is declined, and what text the user sees when offline. If those states had been documented beforehand, the team would have discussed the error flow in a short meeting instead of after a week of building.
When NOT to involve the whole team
- For personal exploration. A sketch you want to test on your own doesn’t need a meeting with all of engineering.
- When the question is business strategy. That belongs to product and stakeholders, not to a conversation with the codebase.
- When the noise outweighs the input. If every color change goes through the engineering channel, the relationship deteriorates.
Common mistakes
- Treating handoff as a single moment at the end.
- Delivering only the final screen without success or error states.
- Requesting scope changes after something is already built.
- Always giving in to technical feasibility at the cost of user experience, or the other way around.
- Letting repeated questions go unanswered instead of documenting them.
How to start tomorrow
Before your next design meeting, pick one screen and write a list of the states that don’t appear in the mockup. Send it to a developer with two specific questions: what data are we missing? which component already exists? Then review which questions keep coming up and turn them into a handoff template or part of your design documentation.
If the team already works with a design system, also look at how to contribute to a design system so changes from both sides follow a clear path.