Helpful advice for packaging your design handoff in an easy-to-digest format for the Engineers on your team.
For me, one of the most time-consuming parts of design is the handoff process. As a designer, I know the ins and outs of my own design, like how a user interacts with a certain element or the size of a specific icon. But what's the best way to share the intimate working knowledge of our designs with others? What follows is a list of helpful tools and tips for handing off your designs using Figma.
Setting Up Your Figma File
Asset Folder + Read-Me File
Whenever I hand off design specs for development, I create an asset folder and a read-me file in Google Docs and link it in my Figma file. This can also be a separate page in your Figma file if you'd like to keep all assets and specs in one place. The read-me document serves as an overview of the information Engineers will find in your handoff documentation and has links to all relevant folders or files. I've also found it useful to include the project roadmap and links to agreed-upon deliverables so that project stakeholders have a one-stop shop for all assets.
I find this checklist helpful when creating a read-me document:
Description or background of the project and what the read-me file includes
Project roadmap with dates of sprints and a list of deliverables
Sprint descriptions and links to deliverables created in each
A link to the project asset folder, which includes assets such as images, video, maps, documents, and/or text that Engineers will need to build the product
You can add project stakeholders as collaborators to your Figma project so they have access to view or edit your work, but in most cases, it's enough to add collaborators as Viewers.
One thing I learned early on in my career was to keep my Figma files as organized as possible. If an Engineer or another Designer jumps into your Figma project one day and see 12 "Rectangle 2"s listed in a row, it will be hard to figure out which "Rectangle 2" acts as a button or which one is an image. Be sure to use descriptive but consistent names for your pages, layers, and frames so that it's easy to figure out which element does what. In addition, make sure any components you've created have meaningful names that provide information like when or what state they should be used in.
Then (left) vs. now (right). Which one do you think is more helpful?!
Style Guide/Design System
Keep all components, fonts, color palettes, and SVGs in one place for easy access and reference. If I have a long list of font stylings, I'll number each in my style guide and reference that number in my wireframe annotations so Engineers or other Designers can quickly refer back to the style guide when necessary. If you've already included descriptions for your components, any collaborator on the Figma file can click "Go to Main Component" on any component to see how it's styled and how it works.
Example of a style guide in Figma, which includes my color palette, typography styles, and components.
Creating annotations is one of the most critical parts of any design handoff process. It's a way to explain how users interact with each element, what each text link, button, or navigational element links to, any styling specs, and different states or variations of components or messaging. You can also include any design rationale or notes related to the wireframes that may be useful for the Development team or other stakeholders.
When creating my annotations, I usually create a new frame around each wireframe screen where I add my documentation. It's helpful to number each annotation, which would correspond to a numbered icon placed next to the relevant element on the screen. For an example, see image below.
Example of an annotated screen
In my Figma handoff file I also like to add a page for documenting any key user flows for the project. These can be key flows that relate to success metrics or KPIs or they could be particularly complex flows that would benefit from some additional explanation. On a recent project, I wanted to demonstrate error messaging, empty states, and certain interactions for more complex flows, so I included detailed descriptions and visuals for each. You could also include annotations for key flows, but any specs should also be cross-listed on the Annotations page of your file.
Example of a key flow
Sometimes visuals are more effective than words. Along with annotations and key flows, it helps to include a prototype of your wireframes so that stakeholders can interact with your designs and get a better idea of how it feels to use the product. Engineers will also be able to explore things like navigation, hover states, error messaging, and any interactions or animations you've included in your designs. You can prototype directly in Figma or export your wireframes into another tool, like Framer, where you can prototype more complex interactions.
If you'd like to go one step further, or if you'd like to be able to explain your designs in more detail, consider creating a video walkthrough of your wireframes or prototype. This ensures every stakeholder is on the same page and saves time by preventing you from having to setup multiple meetings to present your prototype.
On a recent project, I used Loom to record myself (and my screen) as I walked through my final prototype. This made it easy to share the same information to a remote team of three high-level stakeholders and three Engineers without having to schedule multiple video meetings. Recordings can be helpful in exploring any nuances in your design or aspects that may require further explanation. Loom has a pretty generous free plan, or you can try a 14 day free trial of their business plan.
Check out Loom.com
These are some of the tools and processes I've used in my handoff process, but I'm always interested to try out new tools or learn tips from other Designers. If you have any tips or tricks that work well for you, I'd love to hear about them!