Design to code: how to streamline design-to-dev handoff with Figma
At Selecto we believe in collaborative effort as a prerequisite for a successful project. For us, the interaction between the teams of designers and developers is a must to smoothly translate the UX/UI language into code. And design-to-dev handoff is a crucial step to ensure the quality of the final product and end-user satisfaction.
Our designers make the handoff materials accessible, readable, and easy to follow through to facilitate the workflow for the developers. We know how to make a perfect creative-tech match and in this article we will share tips and tricks with those working in Figma or similar design tools, but struggling with the handover process.
Our approach works well if you’re working with small/mid-size design projects. In case you work on a big product, you might use it partially, but every product has its own way to do it.
In this article, we will explain the process from the big picture knowledge to smaller details. Let’s get to it!
First steps first: handoff document
Good handoff document is half of the success of a smooth design-to-dev handoff and to ensure that its structure and logic is clear, we recommend doing the following.
First, make the number of documents optimal. Too few? This will probably result in having big heavy documents which are hard to navigate. Too many? This will lead to constant jumping between the documents to find what developer needs. Listen to your team: they’ll let you know if the number of docs is not a good fit.
Next, every Figma document should have its own thumbnail: this helps to visually spot the document among those shared with the team.
Document name usually has a [ Project name — Type ] structure. In case there are subprojects, we also add their names in a following format: [ Project name — Subproject — Type ]. Types may be UI, UX, Design system, Archive, etc.
Type icon is used as a visual device signifier, usually it’s in the shape of an icon: 📱, 🖥, ⌚️ or else.
The status icon is used together with the status name to reflect the stage of the design process. At Selecto we use these ones:
- 🟢 Delivery: Ready for development. Design is approved by the stakeholders
- 🟠 Process: Work in progress. Design process in progress. This document is where the majority of the work is being done
- ⚫ Archived: Unused and obsolete concepts. Collection of ideas to reuse later
- 💠 Design system: Where your design system lies
We recommend separating delivery and process documents. This way developers won’t be distracted by work-in-progress design concepts.
When working on a large project, some stakeholders prefer not to “hunt” for a certain document, but to view them all at once. Use “hub prototypes” as a Table of Contents for all of your links.
Keeping the handoff structured
Name your pages whatever you like, as long as the document structure stays the same. The approach is similar as with the documents. On the smaller projects, you may include the whole UI on one page, on the bigger ones — one epic/feature per project is a good choice.
General recommendations:
- Add to a page name an emoji at a beginning for visual differentiation
- Don’t put responsive states to different pages (e.g. web-desktop and web-mobile should be on the same page and placed side-by-side)
- Store unapproved concepts in 🗄 Archive page
- Create a separate page for 🖼 Cover
- You may use page names as logical separators by naming them
— — — — —
Sometimes the number of flows may be increased gradually and even pages can’t help. In these rare cases, you may try to use the TOC page with internal links to navigate all of them.
Dealing with frames
First-level frames (AKA “artboards”) should be grouped by flows or use cases. The easiest way to group frames is to add whitespace around and add a group header above it.
Tip: use component instances or groups for the group header, so their names won’t appear on the canvas.
Depending on your design process and the project management tool you use, additional attributes, such as flow design completion status or Jira links, may be added to headers. You may also find it handy to use different levels of headers to arrange smaller groups into bigger ones.
Name every frame with a descriptive name, which describes its content. Make it short so it fits on tight frame width when you browse the page with a small zoom scale. You can use the structure as [Category Name — Screen name: state] where the state, for example, may be used to indicate a slight state change of some elements, but not the whole screen like empty, filled, errors, etc.
Going with the flow
Put your screens in the left to right order if the flow is linear and has no sideways. If it’s not the case and your project has corner cases, exceptions, errors, and other conditional behaviour, you better communicate all these flows to the developer. To do so, we design an annotated flow straight on the Figma canvas to clearly explain how users navigate from one screen to another.
How to annotate the flow:
- Create a starting point and describe the trigger for the appearance of the first screen
- Show condition of moving to the next screen
- Show condition of moving back if it may be unclear
- Add decision question point when the flow goes non-linear and user may choose different path
- If needed, insert additional information for developers under the frame
While working on “matured” projects we already know major user interaction patterns, so there is no need to communicate every concept through a prototype. That’s why communication by flow would be a better choice and will save you time.
Communicating responsive states
Sometimes, you can’t just add mobile (360px wide) and web (1024px wide) states, and hope that developers will figure out the rest by themselves. A usual website has more than two responsive breakpoints to effectively use the available screen space. In this case, illustrate how the layout behaves when facing different external conditions (different width, height, OS theme, etc):
- Add additional responsive states of the layout to show how different components behave. You don’t need to design every screen for every breakpoint if it won’t bring new information: just give a general sense of layout behavior
- Don’t forget to check the states at the beginning of the breakpoint of the responsive states (e.g if you have a breakpoint at 640px, try to test how the layout behaves at 659px wide. Spoiler alert: probably it won’t look good 😄)
Working with the layers
Requiring to name all the layers would be an overkill, let’s be honest 😁. It’s recommended to name appropriately 1st level layers, so that other teammates can read the structure of the artboard. At the same time, it’s mandatory to name all the layers in components. Trust us: your design system developer will thank you for that.
All layers should have applied defined styles (color, typography, effects) and they should be presented and organized in the document’s design system
Use the magical Style Organizer Figma plugin to keep your colors and fonts in order
- Pressed, hover, edit error, and unavailable states of the controls should be designed and applied through styles as well
- If you have drag-and-drop interaction in the app, don’t forget to add drag, dragend, dragenter, dragleave, dragover, dragstart, drop events
- Use standard components from the design system whenever possible and convert repeated design patterns into instances of one component
- Icons should be placed in square containers with one of the several standard dimensions
Content management 101
The content should be as close to the real one as possible. Our general guidelines are:
- No Lorem Ipsum or other text fillers (c’mon, it’s not 2004 anymore). If you can’t add appropriate text, it might be a sign that you haven’t done enough research
- Images and labels should be different. Yes, for table records as well. (content population plugins may help). Consider displaying low-quality photos
- Keep in mind snd think through situations, when there’s no content (AKA “empty states”). For example, the user didn’t upload a profile photo, hasn’t added a bio, etc
- Don’t forget to work with too little or too much content to demonstrate how your design handles such cases
- For heavy loading pages or slow operations include loading state
Structure your communication
If you don’t use a specific application for design-to-dev handoff like Zeplin or Avocode, sometimes it’s hard for product managers to keep track of all the changes in design. The easiest way for async communication of updates are:
- Record Loom video with all the updates presented by you
- Post a Slack update for all the team members in the #design-updates channel, so everybody will have the access to structured updates at their fingertips anytime.
The issue with links to frames in Figma is that they might not show the entire flow once opened. If you want to control what team members see when they access the link, you can use the flow headers as containers for flows and share the link to them.
Final thoughts
In this article we introduced the basic requirements and recommendations we have for the design-to-dev handoff at Selecto. However, we don’t regard them as gold-plated, but rather as constantly changing and updating, especially when new possibilities emerge in software updates or processes. We always look at the primary purpose of the whole process — developing a high-quality product to make the end-user fall in love with it.
Hope this guide will be useful for those working with Figma. And if you’re looking for a team to make your product better from the design and development sides, don’t hesitate to contact us.
— Oleksandr Valius
