5 things designers need to know for a smooth handoff
Handoff is a process, not a moment. So how do you streamline handoff when it’s a constant stream of WIP designs, communication, and collaboration? Designer Advocate Lauren Andres shares her tips.
There’s no truth teller quite like Google autocomplete. As you type “Design development handoff is…” into the search bar, it quickly fills in the blank with terms like “issues” and “not working.” It’s not that everyone’s handoff is broken; it’s that we’re constantly in search of ways to make it better.
That’s no surprise. Knowing when to bring collaborators in, share context, and how to keep work moving can be tough when things are constantly in flux and your team is working across geographies and timezones. So how can you make sure that “Ready for dev” actually means Ready for dev? Figma Designer Advocate Lauren Andres, who has spent countless hours helping teams streamline their processes, shares the five things every designer needs to know for a successful, speedy handoff.
1. Streamline and clarify callouts
Annotations allow you to share the intent behind design decisions and highlight details you don’t want to get lost. If you’re not sure what those details should be, the best thing you can do is talk to your developers about what they’d find most helpful to call out. For example, my developer counterpart may not need me to annotate something like spacing or color if I’ve already defined them as variables. But it could be really helpful for me to annotate if I’m using a new component, if there’s a specific interaction that should happen that may not have been clear in a prototype, or if something should look slightly different on different platforms.
With annotations, you can add information—like text and properties—to help developers during the handoff process. Learn more about annotations and how we built it here.
In addition to adding properties or text for specific layers, you can easily measure the distance between layers through Figma’s new annotations tool and have this information pinned for handoff.
In the past, you would mark up files with comments or stickies, but it would be hard to keep track of all the details. At Figma, we recently launched annotations in Dev Mode to save designers time as they add critical details such as specs, measurements, and notes to final mockups, and help developers find the right information, right away. Dev Mode isn’t meant to eliminate conversations between designers and developers; it’s meant to improve communication between them.
2. Adopt a shared language
As much as we work together, design and development are two completely different disciplines, which means that it’s easy for things to get lost in translation. (You want to be sure that when you’re referencing something like a toggle, your collaborator doesn’t assume that you’re talking about a switch.) The more time you can spend getting aligned on naming in the beginning, the more time you can spend later on focusing on the deeper discussions without getting caught up on confusing details.
For ensuring visual consistency, especially with colors, utilizing a color wheel in your design system can help both designers and developers quickly reference and apply the correct shades and tints across the project. This approach simplifies the handoff by embedding color theory directly into your shared tools and resources, making it easier for everyone to understand and implement the design as intended.
When it comes to the more foundational pieces like fonts, colors, and spacing, variables and styles are a great way to stay in sync. Check with your developers—they might already have naming conventions built out in their code that you can apply to your designs. And trusting that your developer knows what you mean when you say a button should be bg-primary-active with body text is far more comforting than trying to remember the exact hex code and font details.
3. Organize your files with labels
As a designer, I love Figma’s infinite canvas. But it can be confusing and overwhelming to get dropped into a file if you don’t know exactly where to find what you need. I can only assume that for a developer, trying to navigate a file that looks like this is a lot:
While it’s fine for our files to look, shall we say, “WIP” when we’re in the brainstorm and iteration phase, once we start inviting our developer friends over to build, it’s time to clean the place up.
Help narrow down the infinite canvas by using sections to create groupings of designs that make sense together. And add a “Ready for dev” status to those sections, or any other frames that are ready to go, to help your developer know what they should focus on.
Templates can also reduce some of the context switching. If your team aligns on one go-to template, developers don’t have to relearn how a file is laid out every time they work with a different designer. I also like to ask my developer counterpart what they want to see when they build out a design, whether that’s designs for mobile, tablet, or desktop, or a clear distinction between what’s hard coded text compared to what’s dynamic. From there, you can build out a checklist that reduces some of the mental burden and lets you and other designers know when you can be pencils down.
4. Archive old designs
As you organize pages into what’s important and what’s not, separate past explorations from current work. I’m not big on deleting everything; more often than not, I’ll go through 10 iterations only to end up pretty close to where I started (anyone else?), and it’s helpful to go back and compare where we landed to those old versions. What’s key is having a clear differentiation of what’s old and what’s new. I recommend putting any old designs in a clearly labeled archive page to keep confusion to a minimum. Or, use branching to help freeze just the work you want developers to focus on in the handoff.
5. Lean on components
Handoff, of course, isn’t just about the design itself; it’s making sure your collaborators understand how you arrived at that solution, why, and what your vision is for bringing it to life. For developers, Figma is often a space for them to gather information and context—even if their work happens outside of it. Anything you can do to help them find what they need while reducing back-and-forths is helpful. Tactically, I love using component descriptions, so the details of how to use my component stay with them at all times, and the developers don’t have to go back to another file with documentation to understand how to use it.
I also encourage developers to use Dev resources in Dev Mode so they can add links that they know are going to be relevant to them. While I could add links to my component description, the truth is that I’m not always sure which links are going to be the most helpful (and may not even have access to them). To me, it makes a lot more sense for developers to add what they know will be helpful as opposed to me trying to guess.
As designers, we’re in Figma a lot. Many things have become second nature to us, and it’s easy to forget that’s not the case for everyone. I remember when I first introduced the developers I was working with to Figma years ago, I took a lot for granted, assuming they would know that they could export assets themselves or favorite a file. (Similarly, if I popped into VS Code today, I wouldn’t know half of what I could do unless someone helped me along the way!) Figma is just one of the many tools that developers use, so it’s up to us to bring them along and empower them to work hand in hand with us.
Read all about annotations and what's next for Dev Mode.
Learn more about how to streamline handoff in Dev Mode and unlock designer-developer collaboration.
